Alejandro Colomar

> I think`MUTT_MEM_REALLOC` could derive the third param from the first one. Actually, I even think it _should_. Unless I'm missing a use case where you want a different type...

Here are some cases that I handled specially: ```c $ grep -rnI -A1 allocarray | grep -v ^mutt/memory | uniq mutt/array.h:192: ((mutt_mem_reallocarray( \ mutt/array.h-193- &(head)->entries, (num) + ARRAY_HEADROOM, ARRAY_ELEM_SIZE(head))), \...

> > Why did I add that `type` parameter if it's redundant, you may ask? > > > > * Consistency with the other macros > > * Allow grep(1)ing...

> i don't really buy the "grepability" argument (any more) - modern IDEs have "find usages" functionality which serves the purpose just fine. I consciously choose to not use IDEs....

> > I consciously choose to not use IDEs. > > well, that's your choice. as a maintainer, i wouldn't allow my code to be "uglified" for the sake of...

> also, looking practically at this particular context: if you can omit the type from the macro call, that's because you have it spelled out in a declaration rather nearby....

> > You'd need to find the definition of struct s > > well, yes. that's literally one keypress with modern tooling. > > my experience is that whenever i'm...

> > But I don't think using the type uglifies, does it? > > that's sort of philosophical, and strays into the AAA discussion from the C++ world. I'm interested...

> > * A macro that deduces the type from `ptr` would be something like this: > > `./mutt/memory.h:#define MUTT_MEM_REALLOC(ptr, n) \ ( \ mutt_mem_reallocarray(ptr, n, sizeof(typeof(**(ptr)))) \ )` >...

@gahr > I don't think evaluating a vla twice is an issue, anyway. I tend to agree, but I'm skeptic, and prefer to avoid it at all. It's probably just...