🚀 go-pugleaf

>>>>> On 31 Oct 1993 10:38:30 GMT, masc0827@ucssun1.sdsu.edu (Frank Rustemeyer) said:

> The following program does compile, but when i run it under UNIX it produces
> a "segmenattion fault" after the return statement int main() is reached.
> The code is standard ansi c, and i cannot find any errors.
> If you have an explanation or a solution, please mail to
> masc0827@rohan.sdsu.edu (Frank Rustemeyer). Thanks in advance.

> -------------------------------------------------------------------------

> /* Shortest program to produce the error.
> // If any of the lines (1),(2),(3) are deleted, the error will not occur.
> // In line (2),  it has no effect to use NULL, or 0 instead of
> // (struct list *) 0. */

> #include <stdio.h>
> #include <malloc.h>

> struct list               
> {   int x;                                      /* (1) */
> int *line;
> struct list *nxt; 
> } ;                         

> struct list *root;

> void declare(void)
> {   struct list *l;

> if (!(root = (struct list *) malloc(sizeof (struct list *))))
                                              ^^^^^^^^^^^^^ BUG!!!!
> return;
> l = root;              
> l->nxt = (struct list *) 0;                  /*  (2)  */
> } 

> void nothing(void) { printf ("!\n");}

> int main(void)
> {   declare();
> nothing();                                   /*  (3)  */
> return 1;
> }


You've malloced enough space for a pointer to a list item, not
enough for a list item.  That line should be written:

if (!(root = (struct list *) malloc(sizeof (struct list))))

or even better:

#define tmalloc(t)	((t *)malloc(sizeof(t)))
if ((root = tmalloc(struct list)) == NULL)

I heartily suggest using a macro along the lines of tmalloc to avoid this
sort of thing.  It works wonders for the clarity of mallocs.

As for whyu the three numbered lines are critical, if you remove (1) you
shrink the struct to two pointers, which means that you don't run over
into the next malloc block as far with the "l->nxt = (struct list *) 0;"
statement.  Maybe you don't overwrite anything absolutly critical in the
malloc header.  Still, it would probably do it eventually.  (2) is the
actual overwriting.  (3) is probably fatal due to printf using malloc,
thus exercising the broken heap.  Remember, once you've screwed up malloc
headers, anything that looks sidewise at malloc can segv on you!


BTW: As a stylistic comment, having a statement after a open brace on a
given line is usually considered a Bad Thing == hard to read, annoying to
modify, etc.  One more line won't kill you.

BTW2: This post really should have been in comp.lang.c.  Was it gcc
specific?  Not really.  If you had tried this on your vendor's compiler it
would have probably dumped core there just as fast.  I have directed
follow ups to comp.lang.c.

Philip Guenther
--
guenther@stolaf.edu (Philip Guenther) St Olaf College, Northfield, MN 55057
(setq sig-hook '(lambda () (gnus-insert-disclaimer organization 'student)))
"To go outside the mythos is to become insane...." -Robert Pirsig