"Richard Guenther" <[EMAIL PROTECTED]> writes:
[...]
| > It's worse than that:
| >
| > char *pool;
| > void set_pool(char *p) { pool = p; }
| > void *operator new(size_t s) { // return stuff from pool. }
| >
| > bool f() {
| > char *p = new char[1024];
| > set_pool (p);
| > char *i = new char;
| > return (p == i);
| > }
| >
| > In other words, pointers from any part of the program can potentially be
| > "laundered" through set_pool and return via the new operator. I don't
| > see any way to make this fully safe, in general, without the limitation
| > I imposed: the no-aliasing guarantee only applies to the values returned
| > from the function called.
|
| But in this case an access to *i through *p is invalid. [I suppose both
| new calls are actually different implementations here] Each new
| call starts lifetime of a new object, the previous object lifetime is
| terminated. Even comparing both pointers here for this reason
| would lead to undefined behavior.
I don't follow your reasoning here. 'char*' and 'void*' are special.
-- Gaby
