On Tue, Dec 17, 2019 at 05:30:01PM +0100, Vincent Lefevre wrote: > On 2019-12-17 16:27:28 +0100, Manfred wrote: > > It says implementation-defined, not undefined, > > IMHO, the difference matters mainly for the implementer: in short, > he must not ignore the issue. But an implementation-defined behavior > (or result) can be almost as useless as undefined behavior. Thankfully GCC documents it as working as you expect. All sane implementations on sane platforms do, as far as I know (work, that is; I have no idea how much they document). Almost all useful programs are not strictly conforming anyway, so that't alright. It's not a bad idea to document what implementation-defined behaviours your programs depend on, of course :-) > I would have actually preferred undefined behavior with a diagnostic. > I'm wondering why a programmer would want to convert a pointer to an > integer (except as a workaround to bizarre limitations, which would > better be solved directly by the standard). There are many reasons. Of course there are also many ways to abuse this :-) A very simple example is tagged pointers: put some value in the normally unused high or low bits of a pointer, indicating whatever you want it to indicate. In C, you cannot do this in a pointer, but you *can* do it in an uintptr_t (and after masking the tag out again, you can convert it back to a pointer). Segher
