https://bugs.ruby-lang.org/https://bugs.ruby-lang.org/favicon.ico?17113305112014-07-23T06:00:30ZRuby Issue Tracking SystemRuby master - Feature #10082: [PATCH] add ZALLOC* macros to reduce ALLOC + MEMZERO callshttps://bugs.ruby-lang.org/issues/10082?journal_id=479732014-07-23T06:00:30Zmatz (Yukihiro Matsumoto)matz@ruby.or.jp
<ul></ul><p>LGTM.</p>
<p>Matz.</p> Ruby master - Feature #10082: [PATCH] add ZALLOC* macros to reduce ALLOC + MEMZERO callshttps://bugs.ruby-lang.org/issues/10082?journal_id=479742014-07-23T06:32:23Ztad (Tadashi Saito)
<ul></ul><p>The basic policy of patch feels great, but why don't you name CALLOC?</p>
<p>I feel CALLOC is more straitforward because calloc(3) is in the standard and<br>
ZALLOC(_N) already uses calloc().</p> Ruby master - Feature #10082: [PATCH] add ZALLOC* macros to reduce ALLOC + MEMZERO callshttps://bugs.ruby-lang.org/issues/10082?journal_id=479752014-07-23T07:22:51Znormalperson (Eric Wong)normalperson@yhbt.net
<ul></ul><p><a href="mailto:tad.a.digger@gmail.com" class="email">tad.a.digger@gmail.com</a> wrote:</p>
<blockquote>
<p>The basic policy of patch feels great, but why don't you name CALLOC?</p>
<p>I feel CALLOC is more straitforward because calloc(3) is in the standard and<br>
ZALLOC(_N) already uses calloc().</p>
</blockquote>
<p>I considered ZALLOC_N == CALLOC, but the arguments are reversed<br>
for calloc(3), so I didn't want to risk that confusion, either.</p>
<p>I chose ZALLOC based on kzalloc/kmem_cache_zalloc in the Linux kernel.</p>
<p>On a related note: maybe RB_ZALLOC or RUBY_ZALLOC would be better, but<br>
that would be inconsistent with existing ALLOC(_N) and REALLOC_N, too.</p>
<p>Naming is hard :<</p>
<p>matz/ko1 can make the final decision.</p>
<p>I'll commit in a day or so if we cannot decide, the name may still<br>
change after commit.</p> Ruby master - Feature #10082: [PATCH] add ZALLOC* macros to reduce ALLOC + MEMZERO callshttps://bugs.ruby-lang.org/issues/10082?journal_id=479832014-07-23T10:58:45Ztad (Tadashi Saito)
<ul></ul><blockquote>
<p>I considered ZALLOC_N == CALLOC, but the arguments are reversed<br>
for calloc(3), so I didn't want to risk that confusion, either.</p>
</blockquote>
<p>I agree with your concern. ZALLOC may be better.</p>
<p>(My only concern is that zlib uses "zalloc" as its API, but we will<br>
not have to worry about it:<br>
<a href="https://github.com/ruby/ruby/blob/543b402/ext/zlib/zlib.c#L609" class="external">https://github.com/ruby/ruby/blob/543b402/ext/zlib/zlib.c#L609</a> )</p> Ruby master - Feature #10082: [PATCH] add ZALLOC* macros to reduce ALLOC + MEMZERO callshttps://bugs.ruby-lang.org/issues/10082?journal_id=479932014-07-23T12:45:04Znobu (Nobuyoshi Nakada)nobu@ruby-lang.org
<ul></ul><p>Tadashi Saito wrote:</p>
<blockquote>
<p>(My only concern is that zlib uses "zalloc" as its API, but we will<br>
not have to worry about it:<br>
<a href="https://github.com/ruby/ruby/blob/543b402/ext/zlib/zlib.c#L609" class="external">https://github.com/ruby/ruby/blob/543b402/ext/zlib/zlib.c#L609</a> )</p>
</blockquote>
<p>How about <code>0ALLOC()</code>? ;)</p> Ruby master - Feature #10082: [PATCH] add ZALLOC* macros to reduce ALLOC + MEMZERO callshttps://bugs.ruby-lang.org/issues/10082?journal_id=480532014-07-26T07:04:39Znormalperson (Eric Wong)normalperson@yhbt.net
<ul><li><strong>Status</strong> changed from <i>Open</i> to <i>Closed</i></li><li><strong>Assignee</strong> changed from <i>ko1 (Koichi Sasada)</i> to <i>normalperson (Eric Wong)</i></li></ul><p>r46952</p>