Mail Archives: djgpp/1997/11/06/08:20:58
On Thu, 6 Nov 1997, Roland Exler wrote:
> programming a bigger project I found the following problem which may be
> a linker-error, but at least a very dangerous thing. It costs me more
> than one day to find the bug.
IMHO, it's your bug. See below.
> The program below crashes with an segmentation fault, if file test.o is
> linked to main, even if (as you see) main calls nothing from test, but
> calls a function with the same name as a variable in test.o. The linker
> seems to resolve the reference to the function 'int enable();' to the
> variable 'int enable;' !!!
This is no bug. The names of the functions that you use are
``reserved'', in the sense that no other global object may have that
name. That's exactly why ANSI standard says that the names of all the
ANSI functions (like `fprintf', `exit', etc.) are reserved.
Here ``reserved'' has the same meaning as if they were keywords. Would
you be surprised that you cannot call your variables `int' or `char'?
I think not. The names of the functions are exactly the same, just
harder to debug, because in the case of a variable called `int' the
compiler will catch it and complain about ``parse error'' or some such.
While it is relatively easy to avoid calling your variables with names
such as `int' and `fprintf' (everybody knows about them, right?), it is
not so easy with non-ANSI functions such as `enable'. But when you use
non-ANSI functions in your program, it is *your* responsibility to make
sure you don't do these mistakes. So either look up the names of your
variables in the contents of libc.a (e.g., using the `nm' utility), or
call your global variables with names that cannot possibly be in the
library (e.g., `my_own_xyzzy_enable'), or use -ansi or -posix switches to
gcc that will issue a warning for every non-ANSI/non-POSIX function that
you are calling.
Another way to avoid such gotchas is to never call your functions and
global variables with names that begin with an underscore: the ANSI
standard says that these are ``reserved'' for the internal purposes of
the library.
The linker has no easy way of knowing that something here's not kosher.
Moreover, the programmer might have meant just that: that the linker has
to resolve these two to the same address.
> The problem may arise with all variable-names. With enable the problem
> is even more complicated to find, as all file-io as (f)printf calls
> enable() if interrupts are disabled and crashes the program this way.
I don't understand this. Which `fprintf' calls `enable' and where?
- Raw text -