Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > Implementing Malloc()

Reply
Thread Tools

Implementing Malloc()

 
 
Mark McIntyre
Guest
Posts: n/a
 
      11-27-2007
CJ wrote:
> We were discussing implementing malloc(), in particular the following
> situation.
>
> Suppose the user requests 1Mb of memory. Unfortunately, we only have
> 512Kb available. In this situation, most mallocs() would return null.
> The huge majority of programmers won't bother to check malloc() failure
> for such a small allocation, so the program will crash with a SIGSEGV as
> soon as the NULL pointer is dereferenced.
>
> So why not just return a pointer to the 512Kb that's available?


Yike. Take this to the extreme. Imagine you only have one byte
available. Why not just return a pointer to that? How much use is /that/?

>It's
> quite possible that the user will never actually write into the upper
> half of the memory he's allocated,


Its also quite possible the programmer knew how much memory he needed,
and will be justifiably annoyed when his programme starts randomly failing.

 
Reply With Quote
 
 
 
 
Dik T. Winter
Guest
Posts: n/a
 
      11-27-2007
In article <(E-Mail Removed)> CJ <(E-Mail Removed)> writes:
....
> The idea is that instead of a guaranteed crash, isn't it better to make
> a last-ditch effort to save the program's bacon by returning a pointer
> to what memory there _is_ available? If the program's going to crash
> anyway, it's got to be worth a shot.


In that case there is no way a program can actually *check* whether there
was sufficient memory, which a well written program should do. The result
is probably a fault, but all kind of other nasty things can happen, like
completely wrong output.
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
 
Reply With Quote
 
 
 
 
J. J. Farrell
Guest
Posts: n/a
 
      11-28-2007
CJ wrote:
> On 26 Nov 2007 at 22:34, Eric Sosman wrote:
>> Not only does this implementation avoid the processing
>> overhead of maintaining potentially large data structures
>> describing the state of memory pools, but it also reduces
>> the "memory footprint" of every program that uses it, thus
>> lowering page fault rates, swap I/O rates, and out-of-memory
>> problems.

>
> All very amusing, but I think you and some of the other posters have
> misunderstood the context of the discussion.
>
> Of course an implementation of malloc should return a pointer to as much
> memory as requested whenever that's possible! The discussion was about
> the rare failure case. Typically, programs assume malloc returns a
> non-null pointer, so if it returns null on failure then the program will
> crash and burn.


Why do you think such incompetently written buggy programs are "typical"?

> The idea is that instead of a guaranteed crash, isn't it better to make
> a last-ditch effort to save the program's bacon by returning a pointer
> to what memory there _is_ available? If the program's going to crash
> anyway, it's got to be worth a shot.


No, blatantly and obviously not. It is better for the programmer's
incompetence to cause the program to stop execution immediately rather
than allow it to go on with random behaviour doing who knows how much
damage to what. How does, for example, corrupting a few gigabytes of
valuable archive data "save the program's bacon"?
 
Reply With Quote
 
MisterE
Guest
Posts: n/a
 
      11-28-2007

> The worst thing that can happen is that the programmer _does_ write to
> the end of the mallocated block. In this case, either there's a SIGSEGV
> again (no worse off than before), or if the 512Kb is in the middle of
> the heap malloc() is drawing from then the writes might well succeed,
> and the program can continue albeit with some possible minor data
> corruption.
>
> Do any implementations of malloc() use a strategy like this?


omg

this is dumbest thing I have read on the internet


 
Reply With Quote
 
Malcolm McLean
Guest
Posts: n/a
 
      11-28-2007
"J. J. Farrell" <(E-Mail Removed)> wrote in message
>
> No, blatantly and obviously not. It is better for the programmer's
> incompetence to cause the program to stop execution immediately rather
> than allow it to go on with random behaviour doing who knows how much
> damage to what. How does, for example, corrupting a few gigabytes of
> valuable archive data "save the program's bacon"?
>

It does depend what the program is. For instance with a videogame there is
no point exiting with an error message. You might as well ignore the error,
and there's a chance the player won't notice. If he does notice, it won't
spoil his enjoyment any more than an exit.
Unless of course you manage to corrupt his saved character which he's spent
two years of solid gameplay bringing up to a high level. Then people get
annoyed.

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

 
Reply With Quote
 
Keith Thompson
Guest
Posts: n/a
 
      11-29-2007
"Malcolm McLean" <(E-Mail Removed)> writes:
> "J. J. Farrell" <(E-Mail Removed)> wrote in message
>> No, blatantly and obviously not. It is better for the programmer's
>> incompetence to cause the program to stop execution immediately
>> rather than allow it to go on with random behaviour doing who knows
>> how much damage to what. How does, for example, corrupting a few
>> gigabytes of valuable archive data "save the program's bacon"?
>>

> It does depend what the program is. For instance with a videogame
> there is no point exiting with an error message. You might as well
> ignore the error, and there's a chance the player won't notice. If he
> does notice, it won't spoil his enjoyment any more than an exit.
> Unless of course you manage to corrupt his saved character which he's
> spent two years of solid gameplay bringing up to a high level. Then
> people get annoyed.


Even in that context, the proposed malloc implementation where a
request for 1024 kbytes can allocate just 512 kbytes and not report an
error doesn't seem particularly useful.

And if it is useful, you can always implement it on top of malloc *and
call it something else*.

--
Keith Thompson (The_Other_Keith) <(E-Mail Removed)>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
 
Reply With Quote
 
christian.bau
Guest
Posts: n/a
 
      11-29-2007
On Nov 28, 10:40 pm, "Malcolm McLean" <(E-Mail Removed)>
wrote:

> It does depend what the program is. For instance with a videogame there is
> no point exiting with an error message. You might as well ignore the error,
> and there's a chance the player won't notice. If he does notice, it won't
> spoil his enjoyment any more than an exit.


I once played "Who wants to be a millionaire" on a Playstation. The
program crashed at the 8,000 question. It would have been more
enjoyable if the program had crashed immediately.
 
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
Implementing Interface Gomathi ASP .Net 1 11-17-2005 03:09 PM
Need help implementing a proj on SPARTAN3 Riccardo Fregonese VHDL 2 01-03-2005 01:21 PM
Implementing the CORDIC algorithm without using Real Data Type Johnsy Joseph VHDL 2 10-29-2004 10:49 AM
Implementing E1 - E3 Dev VHDL 1 09-09-2004 09:06 AM
vhdl for implementing pre-fetch and an instruction cache Eqbal Z VHDL 3 11-16-2003 06:07 AM



Advertisments