GCC's new fortification level: The gains and costs

Re:GCC's new fortification level: The gains and costs by amadvance on Monday September 19, 2022 @03:33AM (#32895401)

Is a cast to uintptr_t also OK ?

  void *oldptr = malloc(73);
  uintptr_t savedptr = (uintptr_t)oldptr;
  void *newptr = realloc(oldptr, 42);
  if (savedptr == (uintptr_t)newptr) {
    // not changed
  }

[ Parent | on HN ]

Re:GCC's new fortification level: The gains and costs by munch117 on Monday September 19, 2022 @12:49PM (#32900776)

That is OK, at least in the sense that there's no undefined behaviour.

I'm not sure it's also OK, because the memcmp suggestion you are replying to seems a bit suspect.

There's still the problem that comparing the uintptr_t's is not guaranteed to yield the same result as the pointers they were cast from. But that's merely implementation-specific behaviour, not undefined.

[ Parent | on HN ]

Re:GCC's new fortification level: The gains and costs by kazinator on Monday September 19, 2022 @02:52PM (#32902331)

I think it's fine on the assumption that a uintptr_t converted from a pointer cannot be a trap representation, which is the case on mainstream platforms.

(An unsigned type can only have trap patterns if it has padding bits. Every combination of the value bits is a valid value according to the pure binary encoding.)

[ Parent | on HN ]