revenge of CALLOC_STRUCT

Marek Olšák maraeo at
Tue Dec 28 00:18:16 UTC 2021

I remember that it wasn't unusual on Windows to define malloc, calloc,
strdup, and free macros to redirect those calls to custom wrappers. That
would eliminate the need to have non-standard names like MALLOC.

There is also the pipe_reference debug code. Is anybody using that?


On Sun., Dec. 26, 2021, 05:37 Jose Fonseca, <jfonseca at> wrote:

> 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]
> [2]
> ------------------------------
> *From:* Dave Airlie <airlied at>
> *Sent:* Wednesday, December 22, 2021 22:35
> *To:* mesa-dev <mesa-dev at>; Jose Fonseca <
> jfonseca at>; Brian Paul <brianp at>
> *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: <>

More information about the mesa-dev mailing list