Define error codes in terms of errno values

[ssilverman]

littlefs/lfs.h

Line 70 in adad0fb

enum lfs_error {

I was going through the LFS error codes and noticed that a few values don't match my system:

Error	LFS	errno from GCC arm-none-eabi
LFS_ERR_NOTEMPTY	-39	90
LFS_ERR_NAMETOOLONG	-36	91

May I suggest defining the LFS_ERR_* values in terms of the errno values from errno.h? This way, the system would always match, and there'd be no reason to write a custom mapping function that maps from LFS_ERR_* to system errno values.

Then, I could take all return values, check them for being negative, and setting errno to the negative of that value without a map.

[ssilverman]

Here's my mapping function:

static int lfs_to_errno(const enum lfs_error err) {
  switch (err) {
    case LFS_ERR_OK:          return 0;
    case LFS_ERR_IO:          return EIO;
    case LFS_ERR_CORRUPT:     return EBADMSG;
    case LFS_ERR_NOENT:       return ENOENT;
    case LFS_ERR_EXIST:       return EEXIST;
    case LFS_ERR_NOTDIR:      return ENOTDIR;
    case LFS_ERR_ISDIR:       return EISDIR;
    case LFS_ERR_NOTEMPTY:    return ENOTEMPTY;
    case LFS_ERR_BADF:        return EBADF;
    case LFS_ERR_FBIG:        return EFBIG;
    case LFS_ERR_INVAL:       return EINVAL;
    case LFS_ERR_NOSPC:       return ENOSPC;
    case LFS_ERR_NOMEM:       return ENOMEM;
    case LFS_ERR_NOATTR:      return ENODATA;
    case LFS_ERR_NAMETOOLONG: return ENAMETOOLONG;
    default:
      return EIO;
  }
}

[geky]

Hi @ssilverman, thanks for creating an issue.

I agree this isn't ideal. It would be nice to allow users to override the lfs_error enum.

My thinking was we could move lfs_error into lfs_util.h and wrap it with ifndef LFS_ERROR. This would allow it to be overwritten with either LFS_CONFIG or LFS_DEFINES like the other system hooks.

I don't think we'd want to map these to errno.h by default, as that would break external scripts that may be useful (dbgerr.py, for example, not yet merged).

It's not perfect, but I think trying to use errno.h risks more confusion for users using littlefs in a non-OS/standalone environment. In general defaulting to slightly different behavior between systems is not great.

---

Note also littlefs2 is under a feature-freeze while littlefs3 work completes (#1111, unstable), so this is unlikely to change any time soon.