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

Note that libc-hacker is a closed list. You may look at the archives of this list, but subscription and posting are not open.


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

Re: imacros


>>>>> Mark Kettenis writes:

Mark> The real problem is that <getopt.h> makes use of the feature test
Mark> macro's but does not include <features.h> itself.  We cannot include
Mark> <features.h> since <getopt.h> is shared with other GNU programs.  We
Mark> could include <stdio.h> from <getopt.h>.  I don't think that would
Mark> cause any problems, since both getopt.c and getpt1.c already include
Mark> <stdio.h>.
Mark> 
Mark> If there are serious objections against including <stdio.h>, we could
Mark> also move the inclusion of <getopt.h> from rpcinfo.c further down or
Mark> remove it altogether.

getopt.h is so far the only include file that gives trouble.  But it's 
not only used in rpcinfo.c, the problems might exist in other files
also (cf. my email with subject "-imacros").

Mark> Alternativey (if we want to keep the differences with the origional
Mark> Sun RPC sources as minimal as possible) we could also create
Mark> libc/include/getopt.h which does:
Mark> 
Mark> #include <features.h>
Mark> #include <posix/getopt.h>

If we don't want to change getopt.h and don't want to apply my patch,
I guess this is the right thing to do.

Mark> I don't think including <features.h> from include/libc-symbols.h is
Mark> such a good idea, since it hides the cases where we forget to include
Mark> <features.h>.

We included <features.h> indirectly before Zack's patch got applied
and we include it in each file.  If there's an advantage with not
including it via libc-symbols.h that's ok with me.  IMHO the non
inclusion of <features.h> break some files in a subtle way - I haven't 
seen either a good way to recognise those "cases where we forget to
include <features.h>"  nor heard any argument whether there's any
advantage with this scheme.

Andreas
-- 
 Andreas Jaeger   aj@arthur.rhein-neckar.de    jaeger@informatik.uni-kl.de
  for pgp-key finger ajaeger@aixd1.rhrk.uni-kl.de

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