Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > xmalloc

Reply
Thread Tools

xmalloc

 
 
Malcolm McLean
Guest
Posts: n/a
 
      06-27-2007

"CBFalconer" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Eric Sosman wrote:
>> Keith Thompson wrote On 06/26/07 00:05,:
>>

> ... snip ...
>>>
>>> The behavior of xmalloc is still *consistent* with the allowed
>>> behavior of malloc; no portable code can assume that malloc(0)
>>> can return a non-null result.

>>
>> malloc() is permitted to call exit()? When did that happen?

>
> He must be using Microsoft compilers
>

I accidentally created an infinite loop making a small allocations with
Microsoft's free C compiler.
It hung the entire machine for about two minutes, but allowed me to kill the
offending process, and recovered after about another minute.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
 
 
 
Malcolm McLean
Guest
Posts: n/a
 
      06-27-2007

"Christopher Benson-Manica" <(E-Mail Removed)> wrote in message
news:f5p2a7$n3e$(E-Mail Removed)...
> Harald van D?k <(E-Mail Removed)> wrote:
>
>> malloc(0) can make sense, but is allowed by the standard to either return
>> NULL or non-NULL on success. Because of this, xmalloc(0) calls malloc(1)
>> so
>> that a successfull allocation will always return non-NULL.

>
> I take about half of this point. While the code as written did indeed
> need to distinguish between failure to allocate non-zero bytes, and
> successful allocation of zero bytes (a fact which I missed), it's not
> clear to me that xmalloc()'s clients gain anything by essentially
> having all calls to malloc(0) replaced by malloc(1). The pointer
> returned by malloc(0), if not NULL, can't be used to access an object
> anyway, so from xmalloc()'s clients' perspectives, it doesn't much
> matter whether xmalloc(0) returns NULL or not:
>
> void *xmalloc( size_t sz ) {
> if( sz == 0 ) {
> return NULL;
> }
> /* ... */
> }
>
> May as well save the call to malloc(0), if you ask me.
>

There's quite a strong case for that.
With standard malloc() the rule is an easy way of introducing a bug, as you
write

char *buff = malloc(width * height);
if(!buff)
{
/* failure code */
}

however maybe you want to be able to handle zero-dimensioned tables in
normal flow control.

However with xmalloc() we never need the check, so the problem doesn't
arise.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

 
Reply With Quote
 
 
 
 
Ben Pfaff
Guest
Posts: n/a
 
      06-27-2007
"Malcolm McLean" <(E-Mail Removed)> writes:

> With standard malloc() the rule is an easy way of introducing a bug,
> as you write
>
> char *buff = malloc(width * height);
> if(!buff)
> {
> /* failure code */
> }
>
> however maybe you want to be able to handle zero-dimensioned tables in
> normal flow control.


Another peril of such code is the tendency to forget that width *
height can overflow. I used to ignore this possibility entirely;
these days, I generally use helper functions that carefully check
multiplications and additions for overflow.
--
Ben Pfaff
http://benpfaff.org
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
xmalloc.c - my xmalloc vippstar@gmail.com C Programming 11 02-20-2008 12:34 AM
xmalloc string functions Kelsey Bjarnason C Programming 240 02-07-2008 04:11 AM
Multi-threaded C++, new, and xmalloc Tim Hollingsworth Ruby 4 11-24-2006 05:02 PM
[OT?] xmalloc Jeff C Programming 10 07-07-2003 05:14 PM



Advertisments