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