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] |
>>>>> 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] |