4 ms·

> Support for calling realloc() with zero size (the behavior becomes undefined) OMG! Please do not add more undefined behaviour! We really need less UB, not

> Support for calling realloc() with zero size (the behavior becomes undefined) OMG! Please do not add more undefined behaviour! We really need less UB, not more! What was wrong with 'implementation defined' as in C17? UB means that code that exists will now break if a new compiler decides that it can be smart. And we know how inventive this can get, right? Like removal of 'if(new_size==0) {...}' if the compiler can prove that 'new_size' went into 'realloc' before.

c-linkage 5y ago
They'd better not convert that to undefined behavior! First, the specification for malloc() says you can call it with size 0 and it will still return a pointer to zero bytes; this means an array of bytes having size zero is legal. Second, having the compiler detect when realloc() is called with size zero changes what should be a library call into an intrinsic, whose very presence in the code is determined by the value of its arguments[0]. If you're going to do that you might as well just put exceptions in the language! [0] Most compilers assume UB "can't happen" and just remove the offending code altogether.
- enedil 5y ago
  Manual says > If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free(). So it's not really an array of bytes of size 0.
  - MichaelBurge 5y ago
    What qualifies something as a "real" array of bytes? All RAM is an array of bytes, so any pointer to real memory(vs. virtual memory) is a pointer to an array of bytes.
    - enedil 5y ago
      C mandates that arrays have positive size. It's not really a discussion about what the target platform does, rather it's what the abstract C machine mandates.
      - MichaelBurge 5y ago
        Oh sure - malloc() returns a pointer to sequentially-addressable bytes, not a C array. So even if the size were greater than 0, it would prove nothing about C arrays.
        minipci1321 5y ago
        > ... malloc() returns a pointer to sequentially-addressable bytes ... malloc () doesn't return even that. It returns 'void *' which isn't of much use without a further upcast. The required upcast, and the rest that follows, is the coder's own idea of what happens.
    - robotresearcher 5y ago
      The second allowed result of malloc(0), a unique pointer passable to free(), is not a pointer to an array of bytes. It can’t be used to access bytes - only compared to other pointers since it’s unique, and passed to free(). It doesn’t point to anything.
- masklinn 5y ago
  > Most compilers assume UB "can't happen" and just remove the offending code altogether. To be clearer: UBs (specifically the assumption that they don’t happen) get translated into constraints (since C’s type system is extremely weak UBs are a very valuable source of such constraints to optimising compilers), those constraints are then propagated (forwards, and backwards, and upwards due to inlining) and any path for which the constraint does not hold can be considered dead.
colanderman 5y ago
Where did you see this? I can't find it in the Twitter thread or any of the linked sources. I agree that "adding" support for something by making it UB makes no sense... as that generally would imply breaking forward-compatibility...
- beej71 5y ago
  Not only that, but the feature is genuinely useful.

c-linkage 5y ago

They'd better not convert that to undefined behavior! First, the specification for malloc() says you can call it with size 0 and it will still return a pointer to zero bytes; this means an array of bytes having size zero is legal. Second, having the compiler detect when realloc() is called with size zero changes what should be a library call into an intrinsic, whose very presence in the code is determined by the value of its arguments[0]. If you're going to do that you might as well just put exceptions in the language! [0] Most compilers assume UB "can't happen" and just remove the offending code altogether.

enedil 5y ago
Manual says > If size is 0, then malloc() returns either NULL, or a unique pointer value that can later be successfully passed to free(). So it's not really an array of bytes of size 0.
- MichaelBurge 5y ago
  What qualifies something as a "real" array of bytes? All RAM is an array of bytes, so any pointer to real memory(vs. virtual memory) is a pointer to an array of bytes.
  - enedil 5y ago
    C mandates that arrays have positive size. It's not really a discussion about what the target platform does, rather it's what the abstract C machine mandates.
    - MichaelBurge 5y ago
      Oh sure - malloc() returns a pointer to sequentially-addressable bytes, not a C array. So even if the size were greater than 0, it would prove nothing about C arrays.
      - minipci1321 5y ago
        > ... malloc() returns a pointer to sequentially-addressable bytes ... malloc () doesn't return even that. It returns 'void *' which isn't of much use without a further upcast. The required upcast, and the rest that follows, is the coder's own idea of what happens.
  - robotresearcher 5y ago
    The second allowed result of malloc(0), a unique pointer passable to free(), is not a pointer to an array of bytes. It can’t be used to access bytes - only compared to other pointers since it’s unique, and passed to free(). It doesn’t point to anything.
masklinn 5y ago
> Most compilers assume UB "can't happen" and just remove the offending code altogether. To be clearer: UBs (specifically the assumption that they don’t happen) get translated into constraints (since C’s type system is extremely weak UBs are a very valuable source of such constraints to optimising compilers), those constraints are then propagated (forwards, and backwards, and upwards due to inlining) and any path for which the constraint does not hold can be considered dead.

colanderman 5y ago

Where did you see this? I can't find it in the Twitter thread or any of the linked sources. I agree that "adding" support for something by making it UB makes no sense... as that generally would imply breaking forward-compatibility...

beej71 5y ago
Not only that, but the feature is genuinely useful.