delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/1998/01/02/02:22:08

Message-Id: <199801020720.JAA00178@ankara.duzen.com.tr>
Comments: Authenticated sender is <mitch AT ankara DOT duzen DOT com DOT tr>
From: "S. M. Halloran" <mitch AT duzen DOT com DOT tr>
Organization: User RFC 822- and 1123-Compliant
To: djgpp AT delorie DOT com
Date: Wed, 31 Dec 1997 12:31:44 +0200
MIME-Version: 1.0
Subject: Re: What does/doesn't need memory allocated?
In-reply-to: <34a9f503.0@kastagir.senet.com.au>

On 31 Dec 97, Richard Sim was found to have commented thusly:

> Hi, I just spent several days trying to get a routine working because I
> forgot to allocate 5 bytes of memory, and I was wondering if there are any
   ^^^^^^^^^^^^^^^^
  welcome to the club!

> programs/documents that tell you what needs to have memory allocated to it.
> i.e. Goes through your code and finds things that need memory allocated to
> them, or a text that explains things like this...
> Just if you didn't have to allocate memory all of the time...or if there was
> something that would tell you what you have to allocate memory for and what
> you don't :-).
> Oh well, if anyone knows of anything like this could they please tell me
> since I really need it. :-)
> 
> Also, if say you allocate a structure, do you have to do a free at the end
> of your program, or will it be totally free'd anyway? I know that you
> should, but must you?
> 

Since you have a Newsgroup: header in your message, I am assuming you 
have access to the newsgroups (at any rate, dejanews will be of use 
if you have web service as well).  I recommend getting the FAQ from 
the comp.lang.c newsgroup which is posted to that newsgroup fairly 
regularly.  I think there is an abridged version and a long 
version...get the latter.  As I recall, the abridged version is silly 
to have, especially since the regulars of that group are constantly 
griping that people going there ask too many fundamental 
questions...perhaps even those of the kind not in any FAQ.  The FAQ 
may tell you how to find programs that examine your use of the 
standard library functions which manage dynamic allocated storage. 

They may also tell you that you should develop a checklist for 
looking at your code which really doesn't require a program to ferret 
out problem areas:

1) use your editor's global substring search to find all text of the 
type 'alloc('...that should catch all the functions.  On a piece of 
paper, mark a shorthand for function and line number of the call.

2) now look for all occurrences of 'free('.  Try to find their 
matching 'alloc(' functions.  You may have a count of more 'alloc(' 
in the end than 'free(', but never more 'free(' than 
'alloc('...unless it comes at the end of main() perhaps and you like 
to see the possibility that your program exits with a bang rather 
than responsibly :)  The programming purists will insist that the 
number of free() calls must match the number of all allocations 
(with the possible exception of abort() or exit() calls due to 
errors), even if you are lining them up at the end of main(); others 
rely on the OS to clean up everything, which a good OS usually does.

3) for pointers of allocated blocks assigned to local vars, make sure 
the free() call is within the function scope (or block scope, if you 
are setting up pointer variables in inner blocks).  If it is assigned 
to a global, make sure the free() call to the global cannot possibly 
occur before its allocation; you may need to set up the proper 
conditionals.  In particular for global variables used for assignment 
of pointers to alloc'd blocks, follow rule 4.

4) some people like to assign NULL to all variables which they have 
free()d.  This is certainly a good practice for global variables and
static local variables (pointless for nonstatic locals as 
they will not be likely NULL when you re-enter the function).  You 
can then test whether a variable might contain pointer before using 
it as a pointer to another block.  

5) For character arrays serving as null-terminated strings, you may 
want to set up the following macro.

#define  string_alloc(x)       malloc(x + 1)

You could put it at the head of your translation unit or perhaps in 
your stdlib.h header (or header where alloc functions are defined), 
although some might sniff at messing with standard header files.  It 
should be rather obvious what purpose this serves.  It means you get 
in the habit of creating pointers you intend to use as strings using 
a 'function' not part of anyone's standard library.  If you use such 
macros, don't forget the cousins 'string_calloc()' and 
'string_realloc()'

I am sure there is more I neglected to mention about habits 
regarding code checking the memory allocation system, and you can bet 
that others will jump in and fill in the rest.

Mitch Halloran
Research (Bio)chemist
Duzen Laboratories Group
Ankara   TURKEY
mitch AT duzen DOT com DOT tr

other job title:  Sequoia's (dob 12-20-95) daddy

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019