Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!mit-eddie!gatech!mcnc!rti!dg_rtp!meissner
From: meissner@dg_rtp.UUCP (Michael Meissner)
Newsgroups: comp.lang.c
Subject: Re: declaration placements and fgets (query)
Message-ID: <1921@dg_rtp.UUCP>
Date: Sun, 17-May-87 09:51:50 EDT
Article-I.D.: dg_rtp.1921
Posted: Sun May 17 09:51:50 1987
Date-Received: Sun, 17-May-87 19:41:50 EDT
References: <1899@trwrb.UUCP>
Reply-To: meissner@dg_rtp.UUCP (Michael Meissner)
Distribution: world
Organization: Data General (Languages @ Research Triangle Park, NC.)
Lines: 31
Summary: Uninitialized variable

In article <1899@trwrb.UUCP> ries@trwrb.UUCP (Marc Ries) writes:
> 
> The following code, as is, will produce a core dump in the  fgets
> call.  The  seemingly  strange  part  is  that  the  core dump is
> entirely dependent upon whether the char *line  comes  before  or
> after the FILE *fp, *fopen() declaration.
> 
> So, why does it matter (even bad code aside) as to why 
> 
>     FILE *fp, *fopen();
>     char *line;
> 
> bombs fgets, and
> 
>     char *line;
>     FILE *fp, *fopen();

I've never used a pyramid, but this type of occurance happens on other
machines as well.  The problem is the pointer line is never initialized
(to either a char array in scope or a malloc'ed area).  Thus whatever
is on the stack at the time of the storage allocation for the current
procedure's local variables is used.  My guess is a zero or a harmless
pointer happens to be at the first location where auto variables are
allocated, and some harmful pointer (such as a pointer to a database
needed such as stdout's FILE structure, or your stack).  In the DG environ-
ment, this happens because the start location calls initialization routines
which muck with their local variables, and return, and then main is called.
-- 
	Michael Meissner, Data General	Uucp: ...mcnc!rti!dg_rtp!meissner

It is 11pm, do you know what your sendmail and uucico are doing?