Re: gwmem patches

It is not the same. You have at least 2 function calls to do the job of 
single one. I strongly also suspect that the binary code is different, 
unless of course you claim that calloc is implemented as a macro calling the 
2 functions. It is an overhead, and the code is more complex. If it's not 
been used, then it should be removed from the protected functions, and let 
each programmer decide for himself.

Lastly I don't see the point. What's the hurt? At worst next time a 
developer needs it, he can use it. Nobody is forcing anyone to use calloc, 
and I wish the same, that no one would force me to use malloc + memset 
instead.

Nikos
----- Original Message ----- 
From: "Vincent CHAVANIS" <[email protected]>
To: <[email protected]>
Sent: Friday, April 03, 2009 3:26 PM
Subject: Re: gwmem patches


Hi,

i'm also as +0
Calloc is malloc+memset

The only *unsignificant* case where we could use calloc is
to prevent redundant code on when allocating multiples elements
by passing the 2 args.

Vincent


Alexander Malysh a ΞΉcrit :
> Hi,
>
> 2009/4/3 Nikos Balkanas <[email protected] <mailto:[email protected]>>
>
>     Hi,
>      Thanx for your fast response. Must be going crazy reviewing all
>     these patches :-).
>      1) Thread.h: Hmmm I thought I got the function prototype correctly.
>     Well it worked for me. I will have to check with the cvs.
>     2) OK.
>     3) Because calloc is undeffed in gwmem.h. If we try to use it it
>     prints "do_not_call_calloc_directly". Yet no gw_calloc exists!
>     What's a poor programmer to do? :-(. Well you could use malloc +
>     memset (x, 0, n), but then so you could in ANSI C, yet calloc exists
>     I suspect it si more performance related rather than simplicity. It
>     is a normal C function, and I don't the reason to undef it without
>     giving its counterpart.
>
>
> it's not a question whether it exists in gwlib or not. it's just a 
> question, why you use it? I know such function but never used it before 
> and never missed it because malloc + memset does the same for me and it 
> clear for reader what's going on. And from
> kernel perspective it's the same malloc + memset...
> Give me at least one argument why we _really_ need calloc?
>
> My vote is 0.
> How about other developers? do we need calloc?
>
>      Let me know if it is OK with calloc, so that I can submit it
>     together with strdup.
>      BR,
>     Nikos
>
>         ----- Original Message -----
>         *From:* Alexander Malysh <mailto:[email protected]>
>         *To:* Nikos Balkanas <mailto:[email protected]>
>         *Cc:* [email protected] <mailto:[email protected]>
>         *Sent:* Friday, April 03, 2009 12:21 AM
>         *Subject:* Re: gwmem patches
>
>         Hi,
>
>         thanks for your patch but:
>
>         1) thread.h patch was wrong. I fixed it in CVS.
>         2) gw_strdup optimisation looks OK, please submit as extra patch
>         3) gw_calloc, hmm... I don't really see any advantage of this
>         one. because
>         x = gw_malloc(count*size);
>         memset(x, 0);
>             do the same. why do we need this?
>
>         Thanks,
>         Alex
>
>         Am 02.04.2009 um 19:09 schrieb Nikos Balkanas:
>
>>         Hi,
>>          An assortment of small patches to make check_memory_leaks work
>>         better:
>>          1) Added support for gw_calloc, which is #undefed but not 
>> defined
>>         2) Replaced strcpy with memcpy in gw_strdup for better efficiency
>>         3) Added function prototype in thread.h for
>>         mutex_make_measured so that MUTEX_STATS compile correctly.
>>          Please decide and vote.
>>          BR,
>>         Nikos<kannel.diff>
>
>

-- 
Telemaque - 06560 SOPHIA-ANTIPOLIS - (FR)
Service Technique/Reseau - NOC
Direction du Developpement xMS+
http://www.telemaque.fr/
[email protected]
Tel : +33 4 92 90 99 84 (fax 9142)