back
1 comments
`__builtin_dynamic_object_size` has been buggy since it was first implemented, breaking programs that relied on the previously-documented behavior of `malloc_usable_size`.

Instead of fixing the bug, the developers decided to remove the documentation and replace it with something else, breaking backwards compatibility.

Now, it's not that we can't ever break backwards compatibility - but it needs to be done with great deliberation and a transition period, and an alternative needs to be provided. I gave an example of an alternative.

This seems not entirely accurate. "malloc_usable_size" was only recommended for use for statistics before the change in man page: "Although the excess bytes can be overwritten by the application without ill effects, this is not good programming practice:" and "The main use of this function is for debugging and introspection". The new version makes it clearer. You can find the change here: https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/...

Also no code is "actively broken" by a documentation change. If it happened to work before it still works today. Also I do not see how __builtin_dynamic_object_size is broken. It works as intended and can be used with conforming code just fine. It is simply not compatible with some questionable use of "malloc_usable_size".

It's not the documentation change that's the problem. It's the fact that they changed implementation-defined behavior to undefined behavior in the first place (then changed the documentation to follow). Or equivalently, they changed "recommended" to "required".

In particular, the "without ill effects" is no longer true. It's possible to #ifdef to detect broken libc/compiler combinations, but I'm not confident that avoiding explicit use of __builtin_dynamic_object_size will prevent optimizations from taking advantage of false assumptions based on __attribute__((malloc)).