Hi Charles.

:>As I understand it, when malloc allocates a block of memory, it has to mark
:>that block some how so that free will know how much memory to free.  The
:>pointer that malloc returns identifies the block and information about the
:>block.  It it the address of the block that is important, so doing something
:>like changing the variable that has the address of the block is unimportant.
:>However, changing the address malloc returns means losing access to the
:>information about how the block was allocated.

If you are interested, here is a portion of my malloc/free code
(taken from .h file):

#ifdef DEBUG
   #define FREESIG 0x12345678L
   #define USEDSIG 0x87654321L
   #define NONESIG 0x00000000L
#endif

#pragma pack(1)
typedef struct _memBlock {
#ifdef DEBUG
   ULONG             ulSig;
#endif
   ULONG             ulSize;
   struct _memBlock *next;

#pragma pack()

Best regards,
Rok Papez.

Student at Faculty of Computer and Information Science,
University of Ljubljana.

--

        return (char *)malloc(100);  /* malloc(100 * sizeof(char)) */

--
All of reality is just a simulation running in God's computer.  So chill.

// If you'd like to drop me a note: net dot earthlink at huddler
--

Yours,

--

When considering what is and is not an error, it helps to know what
malloc() and free() might be doing.

In K&R's example of how to implement these functions (ed.2, section 8.7),
malloc() accounts for memory in the following way. (Use a fixed-width font
like Courrier to view the diagram.)

                  HEADER
    _________________^_________________
   /                                   \

   ***********************************************************************
   *                 *                  *                                *
   *  POINTER TO     *  SIZE OF THE     *  BLOCK WHOSE ADDRESS IS        *
   *  NEXT FREE      *  BLOCK RETURNED  *  RETURNED BY malloc()          *
   *  BLOCK          *  TO THE USER     *                                *
   *                 *                  *   array of at least the        *
   *  Header *       * unsigned int     *  requested size                *
   *                 *                  *                                *
   ***********************************************************************

   ^  ^                                 ^  ^
   |  |                                 |  |
   |  |                                 |  |
   | ((Header *) (foo_p+1)) - 1      foo_p |
   | MISALIGNED POINTER                    |
   |                                      foo_p+1
  ((Header *) foo_p) - 1
  CORRECT ADDRESS OF HEADER

The diagram shows an area of memory containing the block whose address is
returned by malloc(), plus some adjacent house-keeping information used by
malloc() and free(). The rough position of some relevant addresses is also
given.

free() expects to be able to find the header for the block whose address
it is passed just before this in memory, i.e. at address (Header *)
foo_p-1. But in the above code, free() is actually passed the address
foo_p+1 rather than foo_p. free() will calculate the location of the start
of the header incorrectly, leading to misbehaviour at run-time.

This is just one way malloc() and free() might be implemented, but gives
insight into how free()-ing an address NOT returned by malloc(), calloc()
or realloc() can wreak havoc.

Daniel Barker,
Biocomputing Research Unit,
Institute of Cell and Molecular Biology,
Swann Building,
King's Buildings,
Mayfield Road,
Edinburgh
EH9 3JR
UK
--

: > Case 3: a combination, with function calls
: >
: >  char* get_mem(void)
: >  {
: >          return malloc(100);
: >  }

: I'm just being {*filter*}here, but

        Presumably you mean "{*filter*}retentive", but now maybe _I'm_... :-)

:       return (char *)malloc(100);  /* malloc(100 * sizeof(char)) */

        Exactly what does this accomplish? Are there still systems in wide
use that declare malloc as something other than "void *malloc( size_t )"?
If not, I'd like to make a plea for using the committe-given ability to
assign a void * to any data pointer without a cast. Why? because "{*filter*}"
casts are often a good tip-off to dubious code. If you get used to sprinkling
casts through your code to "shut the compiler up", then someday you will
cast an int** to an int* and since you used a cast, to say "Shut up,
compiler, I know what I'm doing", but you _don't_ really know what you're
doing, you will be in a world of hurt. I was under the impression that
void * was invented partially for this purpose, but I'd gladly hear a
reasoned argument to the contrary.

        My rule, not that I don't break it once in a while because I
am a fallible being, is "no casts outside well-checked macros". Of
course, I have to violate it in, e.g. cases where a function is declared
to return a char * and take a const char * (strchr() springs to mind)
The inability to specify such functions (or am I just stupid, please
enlighten me) to "inherit" the qualifiers of their arguments is just
one of those prices I pay for programming in a ubiquitous language.

                                        Mike

--

[other okay cases deleted]

: > Case 3: a combination, with function calls
: >
: >  char* get_mem(void)
: >  {
: >          return malloc(100);
: >  }

: I'm just being {*filter*}here, but

:       return (char *)malloc(100);  /* malloc(100 * sizeof(char)) */

Having such a functions is a good thing for allocating and initilizing
memory for an "object", such as a structure. The subsequent release_mem()
function is good for the cleanup...

: >  void release_mem(char* in_p)
: >  {
: >          free(in_p);
: >  }      

--

|| Research Programmer
--

         release_mem(foo_p-1);

would be fine.

--
-----------------------------------------


-----------------------------------------
--

I acquired the habit, long ago, of explicitly casting the type from
malloc(), calloc(), and realloc().  

I agree that it's not necessary these days.  Whether or not it represents
dubious code, however, is another matter.  I tend to think that the
programmer doing such a thing is specifying exactly what s/he wants to
occur, committee or no committee.  Much like expressing

        (void)printf( .... ) ;

does.  

As with any use of power, an explosion can result if the person using it
is an idiot.

--
All of reality is just a simulation running in God's computer.  So chill.

// If you'd like to drop me a note: net dot earthlink at huddler
--

--
All of reality is just a simulation running in God's computer.  So chill.

// If you'd like to drop me a note: net dot earthlink at huddler
--

[ ... ]

        x = 1;

is _obviously_ BAD!  To be explicit, what you really meant was that
you were going to assign 1 to x, and then _ignore the value that
produced_:

        (void)x=1;

if one makes any sense at all, so does the other.  Of course, in
reality, both are absurd...

--
    Later,
    Jerry.

The Universe is a figment of its own imagination.
--

        hp

--
   _  | Peter J. Holzer             | But now it's
|_|_) | Sysadmin WSR                | implementation-defined

__/   | http://wsrx.wsr.ac.at/~hjp/ |     -- Clive Feather
--

...

         (void)(x=1);

:-)

--
-----------------------------------------


-----------------------------------------
--

|>   (void)x=1;

This must be
        (void)(x=1);

--
Andreas Schwab                                      "And now for something


--

        (void)(x = 1);

The cast has higher operator precedence than the assignment. :)

You are right of course; if one is going to cast the discarded return
values of functions like printf(), then to be consistent, one should
cast all expression-statements to void. This is, of course, absurd
to say the least.  I also don't see how it can prevent errors.

An error that could arise out of a failure to observe the return
value of a function falls into two categories: the function
could return a pointer (or other reference) to some object that
was allocated in the function, in which case a memory leak results
from ignoring the return value; and the function could return an error
indicator which would cause a subsequent operation to fail.
The first of these two cases is rare because the return value is
of central interest to the surrounding code: it represents some
allocated object, file or what have you, which is subject to
further operations.

The habit of writing (void) casts will help with neither of these
errors, since it only encourages such discarding.

Occurences of (void) printf(/*...*/) in acual programs are evidence
of this. A robust program does in fact check the return value of
printf, which is negative if an error occured. Such a check could
be the difference between a program which silently discards
data and one which reports that an error has occured (because
the disk filled up, say).
--