[vox-tech] malloc() is ... old school?

[Jeff Newmiller]

On Fri, 21 Mar 2003, Tim Riley wrote:

> 
> 
> "Micah J. Cowan" wrote:
> 
> > On Thu, Mar 20, 2003 at 04:52:15PM -0800, Tim Riley wrote:
> > >
> > >
> > > "Micah J. Cowan" wrote:
> > >
> > > > On Thu, Mar 20, 2003 at 10:15:43AM -0800, Tim Riley wrote:
> > > > >
> > <snip>
> > >
> > > The vulnerability with malloc() occurs when working with pointers.
> > > It's common to test if a pointer has been set
> > > by placing it inside an "if" statement before referencing it.
> > > If you always use calloc(), all of your pointers will be
> > > initialized with zero.
> >
> > All bits zero != NULL. This is a common misbelief, which happens to be
> > true on a number of platforms. But it is not guaranteed to be true,
> > and is not on several platforms, though I conced that they are not the
> > mainstream. See:
> >
> >   Sec. 5 of the C FAQ: ~http://www.eskimo.com/~scs/C-faq/s5.html
> >
> >   Any number of comp.lang.c posts:
> >     http://groups.google.com/groups?as_q=NULL%20calloc%28%29&as_ugroup=comp.lang.c
> >
> >   Especially this one by the author of the FreeBSD C Library (last paragraph):
> >     http://groups.google.com/groups?q=NULL+calloc()+group:comp.lang.c+author:Chris+author:Torek&selm=18764%40dog.ee.lbl.gov

Tim, I don't get the impression you actually read this last URL.

> >
> >
> 
> "man calloc" on a Linux machine says bluntly:
>        calloc() allocates memory for an array of  nmemb  elements
>        of  size bytes each and returns a pointer to the allocated
>        memory.  The memory is set to zero.
> 
>        malloc() allocates size bytes and returns a pointer to the
>        allocated memory.  The memory is not cleared.

I am not sure what you are trying to demonstrate by citing the man pages
from a particular (unspecified) distribution... because such documentation
can at best be specific to that installation, and at worst may indicate
nothing about how the Standard C _library_ should behave.

That said, I haven't seen anyone asserting that calloc _doesn't_ set the
memory to zero.  Micah's point is that a pattern of zero bits is not the
same as NULL in every case.  I would warn that this is also technically
true for floating point values. (Subtle point: assigning the numeric value
of zero to a pointer _is_ required to result in a NULL pointer, but the
compiler may treat this as a special case.)

> 
> 
> > > For the following example
> > > it's clear that a core dump might occur; however, if the program were
> > > 1000 lines long and the variables set in different locations, tracing
> > > could be a bear.
> > >
> > > typedef struct
> > > {
> > >     char *name;
> > >     char *address;
> > >     char *city;
> > >     char *state;
> > >     char *zip_code;
> > > } PERSON;
> > >
> > > int main( int argc, char **argv )
> > > {
> > >     PERSON *person = malloc( sizeof( PERSON ) );
> > >
> > >     person->name = "fred";
> >
> > A core dump could occur right here, with or without calloc(),
> > considering you didn't check malloc()'s return.
> 
> Allocation error checking was intentionally left out for simplicity.
> 
> >
> >
> > >     if ( person->name && person->zip_code )
> > >     {
> > >         printf( "For person = %s, got zip code = %s\n",
> > >                 person->name, person->zip_code );
> > >     }
> > > }
> > >
> > > If calloc() had been used, no one would have noticed the delay and no
> > > core would be dumped.
> >
> > Provided that one is using a system on which NULL happens to be
> > all-bits-zero.
> 
> What ANSI C implementation are you referring to here?

The issue is what hardware the ANSI C implementation has to work with.

Apparently both Data General and Control Data Corporation both made
hardware that behaved this way.  Also apparently they included some
run-time code to fix pointers that made this assumption because it was
just too pervasive in available source code.

http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=486%40sas.UUCP

There may be other examples... it isn't really that important to me.  What
is important is what the Standard says.

> > Which we all are on this list, but can we guarantee
> > that the code you write won't be ported to such a system?
> >
> 
> Isn't this a Linux users group?

Yes.  What does that have to do with the hardware you run Linux on?

> What system are you referring to?

See above.  I have not encountered either of these systems... but I try to
be careful to segregate code that is system dependent from code that
conforms strictly to standards, as a matter of good practice.

There are thousands of application programming interfaces out there, and
using them creates dependencies.  Programming in the large leads you to
seriously consider how many APIs you want to depend on... because of
code bloat, and because of potential future porting efforts. Part of
succeeding at that is using your standard interfaces to their utmost... so
knowing Standard C is worthwhile no matter what system you use... even
Linux.

> Does it not have gcc? Is it open source so we can fix it?

Again, you are confusing software with hardware.

Remember... this discussion started when we were informed that a professor
asserted that malloc was not present in all C libraries so calloc should
be preferred.  Aside from the obvious problems of asserting that your C
code can be portable without adhering to the Standard (get a clue), this
presumes it is a good thing to work with multiple implementations of C
compilers.

Honestly, it is.

> >
> > And I submit that without the core dump, the bug of having forgotten
> > to set *person's fields just got much, much harder to track down.
> >
> 
> Core dumps are useful for tracking down bugs.

While I am not very comfortable with bunches of NULL pointers in records, 
I am not sure that depending on the garbage in a malloc'd memory block to
be non-NULL is a good idea either.

---------------------------------------------------------------------------
Jeff Newmiller                        The     .....       .....  Go Live...
DCN:<jdnewmil@dcn.davis.ca.us>        Basics: ##.#.       ##.#.  Live Go...
                                      Live:   OO#.. Dead: OO#..  Playing
Research Engineer (Solar/Batteries            O.O#.       #.O#.  with
/Software/Embedded Controllers)               .OO#.       .OO#.  rocks...2k
---------------------------------------------------------------------------