revenge of CALLOC_STRUCT

[Jose Fonseca]

I believe that as long as the CALLOC_STRUCT continue to get paired with right FREE call (or equivalent if these get renamed) either way should work for us.  Whatever option proposed gets followed, there's a risk these can get out of balanced, but the risk seems comparable.


For context, IIRC, the main reason these macros remain useful for VMware is the sad state of memory debugging tools on Windows.  AFAICT, best hope of one day deprecating this would be use AddressSanitizer, which is supported on MSVC [1], but unfortunately not yet on MinGW w/ GCC [2], and we rely upon a lot for day-to-day development, using Linux cross-compilation.  Using MinGW w/ Clang cross compiler seems be a way to overcome this difficulty, but that too was still in somewhat experimental state when I last tried it.


Jose

[1] https://devblogs.microsoft.com/cppblog/asan-for-windows-x64-and-debug-build-support/
[2] https://stackoverflow.com/questions/67619314/cannot-use-fsanitize-address-in-mingw-compiler
________________________________
From: Dave Airlie <airlied at gmail.com>
Sent: Wednesday, December 22, 2021 22:35
To: mesa-dev <mesa-dev at lists.freedesktop.org>; Jose Fonseca <jfonseca at vmware.com>; Brian Paul <brianp at vmware.com>
Subject: revenge of CALLOC_STRUCT

Hey,

Happy holidays, and as though to consider over the break,

We have the vmware used MALLOC/FREE/CALLOC/CALLOC_STRUCT wrappers used
throughout gallium.

We have ST_CALLOC_STRUCT in use in the mesa state tracker, not used in gallium.

Merging the state tracker into mesa proper, and even prior to this a
few CALLOC_STRUCT have started to leak into src/mesa/*.

Now I don't think we want that, but CALLOC_STRUCT is a genuinely
useful macro on it's own,
I'm considering just defined a calloc_struct instead for the
non-gallium use that goes with malloc/calloc/free.

Any opinions, or should mesa just get u_memory.h support for Xmas?

Dave.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20211226/38dcafa8/attachment.htm>