Please help me overcome the segmentation fault

[Rav]

I have recently started working on GCC on red Hat 9. I have encountered
with some problems that i think should not occur (at least on Turbo C),
here they r:

Why does the following piece of code displays segmentation fault error:

{
int list[]={10,20,30,40,50};
int *p, *q;
p = list; //the problem is somewhere here, i checked with the
debugger
q = list+4;
}

another problem is that, while using fgets i am bound to use getchar to
remove the unread '\n'character in stdin as fflush(stdin) doesn't work.

char temp[20];
printf("\n Enter string: ");
getchar(); //fflush(stdin) was supposed to be used
fgets(temp,20,stdin);

it works fine this way but i think is not a proper approach. plz
suggest a solution. why isn't fflush(stdin) working, is there any
alternative of fflush(stdin).

plz help...thanks in advance

[Ancient_Hacker]

The code looks fine as far as it goes. What comes after?

[Ancient_Hacker]

Rav wrote:

char temp[20];
printf("\n Enter string: ");
getchar(); //fflush(stdin) was supposed to be used
fgets(temp,20,stdin);

it works fine this way but i think is not a proper approach. plz
suggest a solution. why isn't fflush(stdin) working, is there any
alternative of fflush(stdin).

plz help...thanks in advance

using fflush() on a terminal is not a great idea.

If there is an extra "\n", it's likely you had a previous scanf() which
did not absorb the trailing "\n". Either use the getchar() or have the
previous read or scanf() also read the "\n".

[Eric Sosman]

Rav wrote:

I have recently started working on GCC on red Hat 9. I have encountered
with some problems that i think should not occur (at least on Turbo C),
here they r:

Why does the following piece of code displays segmentation fault error:

{
int list[]={10,20,30,40,50};
int *p, *q;
p = list; //the problem is somewhere here, i checked with the
debugger
q = list+4;
}

I can see nothing inherently wrong with this fragment,
so I suspect the problem may be in the code I cannot see.
Please post a minimal, complete, compilable example that
demonstrates your problem.

another problem is that, while using fgets i am bound to use getchar to
remove the unread '\n'character in stdin as fflush(stdin) doesn't work.

Normally, fgets() reads and consumes the input stream
until it has read and consumed exactly one '\n', the one
that terminates the line. (Exceptions: fgets() will stop
early, without reading a '\n', if it encounters end-of-file
or an input error or if the line is too long for the buffer.)
I'm not sure what you mean by "the unread '\n' character,"
since there usually won't be one.

char temp[20];
printf("\n Enter string: ");
getchar(); //fflush(stdin) was supposed to be used

fflush(stdin) was *never* supposed to be used. What
are you trying to accomplish?

fgets(temp,20,stdin);

it works fine this way but i think is not a proper approach. plz
suggest a solution.

You say "it works fine," and you ask for a "solution," but you
haven't told us what problem you are trying to solve.

why isn't fflush(stdin) working, is there any
alternative of fflush(stdin).

fflush() performs an output operation. stdin is not an output
stream. That's why fflush(stdin) doesn't "work," just as

fputs("\n!dlrow ,olleH", stdin);

doesn't "work."

--
Eric Sosman
es*****@acm-dot-org.invalid

[Barry Schwarz]

On 22 Oct 2006 07:26:31 -0700, "Rav" <ra*********@gmail.comwrote:

>I have recently started working on GCC on red Hat 9. I have encountered
with some problems that i think should not occur (at least on Turbo C),
here they r:

Why does the following piece of code displays segmentation fault error:

{
int list[]={10,20,30,40,50};
int *p, *q;
p = list; //the problem is somewhere here, i checked with the
debugger

Not likely. This statement assigns p the address of list[0] so p
points to the 10. Given that you did not post a compilable example,
under the normal assumptions this code should work fine.

>q = list+4;

Ditto. q points to the 50.

>}

another problem is that, while using fgets i am bound to use getchar to
remove the unread '\n'character in stdin as fflush(stdin) doesn't work.

fgets will read the first \n it encounters in the stream unless it has
already transferred count-1 characters. Please try to describe the
problem in detail. fflush is defined only for output streams.

>
char temp[20];
printf("\n Enter string: ");
getchar(); //fflush(stdin) was supposed to be used

This removes the first character of input so you can never see it.
What makes you think it is a \n. The only time I have seen what you
describe actually happen is if this code is preceded by a getchar that
left a \n waiting in the stream.

>fgets(temp,20,stdin);

it works fine this way but i think is not a proper approach. plz
suggest a solution. why isn't fflush(stdin) working, is there any
alternative of fflush(stdin).

plz help...thanks in advance

Please post some compilable code and explain clearly what is happening
that you don't like.
Remove del for email

[Thad Smith]

Rav wrote:

I have recently started working on GCC on red Hat 9. I have encountered
with some problems that i think should not occur (at least on Turbo C),
here they r:

Why does the following piece of code displays segmentation fault error:

{
int list[]={10,20,30,40,50};
int *p, *q;
p = list; //the problem is somewhere here, i checked with the
debugger
q = list+4;
}

I'm temped to say that debugger is undefined, but that would have given
a compiler error and I suspect that your news editor wrapped the comment
line -- one reason to avoid // comments in Usenet.

As others have said, other than the wrapped comment, it looks OK.

--
Thad

[CBFalconer]

Thad Smith wrote:

Rav wrote:

>I have recently started working on GCC on red Hat 9. I have
encountered with some problems that i think should not occur (at
least on Turbo C), here they r:

Why does the following piece of code displays segmentation fault
error:

{
int list[]={10,20,30,40,50};
int *p, *q;
p = list; //the problem is somewhere here, i checked with the
debugger
q = list+4;
}

I'm temped to say that debugger is undefined, but that would have
given a compiler error and I suspect that your news editor wrapped
the comment line -- one reason to avoid // comments in Usenet.

As others have said, other than the wrapped comment, it looks OK.

No, list is an array of ints, not a pointer. The statement should
have read:

p = &list[0] + 4;

If that had happened after passing list to an external routine, the
statement would have been correct in that routine because of the
automatic conversion to a pointer.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Richard Heathfield]

CBFalconer said:

Thad Smith wrote:

>Rav wrote:

<snip>

>>>
Why does the following piece of code displays segmentation fault
error:

{
int list[]={10,20,30,40,50};
int *p, *q;
p = list; //the problem is somewhere here, i checked with the
debugger
q = list+4;
}

<snip>

>>
As others have said, other than the wrapped comment, it looks OK.

No, list is an array of ints, not a pointer. The statement should
have read:

p = &list[0] + 4;

You lost me. Firstly, did you mean q, rather than p? If not, your code
doesn't have the same semantics as p = list, and if you did, how is:

q = &list[0] + 4;

semantically different from:

q = list + 4;

?

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)

[Simon Biber]

CBFalconer wrote:

Thad Smith wrote:

>Rav wrote:

>>I have recently started working on GCC on red Hat 9. I have
encountered with some problems that i think should not occur (at
least on Turbo C), here they r:

Why does the following piece of code displays segmentation fault
error:

{
int list[]={10,20,30,40,50};
int *p, *q;
p = list; //the problem is somewhere here, i checked with the
debugger
q = list+4;
}

I'm temped to say that debugger is undefined, but that would have
given a compiler error and I suspect that your news editor wrapped
the comment line -- one reason to avoid // comments in Usenet.

As others have said, other than the wrapped comment, it looks OK.

No, list is an array of ints, not a pointer. The statement should
have read:

p = &list[0] + 4;

That's an issue of style. Those who prefer adding unnecessary & and []
around array names would probably change it directly to &list[4].

If that had happened after passing list to an external routine, the
statement would have been correct in that routine because of the
automatic conversion to a pointer.

Is this the real Chuck Falconer? I would not have expected him to make
such a fundamental mistake. You can always use the name of an array as a
pointer to its first element. Not just after passing it to another
function. There is nothing wrong with the code that the OP posted.

p = list; /* is equivalent to */ p = &list[0];

q = list + 4; /* is equivalent to */ q = &list[0] + 4;
/* or */ q = &list[4];

--
Simon.

[CBFalconer]

Richard Heathfield wrote:

CBFalconer said:

>Thad Smith wrote:

>>Rav wrote:

<snip>

>>>>
Why does the following piece of code displays segmentation fault
error:

{
int list[]={10,20,30,40,50};
int *p, *q;
p = list; //the problem is somewhere here, i checked with the
debugger
q = list+4;
}

<snip>

>>>
As others have said, other than the wrapped comment, it looks OK.

No, list is an array of ints, not a pointer. The statement should
have read:

p = &list[0] + 4;

You lost me. Firstly, did you mean q, rather than p? If not, your code
doesn't have the same semantics as p = list, and if you did, how is:

You are right. It should have been "p = &list[0];"

Are you always roaming Usenet in the middle of the night? I have
an excuse, I have medical problems that get me up every hour or
two. But you seem to be a relatively young thing.

--
Chuck F (cbfalconer at maineline dot net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home.att.net>

[Richard Heathfield]

CBFalconer said:

Richard Heathfield wrote:

>CBFalconer said:

<snip>

>>>
No, list is an array of ints, not a pointer. The statement should
have read:

p = &list[0] + 4;

You lost me. Firstly, did you mean q, rather than p? If not, your code
doesn't have the same semantics as p = list, and if you did, how is:

You are right. It should have been "p = &list[0];"

Or, equivalently, just: p = list; which is what it actually was.

Are you always roaming Usenet in the middle of the night?

I don't consider 05:55GMT (06:55BST) to be the middle of the night. :-)

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at above domain (but drop the www, obviously)