Mail Archives: djgpp/2000/12/17/16:16:28
naisbodo <naisbodo AT enteract DOT com> wrote:
> > $ gcc -v
> > Reading specs from d:/djgpp/lib/gcc-lib/djgpp/2.952/specs
> > gcc version 2.95.2 19991024 (release)
> > $ echo "int main(void){return 0;}" > foo.c
> > $ cp foo.c ./-.c
> > $ cp foo.c ./--.c
> > $ cp foo.c ./---.c
> > $ gcc foo.c
> > $ gcc ./-.c
> > $ gcc ./--.c
> > $ gcc ./---.c
>
> All correct so far, right?
Yep.
> > $ gcc -.c
> > gcc.exe: unrecognized option `-.c'
> > gcc.exe: No input files
>
> A single dash means "gcc option" and .c is not a valid gcc option, so
> this error is correct.
Correct.
> > $ gcc --.c
> > gcc.exe: No input files
> > $ gcc ---.c
> > gcc.exe: No input files
> > $ gcc ---
> > gcc.exe: No input files
>
> A double dash means "cc1 option" and it is passed to cc1 when cc1 is
> invoked. Since you've given gcc no input files, cc1 is never given the
> chance to reject the option.
This could explain the observed behaviour of gcc.
> However, there are several possible options beginning with -- which are
> not passed to cc1, such as --version.
>
> > $ gcc --
> > gcc.exe: Ambiguous abbreviation --
> > gcc.exe: No input files
> > $ gcc -- foo.c
> > gcc.exe: Ambiguous abbreviation --
>
> And because of this, gcc can recognize several abbreviations beginning
> with a double dash, and in this case it is ambiguous because more than
> one option could follow the sequence given.
Hmm, ok, I think I understand. However, double dash, on its own, is
commonly used in GNU programs to mean "treat all following arguments
as non-options."
> So this is correct as well.
>
> > $ gcc --- foo.c
> > cc1.exe: Invalid option `-f-'
>
> That's how double dash options are translated into cc1 options, and is
> correct behavior.
Well it seems strange behaviour to anyone not familiar with this
feature. Can you point to some docs that explain this? Or at least
give an example of its correct usage (so we can test this with DJGPP).
> > For example: gxx ./-----.cpp -o ./-----.exe
>
> Since you already know how to compile these, can I safely assume that
> there is no invalid behavior causing you any problems? I have seen no
> gcc bugs in the above.
There is no invalid behavior causing me any problems, I was merely
trying to help the OP.
- Raw text -