# So many different mallocs - do we need them?

**URL:** <https://forum.graphviz.org/t/so-many-different-mallocs-do-we-need-them/493>\
**Category:** Dev\
**Created:** [January 5, 2021, 7:44pm UTC](https://forum.graphviz.org/t/so-many-different-mallocs-do-we-need-them/493 "2021-01-05T19:44:38Z")\
**Posts on this page:** 5\
**Page:** 1

<div class="post-metadata">

**Author:** ![Vithanco](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/vithanco/32/292_2.png) [@Vithanco](https://forum.graphviz.org/u/Vithanco)\
**Post date:** [January 5, 2021, 7:44pm UTC](https://forum.graphviz.org/t/so-many-different-mallocs-do-we-need-them/493/1 "2021-01-05T19:44:38Z")

</div>

I have a really odd problem that I described [here](https://stackoverflow.com/questions/65573639/difference-of-use-of-stack-memory-after-return-between-native-arm64-and-native). I try to get my head around this issue and came across this in [memory.h](https://gitlab.com/graphviz/graphviz/-/blob/master/lib/common/memory.h#L23):

```
#define NEW(t) (t*)zmalloc(sizeof(t))
#define N_NEW(n,t) (t*)gcalloc((n),sizeof(t))
#define GNEW(t) (t*)gmalloc(sizeof(t))

#define N_GNEW(n,t) (t*)gcalloc((n),sizeof(t))
#define N_GGNEW(n,t) (t*)calloc((n),sizeof(t))

```

and [later](https://gitlab.com/graphviz/graphviz/-/blob/master/lib/common/memory.h#L43):

```
extern void *zmalloc(size_t);
extern void *zrealloc(void *, size_t, size_t, size_t);
extern void *gcalloc(size_t nmemb, size_t size);
extern void *gmalloc(size_t);
extern void *grealloc(void *, size_t);

```

I am not really into this memory allocation business (spoiled by the likes of Java and Swift), but what are we doing here? Why so many new versions? Why always so inspirational names? 🙂 Can these even work with each other? Should we try to harmonise?

---

<div class="post-metadata">

**Author:** ![mark](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/mark/32/84_2.png) [@mark](https://forum.graphviz.org/u/mark)\
**Post date:** [January 5, 2021, 9:21pm UTC](https://forum.graphviz.org/t/so-many-different-mallocs-do-we-need-them/493/2 "2021-01-05T21:21:17Z")

</div>

realloc/calloc/malloc do different things. I’m not sure about the other letters in front of the names or the macros though.

---

<div class="post-metadata">

**Author:** ![scnorth](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/scnorth/32/89_2.png) [@scnorth](https://forum.graphviz.org/u/scnorth)\
**Post date:** [December 26, 2021, 10:45pm UTC](https://forum.graphviz.org/t/so-many-different-mallocs-do-we-need-them/493/3 "2021-12-26T22:45:27Z")

</div>

6 posts were split to a new topic: [Potential language extension for graph object classes - motivation, design](https://forum.graphviz.org/t/potential-language-extension-for-graph-object-classes-motivation-design/968)

---

<div class="post-metadata">

**Author:** ![scnorth](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/scnorth/32/89_2.png) [@scnorth](https://forum.graphviz.org/u/scnorth)\
**Post date:** [January 6, 2021, 10:57am UTC](https://forum.graphviz.org/t/so-many-different-mallocs-do-we-need-them/493/5 "2021-01-06T10:57:41Z")

</div>

It’s not even different mallocs - I think they are just macros or functions that wrap whatever malloc is around.

I realize that reliance on macros is passe and out of step with reasonable coding style today.

---

<div class="post-metadata">

**Author:** ![smattr](https://sea2.discourse-cdn.com/graphviz/user_avatar/forum.graphviz.org/smattr/32/85_2.png) [@smattr](https://forum.graphviz.org/u/smattr)\
**Post date:** [January 6, 2021, 4:04pm UTC](https://forum.graphviz.org/t/so-many-different-mallocs-do-we-need-them/493/7 "2021-01-06T16:04:03Z")

</div>

> [@Potential language extension for graph object classes - motivation, design](https://forum.graphviz.org/t/potential-language-extension-for-graph-object-classes-motivation-design/968/1):
>
> It’s not so important.

I will respectfully disagree with Stephen 🙂

Vithanco, my background is mostly C/C++ and I still had a very similar reaction to you when learning the code base. In 2020 I deleted as much of lib/vmalloc as I could and tried to reduce other malloc duplication across the tree. Let me try to answer your questions…

> [@Vithanco](#):
>
> Why so many new versions?

Some of these have slightly different purposes. There’s the three library functions Mark noted, then the “g” prefixed wrappers that exit on failure and the “z” prefixed ones that return pre-zeroed memory. As for why the macros like `N_NEW` are repeated in various parts of the code base, I assume when this code was written #includes were somehow expensive and to be avoided.

> [@Vithanco](#):
>
> Why always so inspirational names?

My interpretation of the prefixes is “g/G” = “global”, “N\_” = “new”, “z” = “zeroing”. This is terse, but pretty common in C code bases. I’ve seen the same named functions elsewhere.

> [@Vithanco](#):
>
> Can these even work with each other?

Yes. They all allocate from the same heap, with the exception of lib/vmalloc (“vm” prefixed functions) which is an [arena allocator](https://en.wikipedia.org/wiki/Region-based_memory_management). In the long term I would like to remove it completely.

> [@Vithanco](#):
>
> Should we try to harmonise?

Maybe. Some of these wrappers are useful. E.g. the `zmalloc` wrapper helps write more readable code. The “g” prefixed wrappers are also useful because many Graphviz allocations do not check the return value. None of this is really good practice, but we have to deal with the situation as it is.