Re: Confused with malloc

From: The Real OS/2 Guy (os2guy_at_pc-rosenau.de)
Date: 01/04/04 

Date: Sun, 4 Jan 2004 15:35:16 +0000 (UTC)

On Sun, 28 Dec 2003 23:08:04 UTC, Kevin Goodsell
<usenet1.spamfree.fusion@neverbox.com> wrote:

> #define ALLOC(type) (type *)malloc(sizeof(type))

Makes bad things much bader. Whenever you frget to #include stdlib
your gets no warning but garbidge. malloc without prototyppe gets
interpreted as int mall() and this gets you code like:

1. call malloc
2. convert the value now in the place a function returned int to a
pointer of type the cast requires
3. later you'll dereference this garbidge - causing some undefined
behavior

Not every compiler uses one and the same location with exactly the
same number of bits for int and pointer to something.

So casting the return value <pointer to void> to something else means
invoking undefined behavior in any case even when the compiler does
send a diagnostic because YOU have forced the compiler to avoid any
diagnostic by telling him I KNOW THAT THE INT malloc returns IS in
reality a pointer - whereas it was YOU bug to avoid #include
<stdlib.h> - so the compiler will thing: "ok, the ill guy in front of
the screen knows that I can't know what malloc() does really, becaue
he has not telled me how to find the prototype. So I will assume that
it returns int and ignore anything that is on the place a function
returns void* has modified. It would be garbidge - but as the guy
tells me I will suppress any warning and transform that garbidge to be
a pointer of xy. Hopefully the program will crash some thousend lines
of source later."

Don't come with: but in C++.... because when you writes C++ then you
have to avoid the malloc family completely, you fave to use new/delete
instead. 

-- 
Tschau/Bye
Herbert
Visit http://www.ecomstation.de the home of german eComStation

Relevant Pages

  • Re: about the array
    ... 3- If you cast to the wrong type by accident, ... are malloc and free. ... the compiler should issue a diagnostic - gcc ... unknown set of arguments, and return an int. ...
    (comp.lang.c)
  • Re: why still use C?
    ... >>type of the object pointed to by a pointer differs from the type that I, ... >>the programmer, know to be the real type pointed at. ... When you're using implementation defined behaviour, the compiler ... I would argue that the malloc() is just such a case. ...
    (comp.lang.c)
  • Re: How does C cope if architecture doesnt address bytes?
    ... >>which the malloc() call occurs, figure out the type of the pointer which ... alignment in the implementation, rather than in either part of it. ... compiler and library are so strictly separate that there is no ... # The pointer returned if the allocation succeeds is suitably aligned so ...
    (comp.lang.c)
  • Re: Help. What is the error?
    ... int main ... check if malloc has succeeded before using it. ... If param put in the cast to shut the compiler up then it just goes to show *why* you should never put in a cast to shut the compiler up, you only put in casts when you understand *why* the compiler complained and exactly what the effect will be. ... So malloc returns a 64 bit pointer, but when main was compiled the compiler assumed it would be getting a 32 bit int, so it only grabs half of the address and then converts that in to a pointer which obviously produces a garbage value. ...
    (comp.lang.c)
  • Re: forwards declarations!
    ... h, long m, int w, int l); ... compiler obviously doesn't. ... LRESULT callerFunction(HWND, long, WPARAM, LPARAM), HWND ... Not quite the same as straight forwards function pointer usage. ...
    (microsoft.public.vc.language)