xiaoxiang781216 commented on a change in pull request #4121:
URL: https://github.com/apache/incubator-nuttx/pull/4121#discussion_r668804207
##########
File path: fs/vfs/fs_stat.c
##########
@@ -120,6 +120,10 @@ static int stat_recursive(FAR const char *path,
ret = inode->u.i_mops->stat(inode, desc.relpath, buf);
}
+ else
+ {
+ ret = -ENOSYS;
Review comment:
> > How to interpret the error code not mention in standard?
>
> The application is not expecting to receive `-ENOSYS`, since this is
non-compliant to the standard.
>
from
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html:
Implementations may support additional errors not included in this list, may
generate errors included in this list under circumstances other than those
described here, or may contain extensions or limitations that prevent some
errors from occurring.
It's valid to return the additional error code. Actually, I don't believe
anyone write the code to only hande the error value mentioned by the standard,
it's totally unportable.
> > @gustavonihei I think I would agree with @xiaoxiang781216 that the
ENOSYS is appropriate here. Do you have a better solution in mind?
>
> I'd like to understand what is the error scenario that the `-ENOSYS` value
may be useful:
>
> 1. Is it when `stat` should be implemented by the FS implementation, but
it is not? (missing implementation)
All FS should implement it, but this check ensure if implementer forget it,
the user(even the implementer self) can catch it immediately, instead wasting
the time to the unnecessary debug.
> 2. Is it when the application erroneously calls `stat` for an invalid FS
node? (usage error)
>
This case is covered by the code before this point.
> Please, correct me if I am understanding it wrong, but what I am worried
about is that we may be trying to postpone to runtime the handling of a
"static" error.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
