getopt.c: optarg should not be initialized

Christophe Lyon christophe.lyon@st.com
Wed Sep 22 22:46:00 GMT 2010


On 22.09.2010 13:47, Schwarz, Konrad wrote:
> Christophe,
>
> could you explain your problem in more detail,
> with an example, perhaps?
>
Here is a reduced test (I hope it's not too reduced)

========= main.c =========
#include <stdio.h>

extern char *optarg;
extern int optind, opterr, optopt;

int getopt(int argc, char * const argv[],
	   const char *optstring);

int main()
{
   printf("Hello\n");
   return 0;
}
======= getopt.c =========
char *optarg;

int optind = 1;
int opterr = 1;
int optopt = '?';

int getopt(int argc, char * const argv[],
	   const char *optstring)
{
   optarg = 0;
   return -1;
}

===========================
I am using an ARM-bare machine GCC + Newlib (Code Sourcery 2010q1) like 
this:
$ arm-none-eabi-gcc -c getopt.c
$ arm-none-eabi-gcc -c main.c
$ arm-none-eabi-gcc getopt.o main.o -o main -T generic-hosted.ld
[...]/arm-none-eabi/lib/libc.a(lib_a-getopt.o): In function `getopt':
getopt.c:(.text+0x97c): multiple definition of `getopt'
getopt.o:getopt.c:(.text+0x0): first defined here
[...]/arm-none-eabi/lib/libc.a(lib_a-getopt.o):(.bss+0x4): multiple 
definition of `optind'
getopt.o:(.data+0x0): first defined here
[...]/arm-none-eabi/lib/libc.a(lib_a-getopt.o):(.data+0x0): multiple 
definition of `opterr'
getopt.o:(.data+0x4): first defined here
[...]/arm-none-eabi/lib/libc.a(lib_a-getopt.o):(.data+0x4): multiple 
definition of `optopt'
getopt.o:(.data+0x8): first defined here
collect2: ld returned 1 exit status

I don't think it's obvious that initializing optarg will make the linker 
happy.

To make it clear, in this precise case, optarg is COMMON in the user 
getopt.o, and because it is DEFINED in libc.a(getopt.o), the linker 
decides to link with libc.a(getopt.o), leading to multiple definitions. 
If the optarg from libc.a(getopt.o) was COMMON too, the libc.a(getopt.o) 
module wouldn't be pulled by the linker, thus avoiding the multiple 
definitions.

I think this is a bit opaque for the average user.

Christophe.



More information about the Newlib mailing list