Re: Segmentation fault
Thanks for all the feedback. I really don't know what the problem was here.
The Title buffer was set to 80 char and the input was not 10 characters
As I come up to speed, I'll get a better understanding of the nuances of
gcc/g++. In the meantime, I think I'm much safer using safe practices, as
In this particular case, it was useful for me to convert the code to c++
stream i/o, which reads very straightforwardly. I've since enhanced it with
cgi code and it now outputs the results of its computation to a web page.
For instance, the code below reads in>>Title; in>>m>>n>>it>>LT>>EQ>>GT; This
will change again as I hand off the interface to the client terminal
----- Original Message -----
From: Eric G . Miller <email@example.com>
Sent: Tuesday, February 15, 2000 8:10 PM
Subject: Re: Segmentation fault
> On Tue, Feb 15, 2000 at 11:08:21PM +0900, Junichi Uekawa wrote:
> > On Mon, 14 Feb 2000 11:43:25 -0800, "davidturetsky"
> > <firstname.lastname@example.org> was crying out from somewhere about: Re:
> > Segmentation fault
> > davidturetsky> I believe this is the code
> >> that was getting me into trouble, but it could be
> > davidturetsky> elsewhere
> > davidturetsky>
> > davidturetsky> fscanf (file, "%s", Title);
> > davidturetsky> fscanf (file, "%d %d %d %d %d %d",
> >> &m, &n, &it, <, &EQ, >);
> > Probably, the input string was too long for the char* Title? I don't
> > know. MSC seems to let the stack be destroyed quite quietly. It's a
> > feature, methinks. Not too many segfaults when developing, but
> > occasional BOD on using.
> This is why, I think, that fgets is recommended over scanf/fscanf.
> You'll always know the maximum of the data you read in. Of course, then
> you still have to split it and check your input data matches what you
> expected to receive. Also, newlines and whitespace can pile up in
> scanf/fscanf. It's generally recognized as being unsafe (like C/C++ in