This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: using _FILE_OFFSET_BITS=64 with a non-gcc compiler
[Get raw message]
> 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.