Added LFS_ERR_UNKNOWN (-1) for quick-and-dirty errors

The idea behind LFS_ERR_UNKNOWN is to reserve -1 as a general purpose "Idunno what error code to use just bail" error. Discouraged for production code, but very useful for hacking things together either for quick prototypes or when trying to bootstrap a system. -1 was actually already carved out for this purpose, but not documented. I've used it heavily in other project, and it would be good to actually codify this so others know the option is available. This should end up being one of the allowed bd error codes, along with LFS_ERR_IO, LFS_ERR_CORRUPT, etc. --- If you try to map this to Linux errno codes, this does unfortunately conflict with EPERM (-1), but what is EPERM other than an arbitrary "you can't do that" error? Outside of Linux/POSIX, I think you can probably get away with using EACCES (-13) for permission related errors instead. I think the tradeoff is well worth it given we're not _really_ constrained to exact POSIX semantics.
2024-06-10 02:55:51 -05:00
parent 4da5ad0459
commit 06cfd9f6bf
1 changed files with 1 additions and 0 deletions
@@ -94,6 +94,7 @@ typedef int32_t  lfsr_sdid_t;
 // valid positive return values
 enum lfs_error {
    LFS_ERR_OK          = 0,    // No error
+    LFS_ERR_UNKNOWN     = -1,   // Unknown error
    LFS_ERR_INVAL       = -22,  // Invalid parameter
    LFS_ERR_NOTSUP      = -95,  // Operation not supported
    LFS_ERR_IO          = -5,   // Error during device operation