On May 7, 11:17 am, r...@hoekstra-uitgeverij.nl (Richard Bos) wrote:
> Eric Sosman <esos...@ieee-dot-org.invalid> wrote:
> > C99 improves the situation, but only a little. If the integer
> > types intptr_t and uintptr_t exist, then any valid void* can be
> > converted to one of them and back again and survive the journey.
> > (There are no guarantees for invalid pointers, nor for converting
> > an arbitrary integer value to void* and back.) Note, though, that
> > these integer types are optional: If they exist they will work as
> > you desire, but on some "exotic" architecture they might be absent.
>
> On the upside, if your architecture is exotic enough that it has a C99
> implementation but no (u)intptr_t, it's probably not reliably possible
> to do this in the first place. So if including <stdint.h> doesn't result
> in a definition of UINTPTR_MAX, bailing out with an #error would
> probably have been your best option anyway.
>
> BTW, I still don't understand why we have both intptr_t and uintptr_t.
> We really only need either of those.
I explained that in my other post.
vippstar wrote:
> That's possible. Using `intptr_t' or `uintptr_t'.
> You have to include <stdint.h> to use it.
> There is also uintptr_t, which you will use to store the void pointer
> does not matter.
> The type only matters if you use it in arithmetic.
> ie, uintptr_t foo = malloc(123); foo = ~foo; free((void*)~free);
^ ^^^^
> With intptr_t undefined behavior might be invoked in this example (if,
> for example, malloc() returns NULL)

Ignore the small error I made (typing free instead of foo), and that I
did not cast malloc(123) to (uintptr_t), which might be necessary.
The point of this snip is to show that ~ in signed integer with value
0 might be a trap representation, which you can avoid by using an
unsigned integer. I cannot think of an example that signed is
preferred to unsigned, but there has to be at least one.