[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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
below.

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

David

----- Original Message -----
From: Eric G . Miller <egm2@jps.net>
To: <debian-user@lists.debian.org>
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"
> > <davidturetsky@email.msn.com> 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, &LT, &EQ, &GT);
>
> > 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
> general!).
>




Reply to: