Re: 1.3.12: gcc bug: variable named "end"

[Randall R Schulz <rrschulz at cris dot com>]

As it has been since time immemorial in compilers with a Unix lineage or 
patterned after compilers of that lineage. Clearly GCC is such a compiler.

The linker binds the symbol "end" to the first unused address in the linked 
program. Some linkers also define "etext" and "edata" to indicate the end 
of the program text (its instructions) and of the initialized data, resp.

This program:

-==--==--==--==--==--==--==--==--==--==--==-
#include <stdio.h>

extern int main(int argc, char **argv);

extern int end;

int
main(int argc, char **argv)
{
    printf("etext=%#lx\n");

    return 0;
}
-==--==--==--==--==--==--==--==--==--==--==-

when compiled and run on my Cygwin system prints this:

end=0x407000


Note the "extern" storage class on the declaration of "end." It's supplied 
elsewhere (by the linker, i.e.).


Randall Schulz
Mountain View, CA USA


At 22:16 2002-10-18, you wrote:
> CYGWIN_NT-5.1 X22CHIKAYAMA 1.3.12(0.54/3/2) 2002-07-06 02:16 i686
> unknown
> gcc 2.95.3-5
>
> The following program causes a segmentation fault.
> ---
> int end;
> main() { end = 0; }
> ---
> Seems that the problem is with the variable name "end".
> In the object code tries to store in some invalid address.
> Variables with other names, of course, does not cause this.
>
> - Takashi Chikayama

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/