On Fri, 29 Mar 2024 07:59:05 GMT, Thomas Stuefe <stu...@openjdk.org> wrote:
>> While looking at this, I noticed that my question in >> https://github.com/openjdk/jdk/pull/14146#discussion_r1207078176 and >> followups had never been answered. Do you know the answers now? >> >> Quoting myself: >> >>> So, we do this only for malloc? Not for calloc, posix_memalign, realloc >>> etc? What about free? >>> Removing that define and hard-coding it here assumes ... pointers it >>> returns work with the unchanged free() and realloc() the system provides, >>> and will always do so. >>> I am basically worried that undefining malloc, even if it seems harmless >>> now, exposes us to difficult-to-investigate problems down the road, since >>> it depends on how the libc devs will reform those macros in the future. > > Other than that, and kind of depending on your answer: How important is it > that we catch every use of the original malloc? Can be safely mix the > original malloc with vec_malloc if logging is not involved? > > I am asking, because from that it depends whether this hunk needs to appear > right behind `#include <stdlib.h>` or whether we can move it into the middle > of the file together with the other AIX stuff. > > Because, if we move it into the middle of the file, we may miss any uses of > malloc that may happen in system headers (would be unusual for that to happen > but with IBM one never knows). Hi Thomas, I would like to get totally rid of this, because as I mentioned IBM already modified the `stdlib.h` header not using `#define malloc vec_malloc` any more (and all the other vec_... defines). We have to ask the adoptium colleagues at IBM if they already have raised their build environment by the 2 SP levels needed. In principle we had to do the same workaround for `calloc, free,...` too, but they didn't show up as errors in the logging files. These lines where never meant to stay for long. Just to be able to compile until IBM fixes the issue, which is done now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/18536#discussion_r1547465986
