Re: C 99 compiler access

From: Stewart Brodie (stewart.brodie_at_ntlworld.com)
Date: 09/11/04 

Date: Fri, 10 Sep 2004 23:51:58 GMT

"Paul D. Smith" <psmith@nortelnetworks.com> wrote:

> %% Niklas Matthies <usenet-nospam@nmhq.net> writes:
>
> nm> I'm not sure. :) I guess I wanted to point out that "all you have
> nm> to do is ..." introduces a portability problem. And just for
> nm> reliably allocating some piece of memory.
>
> Well, malloc() can't be implemented in portable C anyway of course.

We're not talking about implementing malloc in portable C - it's part of the
standard library. It's reasonable to assume that the standard library will
be implemented to integrate (efficiently) with the execution environment
which will almost certainly mean an environment-specific implementation. The
concern is that library implementations are not implementing the required
semantics (although I also accept that the C library implementations may in
turn be being stymied by the environment to some extent).

> Yes, if you wanted to write a 100% portable, 100% foolproof wrapper for
> malloc() you wouldn't be able to make use of this capability. You can
> write a reliable POSIX-portable version, though, and/or you can make a
> very conservative assumption and write every 256th byte and call it good.

"Reliable on POSIX only", "very conservative". Neither of these equates to
"portable" as far as I'm concerned.

What other standard library routines would you not mind getting lies back
from? Douglas A Gwyn mentioned the file access functions in another
article. What if fopen() returned a valid non-NULL handle but then just
caused a crash when you tried to read data from it. In fact, it is quite
possible that this behaviour can occur if the C library's stdio buffering is
using malloc to allocate the buffer memory. You open the file, get a valid
handle, you're not at the end of the file, the file is buffered, you call
getc() and a crash occurs (in __filbuf or whatever the buffer filling
routine is called) because the buffer was "successfully" allocated yet the
memory wasn't actually available. If it had been told that memory wasn't
available in the first place, __filbuf (or whatever) could have disabled
buffering on the FILE stream or the fopen() could have been failed in the
first place or something.

> Heck, even if you are ridiculously conservative and write every 5th byte
> that's still only 20% of the effort it would take to write all of them

To be honest, the chances are that memset would be more efficient than that
on many systems (although devious implementations could end up doing
something sneaky with page mapping and copy-on-write that defeats it). But
we're talking about having to take silly, timewasting and
implementation-specific measures just to ensure that the library is
implementing the required semantics. 

-- 
Stewart Brodie

Relevant Pages

  • Re: Dealing with naive malloc() implementations
    ... Were there implementations where this strategy (or something ... A "buddy system" malloc ... fragmentation can cause allocation failure when memory is ... but at a PPOE I did a fairly sizeable amount of work ...
    (comp.lang.c)
  • Re: execution time becomes unpredictable?!
    ... > performance and real implementations of memory heaps *really do* ... > do exist Oimplementations of malloc/free (and realloc, ... As far as I know, gcc, ... > because its open source and "Lea" malloc implementation is reasonably ...
    (comp.lang.c)
  • Re: Benchmark: STLs list vs. hand-coded one
    ... if you bother to check the pointer from malloc or use newand throw ... buffer to 640MBytes. ... To support your efficient memory management you limit symbol size to ... Yes you could require the compiler to jump ...
    (comp.arch.embedded)
  • Re: NTFS - Kernel memory leak in driver for kernel 2.4.28?
    ... I should say that the malloc() succeeds, but the 16mb I need for the ... buffer are not available. ... memory tied up in the inode and dentry cache. ... kernel attempts to use for the dentry/inode cache, or make it much, ...
    (Linux-Kernel)
  • Re: style question,itoa
    ... sensible to have the caller pass in a buffer. ... technically useless malloc and free calls, ... priori when memory allocations would fail. ...
    (comp.unix.programmer)