Please help me overcome the segmentation fault

R

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
 
A

Ancient_Hacker

Rav said:
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".
 
E

Eric Sosman

Rav said:
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."
 
B

Barry Schwarz

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
 
T

Thad Smith

Rav said:
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.
 
C

CBFalconer

Thad said:
Rav said:
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.
 
R

Richard Heathfield

CBFalconer said:
Thad said:
Rav wrote:
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;
}
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;

?
 
S

Simon Biber

CBFalconer said:
Thad said:
Rav said:
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];
 
C

CBFalconer

Richard said:
CBFalconer said:
Thad said:
Rav wrote:
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;
}
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.
 
R

Richard Heathfield

CBFalconer said:
Richard said:
CBFalconer said:
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. :)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,051
Latest member
CarleyMcCr

Latest Threads

Top