Re: [PATCH] Fix {,f}pathconf

[Roland McGrath <roland@redhat.com>]

> Recent pathconf changes broke alpha build (both linux/pathconf.c and
> alpha/linux/pathconf.c are redefining __pathconf).

Oops, braino on my part.

> But looking at it I found that alpha/*pathconf.c is bogus, not just alpha
> but all linux platforms support files >= 2GB on some filesystems.

Ok, but this changes the answers seen now and I don't know what users expect.

I like your changes to make the code generic, but the exact values you use
are wrong.  I think users will expect to see 32 or 64 and not anything
else.  FILESIZEBITS is not specified as the exact log2 of the maximum file
size, but rather as the minimum number of bits needed to represent *as a
signed integer* the maximum file size.  So, for 2GB files it needs to be
32, not 31--moreover, POSIX.1 specifies that 32 is the minimum value an
implementation can define.  It would meet the spec to return 42 when the
max size if 2^41-1, but I think it's a better plan to return 64, and in the
general case to return the bitcount of the off_t equivalent type
appropriate for the filesystem rather than its internal storage format limit.

> Looking at the kernel, it is really a mess to find out what the maximum
> filesizes are, but I've at least tried. Ideally kernel would implement
> itself *pathconf (and even then s_maxbytes would have to be cleaned up).

We are all agreed here, but the kernel people never helped in the past.