This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] PR bootstrap/10169: Prototype getopt in mips-tfile.c


Hi Kaveh,
> Actually I find this kinda hackish, why fixinclude something just
> because gcc's -I setup with libiberty is crufty?  It's generally
> better to minimize the number of headers you "fix".

I agree that it isn't the cleanest solution, but it did have the
benefit of being safe and relatively machine independent.


> When I find myself in these situations, I ask: how is this working in
> the rest of the source base?  Answer: elsewhere we use getopt_long.
> E.g. look at gcov.c.  I believe accepting "long" options is also more
> in line with GNU standards.

Now who's being "hackish"?  :>  The reason we define a getopt in
libiberty is so we can call it portably from GNU code.  I must
admit that I never considered the solution "just don't use getopt!".
We could also get equally effective results just renaming the
function to xgetopt in libiberty :>

However, I do prefer your hack to the otherwise needless duplication
of headers by fixincludes.  I'm working on a patch.  Perhaps we should
poison "getopt" in the gcc source code.


But I do have one question.  I've never used getopt_long before so
I've been reading both gcov.c (as you suggested) and the man page.
Shouldn't gcov.c's and gcov-dump.c's "option" global variables have
a zero terminator?  i.e. { 0, 0, 0, 0 }?


If so I'll include fixes to both gcov.c and gcov-dump.c in the same
patch that changes mips-tfile.c and mips-tdump.c to use getopt_long.


Many thanks for your help (and forgive my teasing).

Roger
--


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