wjwithagen commented on PR #906: URL: https://github.com/apache/arrow-nanoarrow/pull/906#issuecomment-5036081106
> My problem with ENOATTR that it is logically tied to xattr and would be an abuse. Does it make it better? I am not a huge fan of the downstream patch either. I am open for improvements. I totally agree that in essence ENODATA is tied to attributes... And the Linux manpages for xattr() functions give ENODATA errors when the attributes are not there. They seems to have made those there aliases. But just random assigning a leftover number doesn't help either. I do not know enough of your full set of code, but I found that in Ceph the guys returned ENODATA on some points where ENOATTR would have been more apropriate. Currently I'm sort of starting to wonder how to fix this mess. This is another definition that is available: ''' .//devel/dwarves/files/patch-lib_bpf_src_str__error.c:+#define ENODATA 8817 ''' Which is something I've come arcross in some other libraries. (Which ones I cannot recall at this moment) So it comes back to why do you want to define it? And are you totally free to just pick a value for this define, completely outside the scope of the *xattr() functions. Otherwise I would really refrain from adding even more complexity to this tarpit. But looking at the objective off this project, where you build a set of functions to be used by others I'd keep with the mess Linux created and have ENODATA == ENOATTR. And not add jet again another value to ENODATA. -- 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]
