Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!dino!ux1.cso.uiuc.edu!ux1.cso.uiuc.edu!m.cs.uiuc.edu!sunb0.cs.uiuc.edu!mccaugh
From: mccaugh@sunb0.cs.uiuc.edu
Newsgroups: comp.lang.c
Subject: Re: stupid compilers
Message-ID: <24700008@sunb0.cs.uiuc.edu>
Date: 2 Sep 90 05:47:00 GMT
References: <163@prodix.liu.se>
Lines: 25
Nf-ID: #R:prodix.liu.se:163:sunb0.cs.uiuc.edu:24700008:000:1553
Nf-From: sunb0.cs.uiuc.edu!mccaugh    Sep  2 00:47:00 1990


Hmmmmm: "pure luck" that the first program works, comments the previous note.
But the question orignally posed did not address correctness of either program,
but rather why the second version precipitates a segmentation fault where the
first one does not. So what is the key difference in the two programs? It would
appear to be in the declaration of variable 'line' which is a null (length = 0)
string in the first declaration (char []) and a char-ptr in the second. We are
not informed as to whether the assignment (via 'strcpy') caused the problem or
the subsequent 'printf' but I would suspect the latter. (If the former caused
the problem in the second version, why not in the first?) Perhaps "%s" allows
for "normal" execution in the first program -- since 'line' is technically a
string -- but not in the second. I, too, have encountered a similar problem
with C compilers on VAXen.  My point is that certain compilers MAY draw some
serious distinction between char-ptrs and "true" strings (char [*]) even when
the string is null.

   Since un-initialized ptrs so often lead to segmentation faults, here is my
guess as to what happened. The first declaration (char line [];) must have
initialized variable 'line' as a char-ptr to some 0-length area, while the
second declaration (char *line;) left 'line' un-initialized. Hence the value
of 'line' in the first case was legitimate -- even if it addressed 0-length
space -- while the un-initialized "value" of 'line' in the second case could 
not even be considered legitimate.

 Scott McCaughrin