Hi all, On Mar 17, 2024, at 2:32 PM, Bruno Haible <br...@clisp.org> wrote: > >> Is this a thing that anyone would want submitted to GNUlib? > > It seems to me that many GNU packages (coreutils, emacs, gettext, sed, at > least) include <sys/xattr.h> only for the purpose of ACLs.
That was why I was trying to make them work, yes. The libacl package requires them and is in turn taken advantage of if present by a great many other things. > GNU tar needs variants with *at, which it declares in xattr-at.h. I'll be honest, I'd never even heard of those variants until now. > GNU wget2 needs it in order to set > user.mime_type > user.charset > user.xdg.origin.url > user.xdg.referrer.url > user.last_modified > attributes, and has code for it on Linux, macOS, FreeBSD (the code for > FreeBSD being obviously buggy). "Obviously"? Why? > But these are not the only OSes that have xattr. fgetxattr and fsetxattr > are available on > Linux, Hurd, macOS, NetBSD, Cygwin, Android > whereas the extattr_* functions are available on > FreeBSD, NetBSD. > > Would you like to work on submitting a sys/xattr.h facility for Gnulib, > that > - covers all functions from glibc [1], > - works on Linux, Hurd, macOS, FreeBSD, NetBSD, Cygwin, Android ? Would I like to? Certainly. Would I know how? Unfortunately not. The only way I was able to get it to work on my Mac required overriding, and completely re-implementing the relevant parts of, the system xattr.h file; and I can't imagine it would be much different on those other platforms. How do you do something like that and have it work cross-platform? In C, the whole thing would be completely different on every kind of kernel, because the system call numbers are platform-specific. (I _think_ C++ can skate by on the fact that you can have the same function name more than once when the parameter lists differ.) As it is, I think even the C-language method I used might only reliably work for GCC, which not everyone uses. > You can delegate some of the platform specific testing to us. > You will need to sign copyright papers with the FSF for this contribution, > cf. [2]. That part's no issue. I just wasn't sure whether there was any interest for this in the first place, and it sounds like what little interest there is had never bothered to generalize their solutions. From what you say, it really might make more sense to build off of what the GNU tar and wget2 projects have already got -- it sounds like they're already further along than I got. G.
