Date: Tue, 13 Jan 1998 13:07:30 +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.19980113112429.1c373728@hem1.passagen.se>
Message-ID: <Pine.SUN.3.91.980113130027.5922A-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Tue, 13 Jan 1998, Peter Palotas wrote:

> Well, only problem are two warnings... "Implicit declaration of strncmp"
> and "Comparation between signed and unsigned"... The comparation probably
> isn't much to do about

On the contrary, I would suggest to understand exactly where does this 
comparison happen, since mixing signed and unsigned ints is generally 
asking for trouble.  It is possible, though, that including <string.h>
(see below) will make this warning go away as well.

> would you recommend adding "#include <string.h>" to the getopt.c file to
> get rid of the first warning, or should I just leave it the way it is?

I think it is better to include the header, provided that you know that
only ANSI compilers will be used to compile the code (some non-ANSI
compilers don't have string.h). 

> (Do any compilers produce errors instead of warnings for implicit 
> declarations?)

AFAIK, no.  Doing so would mean that such a compiler is incompatible with 
K&R style of code, and I don't believe any compilers would risk this.

> >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.
> 
> Is this a portable solution, i.e. does all linkers work this way?

AFAIK, yes.  An object module in a library is linked in only if there are
some unresolved symbols that are defined in that module.