Re: [bug-gnulib] New GNULIB glob module?

[Paul Eggert]

Derek Price <address@hidden> writes:

>>Why do we need to include <sys/types.h> here?  All we need is size_t,
>>right?  And stddef.h gives us that.
>
> If I don't, I get the following error:
>
> In file included from glob.c:23:
> glob.h:107: error: syntax error before "struct"
> In file included from /usr/include/errno.h:36,
>                  from glob.c:25:
> /usr/include/bits/errno.h:38: error: syntax error before "extern"

Sorry, I can't debug that, since I don't have the exact version you do.

In the latest version you sent, we have code that looks like this:


   #ifdef _LIBC
   # include <sys/cdefs.h>
   #else
   # include <sys/types.h>
   # include <stddef.h>
   # undef __size_t
   # define __size_t size_t
   #endif

   __BEGIN_DECLS

First, already we have something bogus: that __BEGIN_DECLS.  It must
be protected by "#ifdef _LIBC", since random C environments don't have
it.  Similarly for __END_DECLS.

Second, that <sys/types.h> ought to be unnecessary.  We need only
size_t, and <stddef.h> provides that.  If we need <sys/types.h> for
some other reason on your platform, let's figure out why that is, and
attack its root source rather than the symptoms.  (The rest of this
message does that, I think.)

> Hrm.  Tracing this a little farther, it is only <features.h>, or even
> the <sys/cdefs.h>,

OK, here's what's happening, I think.  Every glibc header includes
<features.h> (and thus <sys/cdefs.h>) first thing, and this defines a
whole bunch of stuff.  If you attempt to declare libc-related stuff
without including <features.h> first, bad things happen.

The simplest fix would be to do something like this:

#if defined _LIBC || HAVE_SYS_CDEFS_H
# include <sys/cdefs.h>
#endif

with the appropriate change to glob.m4.

But let's step back a second.  Why are we worried about building
gnulib glob.c under glibc?  It will never happen, right?  So perhaps
we needn't worry about this problem at all.


> I copied and pasted this comment and the #undef block
> from the glob.c file.  It was previously placed just prior to the
> #include of <glob.h>.  This looked the better place for it since I
> assumed that we wouldn't want applications using the GNULIB glob module
> to issue lots of redefinition warnings.

OK, but in general this problem cannot be fixed in glob_.h.  If the
application includes our glob.h and then the buggy system files, it
will still lose big-time.

I tracked down these #undefs to this patch:

http://sourceware.org/cgi-bin/cvsweb.cgi/libc/posix/Attic/glob.c.diff?r1=1.20&r2=1.21&cvsroot=glibc

which has this ChangeLog entry in glibc:

Thu Jan 21 20:12:25 1993  Roland McGrath  (address@hidden)

        * posix/glob.c: Put #includes of <glob.h> and <fnmatch.h> after
        all system includes, in case one of them has conflicting defns of
        FNM_* or GLOB_*, so we will redefine.  #undef FNM_* and GLOB_*
        before including our headers.

I have heard of this problem occurring with <fnmatch.h> -- indeed,
<fnmatch_.h> documents that it occurs with HP-UX A.08.07 -- but it's
not clear to me that the problem every actually occurred with
<glob.h>.  Perhaps Roland made the change for <glob.h> simply as a
precaution, because it had happened with <fnmatch.h>.

Also, the problem, if it occurred with glob.h, was a long time ago,
and perhaps we need not worry about it any more.  HP-UX 8.07 was
released in 1992, and HP hasn't supported it for many years.  I doubt
whether people are building new GNU software for it any more.

With that in mind, how about if we simply remove those #undef's?  If
the problem recurs we can put them back in again.