Date: Tue, 13 Jan 1998 10:43:31 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Peter Palotas <blizzar AT hem1 DOT passagen DOT se>
cc: djgpp AT delorie DOT com
Subject: Re: getopt() and ANSI?
In-Reply-To: <3.0.16.19980112231015.199705b0@hem1.passagen.se>
Message-ID: <Pine.SUN.3.91.980113104304.5496A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Mon, 12 Jan 1998, Peter Palotas wrote:

> (2)How would I make sure that they are ANSI? Is there some program out
> there which can find out wether a program is ANSI or not? By the way, the
> GNU `getopt' compiles fine with -ansi -pedantic, but this isn't bulletproof
> I guess.

-ansi -pedantic *is* the way to test this.  And I was wrong: GNU
`getopt' seems indeed to be ANSI-compatible.

> >Since getopt.o (fgrom GNU) is mentioned on the link command line *before* 
> >libc.a, it gets linked instead of the DJGPP version.  And the interface 
> >is compatible, so no conflict here.
> 
> The interface is compatible? What do you mean by that?

I meant to say that the interface for calling the DJGPP version of
`getopt' is identical to the GNU version.  The reason for this
compatibility is, of course, that the POSIX standard defines the
functionality and the prototype of `getopt'.

> As far as I know, most compilers complain if the same symbol is
> defined twice no matter where it is put on the commandline, isn't it
> so in this case?

Yes, but you don't mention getopt.o twice on the link command line.
You say something like this:

	 gcc -o foo ... getopt.o libc.a

The second instance of getopt.o lives inside libc.a, but the linker
won't pull it from there since by the time it gets to the library,
the symbol `_getopt' is already resolved by the code from getopt.o.
So the linker doesn't have any reason to complain.