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
Attachment:
signature.asc
Description: This is a digitally signed message part.