Re: ENOATTR vs ENODATA

[Jean-Yves Migeon <jeanyves.migeon%free.fr@localhost>]

Le 30/04/12 11:20, Emmanuel Dreyfus a écrit :
> Hi
>
> There is a choice to be made about returing ENOATTR or ENODATA  when we
> do not find an extended attribute.
>
> Here are the existing behaviors:
>
> 1) return ENOATTR, while ENODATA is defined and has other usages: NetBSD
> and MacOS X
>
> 2) return ENODATA, while ENOATTR is not defined: Linux
>
> 3) return ENOATTR, while ENODATA is not defined: FreeBSD
>
> The problem is that some userland program may test (errno == ENODATA)
> and get a different semantic on NetBSD and Linux. glusterfs does that,
> for instance.
[snip]
> In order to get the broader compatibility, I suggest patching our
> errno.h to define ENOATTR as ENODATA. Opinions?

Huh, you are going to meet some opposition (and I admit I am not fond of 
this solution). You are modifying a system-wide header and change the 
ENOATTR value (breaking backwards compat?)

BTW, having ENODATA ~= ENOATTR blocks all future usage where a real 
different semantic is needed.

Why not special case ENOATTR declaration, and let build environment 
override it when needed?

cc -DENOATTR=ENODATA [...]

Index: sys/sys/errno.h
===================================================================
RCS file: /cvsroot/src/sys/sys/errno.h,v
retrieving revision 1.39
diff -u -p -r1.39 errno.h
--- sys/sys/errno.h     31 Oct 2006 00:38:07 -0000      1.39
+++ sys/sys/errno.h     30 Apr 2012 11:59:02 -0000
@@ -165,7 +165,9 @@
 #define ETIME          92              /* STREAM ioctl timeout */

 /* File system extended attribute errors */
+#ifndef ENOATTR
 #define ENOATTR        93              /* Attribute not found */
+#endif

 /* Realtime, XSI STREAMS option errors */
 #define        EMULTIHOP       94              /* Multihop attempted */