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)
