Re: the nonexistent "sys/xattr.h" gnulib module

[Gordon Steemson]

Hi all,

On Mar 17, 2024, at 2:32 PM, Bruno Haible <bruno@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.