Feature #10082: [PATCH] add ZALLOC* macros to reduce ALLOC + MEMZERO calls

• Status: Closed
• Assignee: normalperson (Eric Wong)
• Target version: 2.2.0

[normalperson (Eric Wong)]

This reduces code and binary sizes.
ZALLOC macros are accessible via public API for exts

OK to add this API? It should simplify some code and reduce typos.

[matz (Yukihiro Matsumoto)]

LGTM.

Matz.

[tad (Tadashi Saito)]

The basic policy of patch feels great, but why don't you name CALLOC?

I feel CALLOC is more straitforward because calloc(3) is in the standard and
ZALLOC(_N) already uses calloc().

[normalperson (Eric Wong)]

[e-mail] wrote:

The basic policy of patch feels great, but why don't you name CALLOC?

I feel CALLOC is more straitforward because calloc(3) is in the standard and
ZALLOC(_N) already uses calloc().

I considered ZALLOC_N == CALLOC, but the arguments are reversed
for calloc(3), so I didn't want to risk that confusion, either.

I chose ZALLOC based on kzalloc/kmem_cache_zalloc in the Linux kernel.

On a related note: maybe RB_ZALLOC or RUBY_ZALLOC would be better, but
that would be inconsistent with existing ALLOC(_N) and REALLOC_N, too.

Naming is hard :<

matz/ko1 can make the final decision.

I'll commit in a day or so if we cannot decide, the name may still
change after commit.

[tad (Tadashi Saito)]

I considered ZALLOC_N == CALLOC, but the arguments are reversed
for calloc(3), so I didn't want to risk that confusion, either.

I agree with your concern. ZALLOC may be better.

(My only concern is that zlib uses "zalloc" as its API, but we will
not have to worry about it:
https://github.com/ruby/ruby/blob/543b402/ext/zlib/zlib.c#L609 )

[nobu (Nobuyoshi Nakada)]

Tadashi Saito wrote:

(My only concern is that zlib uses "zalloc" as its API, but we will
not have to worry about it:
https://github.com/ruby/ruby/blob/543b402/ext/zlib/zlib.c#L609 )

How about 0ALLOC()? ;)

[normalperson (Eric Wong)]

• Status changed from Open to Closed
• Assignee changed from ko1 (Koichi Sasada) to normalperson (Eric Wong)

r46952