From 06cfd9f6bf73cde4aae12120e3c724f9a0d3bd36 Mon Sep 17 00:00:00 2001 From: Christopher Haster Date: Mon, 10 Jun 2024 02:55:51 -0500 Subject: [PATCH] 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. --- lfs.h | 1 + 1 file changed, 1 insertion(+) diff --git a/lfs.h b/lfs.h index 1f2804c8..ec603d00 100644 --- a/lfs.h +++ b/lfs.h @@ -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