meissner@dg_rtp.UUCP (Michael Meissner) (05/17/87)
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?
throopw@dg_rtp.UUCP (Wayne Throop) (05/18/87)
> chris@mimsy.UUCP (Chris Torek) >> ries@trwrb.UUCP (Marc Ries) >>... the core dump is entirely dependent upon whether the char *line >>comes before or after the FILE *fp, *fopen() declaration. > The variable is *not* initialised, hence it contains trash. Worth noting: lint would have caught this error. Moral: use lint. I think there is only one valid justification for not using type and usage checking tools like lint. And that's if they aren't available to you. -- "He's more than just a Galaxy Ranger.... He's a Super-Trooper!" --- From "The Adventures of the Galaxy Rangers" -- Wayne Throop <the-known-world>!mcnc!rti!dg_rtp!throopw