On: Essential C [pdf]

[pjmlp]

You never could implement malloc() in C anyway, because the language lacks the ability to manipulate the MMU.

[NonEUCitizen → pjmlp]

C runs on platforms such as microcontrollers that don't have MMU's. Malloc is available on those platforms.

[pjmlp → NonEUCitizen]

The point isn't that malloc is available, rather that it is impossible to write in ISO C, other than mapping a global memory segment.

[monocasa → pjmlp]

It's strict aliasing that's the issue, not the mapping of memory to a address space. You run into the same issues with a global segment.

[pjmlp → monocasa]

Both are a problem, because they can only be implemented outside ISO C semantics.

That is why I tend to always write ISO C instead of C.

[monocasa → pjmlp]

One's not a blocker to a malloc implementation since you could otherwise just cut up a static char buffer. Coordinating with the OS is a nice to have. Strict aliasing is hard blocker. Hence why that's the issue under discussion.

And I'm not sure I understand why you're using the inability to describe certain actions as the reason why you use ISO C.

[astrange → monocasa]

Implementations of C have more functionality than C itself - like inline assembly or syscalls or machine-specific intrinsics, so it can do more. ISO C only has what's written in the standard.

(A syscall is an example of "something you can only do because the implementation isn't visible to the caller" - it can violate aliasing that way.)

Also, my argument isn't about type aliasing, it's about UB on out of bounds pointers. Could be some other aliasing issues though.