using _FILE_OFFSET_BITS=64 with a non-gcc compiler

[Paul Eggert]

> From: Ulrich Drepper <drepper@redhat.com>
> Date: 12 Nov 2001 17:56:41 -0800

> Why excluding all compilers because very few features cannot be used
> in the same way as gcc?

I don't mean to exclude the compilers, just warn people about
compatibility issues.

How about this documentation patch instead, then?  I hope it addresses
the concerns that you raised in your message.

--- intro.texi	Tue Nov 13 16:50:47 2001
+++ intro-fix.texi	Tue Nov 13 16:57:12 2001
@@ -419,8 +419,15 @@
 come from the @w{ISO C} standard are reserved unconditionally; your program
 @strong{may not} redefine these names.  All other library names are
 reserved if your program explicitly includes the header file that
-defines or declares them.  There are several reasons for these
-restrictions:
+defines or declares them.
+
+If a name is not reserved, you can use it in your programs.  However,
+you may need to compile with GCC release 2.95 or later if you require
+complete conformance to the name space rules, as other compilers lack
+features that the GNU C Library headers use to avoid infringing on the
+user name space.
+
+There are several reasons for the name space restrictions:
 
 @itemize @bullet
 @item

This doc patch pushes glibc in the Solaris libc direction of violating
the strict name-space rules when used with compilers that lack the
necessary features.  As shown below, your proposed patch to the code
is already heading in that direction, so I assume this is OK; if not,
I can rephrase the patch.


>   #define readdir ((struct dirent *(*) (DIR *)) readdir64)
> 
> makes things work with only a little drawback: function pointer
> assignments...

Can't you fix the function-pointer assignment problem by prepending '*'?

Also, POSIX applications that don't define any feature-test macros
like _LARGEFILE64_SOURCE must be able to have an external declaration
like 'int readdir64;', but the above solution usurps that name.  I
assume that you meant __readdir64 instead?  Something like this:

  #define readdir (* (struct dirent *(*) (DIR *)) __readdir64)

That first '*' relies on a rather obscure feature of C89 and C99.
(If you want some amusement, you can even rewrite it as follows,
without changing the semantics from the single-'*' version:

  #define readdir (********* (struct dirent *(*) (DIR *)) __readdir64)

:-)


> If this is more acceptable I'll accept a patch.

This is more acceptable to me.  I'd like to see whether Bruno likes it
as well, as I think he has some test cases in mind that he can check
it with.

However, I don't see how this solution obeys the name space rules, as
it's an object macro, whereas it is supposed to be a function macro.
For example, the user must be able to have a function body like '{int
(readdir) = 1; return (readdir); }'.  It's bad style perhaps, but it
conforms to the POSIX standard.  Hence the above doc patch will still
be needed with this solution.

I think some minor name space violations are inevitable if we want to
support non-GCC compilers with LFS.  Mark Brown's solution with static
functions is clever, but it's hacky and I think it still doesn't quite
conform, as two different modules will have different readdir
functions, and their function pointers won't compare equal as the
standards require.