ISO C violation (really -- style & string pasting)

Donn Terry donn@interix.com
Thu Mar 25 15:05:00 GMT 1999


I don't believe you're understanding my point.  I'm trying to
change gcc so it doesn't create a symbol conflict, as it currently
does.  Please see my response to Richard H and if it still isn't
clear, let's try again.

W.r.t the program below: let's change it so GLOBAL_OFFSET_TABLE_
is an extern.  (With it on the stack, it doesn't have an assembler
name, and the issue isn't relevant.)

If the objective of the program is to print a user variable by
the name of GLOBAL_OFFSET_TABLE_, then it is correct ISO C.
However, on a machine which prefixes "_" to user names, it
would in this case first modify, then print, the first entry
in the runtime support data structure whose name is currently
spelled (in assembler space) _GLOBAL_OFFSET_TABLE_.  That's
what I'm trying to fix.

Donn

Martin v. Loewis wrote:
> 
> > Since the current uses of _GLOBAL_OFFSET_TABLE_ (which would
> > NOT present a problem for, e.g., ELF) are hardcoded into literal
> > strings in the compiler source (as part of instruction
> > source lines), which in turn becomes part of the .s file,
> > the symbol name needs to be changed in those strings,
> > which becomes a preprocessor trick.
> 
> I see. If this is really a problem, why not just change the compiler?
> Hacking with the preprocessor seems to produce more problems than it
> solves. Consider
> 
> #define SHOW(x) printf(#x " is %d\n", x);
> 
> int main()
> {
>   int GLOBAL_OFFSET_TABLE_ = 1,
>   SHOW(GLOBAL_OFFSET_TABLE_);
> }
> 
> With your hack, you'd break this program.
> 
> Regards,
> Martin

-- 

===================================================
Donn Terry                  mailto:donn@interix.com
Softway Systems, Inc.        http://www.interix.com
2850 McClelland Dr, Ste. 1800   Ft.Collins CO 80525
Tel: +1-970-204-9900           Fax: +1-970-204-9951
===================================================


More information about the Gcc mailing list