This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: malloc attributes and realloc


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
 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]