This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] C undefined behavior fix
- From: kaih at khms dot westfalen dot de (Kai Henningsen)
- To: gcc at gcc dot gnu dot org
- Date: 05 Jan 2002 14:41:00 +0200
- Subject: Re: [PATCH] C undefined behavior fix
- Comment: Unsolicited commercial mail will incur an US$100 handling fee per received mail.
- Organization: Organisation? Me?! Are you kidding?
- References: <200201042153.g04LrfJ08250@penguin.transmeta.com>
torvalds@transmeta.com (Linus Torvalds) wrote on 04.01.02 in <200201042153.g04LrfJ08250@penguin.transmeta.com>:
> While the expression
>
> "string" - TASK_BASE
>
> may be undefined, the expression
>
> (void *)((unsigned long)"string" - TASK_BASE)
>
> is _not_ undefined, and gcc cannot play it's illegal games with it.
Uh, I am pretty certain it is completely legal for the "implementation
defined" parts to say that the latter is exactly equal in every respect to
- well, not the former, but the former cast to void *.
That *is* spelling out the choice of the implementation. And it leaves
sending this to strcpy() just as undefined as before.
But that is because we're talking about strcpy() (or any other thing the
compiler has reason to believe it understands).
What is *really* the problem here is that you are lying to the compiler.
The string constant (or global variable) is not where the compiler thinks
it is. *That* is the real problem, and nothing else.
Still, it's not unsolvable. Here is a fairly simple solution:
1. You need a way to get at a base address. I think reloc_offset() already
does all the hard work for that.
2. Put everything you need to access - everything you currently use
RELOC() for - in a big struct. Yes, including all the string constants.
3. Use (1) to create a pointer to where that struct actually lives, and
dereference *that*.
Problem solved. You're no longer lying to the compiler.
MfG Kai