This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: malloc attributes and realloc
- From: Gabriel Dos Reis <gdr at integrable-solutions dot net>
- To: dewar at gnat dot com (Robert Dewar)
- Cc: drow at mvista dot com, gcc at gcc dot gnu dot org
- Date: 02 Jan 2004 00:42:45 +0100
- Subject: Re: malloc attributes and realloc
- Organization: Integrable Solutions
- References: <20040101234055.70AC1F2CAE@nile.gnat.com>
dewar@gnat.com (Robert Dewar) writes:
| > And it is not clear that you can conclude from this that the behaviour
| > is undefined. If realloc returns a pointer that is equal to its
| > argument, it is clear that the storage is guranteed to be reserved for
| > the object pointed to. But if it does return a different value, then
| > the behaviour becomes undefined. That is, I think, what Joseph was
| > alluding to with his "bits compare".
|
| But if there are two non-determistic possibilities, then a program
| that counts on one of the two possibilities is incorrect anyway, so
| the fact that something *might* be undefined means semantically that
| it *is* undefined.
No. In C, it means that the behaviour is undefined if that execution
path is actually taken. Just like in
extern bool foo(void);
int main(void) { int *bar = 0; if (foo()) *bar = 2004; }
| The interesting question to ask is whether a compiler can use this
| fact even though it knows that in its particular implementation only
| one of the two possibilities will be chosen. I think the answer to
| this must be yes, or you get into a semantic mess.
Not really. As Joseph pointed out earlier, if you save the pointer
value in an array of unsigned char and latter do bits compare, you can
safely determine whether realloc returns the same pointer or not.
I don't know how that affect the design of the aliasing algorithm in
the compiler though.
-- Gaby