Hi,
Alle martedì 6 novembre 2012, Steven Chamberlain ha scritto:
> I'd say the test at Modules/posixmodule.c:114 is wrong:
> > #if defined(HAVE_SYS_XATTR_H) && defined(__GLIBC__)
> > #define USE_XATTRS
> > #endif
>
> Because GLIBC doesn't imply a working xattr interface (traditionally
> a Linux thing?). There seem to be implementations only for Linux,
> GNU/Hurd and as part of NetBSD Linux compatibility layer.
>
> On GNU/kFreeBSD there is only a stub for setxattr, returning -ENOSYS
> (not implemented).
Sure, and that's perfectly fine: those functions will return -1 with
errno ENOSYS, and the caller will check that and determine there is no
support for extended attributes.
The fact that glibc/kfreebsd *now* does not implement these functions
should not reflect on limiting features on userland, especially when
userland can already know *at runtime* when such features are not
available. If somebody implement them, say tomorrow, on glibc/kfreebsd,
the python code will just work, with no need for further changes.
> Hence there is no XATTR_SIZE_MAX defined either.
There is no relation on making the xattr functions working and defining
this. And actually, it would be even better if you do *not* define it,
since assuming a limit a compile time on something that can change at
runtime is simply pointless, or even harmful.
> For now, maybe it would be better as:
> > #if defined(HAVE_SYS_XATTR_H) && (defined(__linux__) ||
> > defined(__GNU__))
Please no, the current check:
#if defined(HAVE_SYS_XATTR_H) && defined(__GLIBC__)
is perfectly fine.
> The other problem is that GNU/Hurd doesn't enforce a maximum size and
> so still doesn't define XATTR_SIZE_MAX; on NetBSD they define it
> like this for compatibility it seems:
>
> http://fxr.watson.org/fxr/source/sys/xattr.h?v=NETBSD5#L52
>
> > #define XATTR_SIZE_MAX 65536 /* NetBSD does not enforce
> > this */
>
> So, GNU/Hurd could maybe add something like that if it helps with
> porting;
You still seem to assume there must be some magic MAX constant giving
you some upper limit...
Consider that Hurd does not provide PATH_MAX, I personally think it
would be a mistake providing the two XATTR_*_MAX defines just for the
sake of applications not actually checking their return values.
--
Pino Toscano
signature.asc
Description: This is a digitally signed message part.