[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: python3.3 build failure on kfreebsd and the hurd


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.

Reply to: