This is the mail archive of the libc-hacker@sourceware.cygnus.com mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: glob.h lack of #includes


> Do you have a proposal how to implement this?
> The problem is that there is no __size_t type.

I am not going to get into it all over again now.  I went to a lot of
trouble and hair in the original GNU libc implementation to get this right.

We ripped most of that out when 1003.1-1996 made *_t fair game for any
header to define, and relieved us (we thought) of the aggravating concern.
Are we really going to resurrect it now for pedantic adherence to
1003.2-1992 in the tiny set of headers it specifies?  I'm quite sure that
future standards will follow the 1003.1-1996 rules.

It is a very useful property that we would like to be able to claim
universally in the manual, that any GNU libc header can be #include'd cold
and won't generate syntax errors just because you didn't #include some
other header first.

Moreover, if glob.h only defines size_t and a 1003.2-1992-compliant
application is required to do:

	#include <sys/types.h>
	#include <glob.h>

anyway, then such uses can't possibly be broken.

Obviously, we can't make such a change in a 2.0.x release (since noone says
"can't possibly broken" on this list without me yelling at them).  But I
think we should make it in the development version, and get that version to
the maintainers of all the GNU packages that copy the file, so we can make
sure there aren't new problems using it outside of libc.  To be portable,
all those packages should (and presumably already do) #include
<sys/types.h> first anyway, so one thinks it shouldn't make a difference to
them.



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]