How so? The memory model and address space aren't something defined. Pointers aren't inherently limited to addressing only the space reflected by their size. In practice, that call cannot succeed, but those semantics aren't what is standardized or implemented by compilers at all.
Conversation
By deciding they can remove malloc(4), they've decided that the side effects or potential for failure don't need to be treated as observable. It's not that much further for them to then decide to use a virtual definition of it where it can be treated as potentially succeeding.
1
There are a lot of things that are explicitly undefined in the standard specifically to permit odd implementations of C with (mostly) precise garbage collection, etc. Pointers aren't really defined as addresses either and int conversions / arithmetic are very constrained by that.
1
Convert a pointer to an integer. Write the integer to a pipe, read it from the other end of the pipe and convert it back to a pointer. Dereferencing that pointer or even just doing any arithmetic on it is undefined and will even be broken by Clang / GCC optimization in practice.
3
I see your sentiments, but the above is incorrect or glossing over something important. Pointer escaping via write() is no different from escaping via any other function. Note how this is different from e.g. obtaining a not-escaping pointer value with a debugger.
1
1
You're trying to reason about it as a logical system providing native semantics which it isn't. The compilers have knowledge about standard library functions and they don't simply act the way they're defined in the library. My example is just something they consider undefined.
1
A very easy example to demonstrate is strdup. It's considered to have __attribute__((malloc)) (whether or not the libc marks it as such like glibc does) which includes guaranteeing:
> no pointers to valid objects occur in any storage addressed by P.
which can clearly happen.
2
In order for a pointer converted from an integer to be valid, there has to be a 'valid' path leading to it from where it was originally converted from a pointer to an integer. It's worth looking at DR 260 and also the standard's wording.
open-std.org/jtc1/sc22/wg14
1
> are permitted to track the origins of a bit-pattern and treat those representing an indeterminate value as distinct from those representing a determined value. They may also treat pointers based on different origins as distinct even though they are bitwise identical.
1
No conversions from integer take place here. Rather it's a matter of effective type rules for allocated storage with memcpy-like char copying.
1
I'm not talking about the specific example that was presented but rather the response to it. They are likely to more formally define these things in C2X and some early drafts like cl.cam.ac.uk/~pes20/cerberu show what that could end up looking like.
Compilers already interpret the standard as allowing them to do something similar to this, but not quite like this. It's also roughly similar in some ways to how C++14 defined it but not quite. The standard has been repeatedly modified to more explicitly permit this approach.
1
Thanks for the link. That proposal is still a pile of overcomplicated nonsense. The problems are all trivially solved *without breaking anything* by giving all the hard cases "wildcard provenance".
1
Note that the proposed text breaks lots of important valuable use cases like xor lists.
2
Show replies
1
1
Show replies