seg fault

[Bill Cunningham]

I have put together this program that seems to do what I want without
error checking added yet. If I just run the program it produces a
segmentation fault. If I add the proper value say 43.56 it's fine. Does
anyone see what's wrong ? I have a c99 compiler. Thanks.

#include <stdio.h>
#include <stdlib.h>

int main ( int argc, char *argv[] ) {
FILE*fp;
double x;
x=strtod(argv[1],NULL);
if (argc !=2) {
fprintf(stderr, "usage error\n");
exit(EXIT_FAILU RE);
}
fp=fopen( "data", "a");
ftell(fp);
fseek(fp,sizeof (double),SEEK_C UR);
fprintf(fp,"%.2 f\n",x);
fclose(fp);
}

[Malcolm McLean]

Re: seg fault

"Bill Cunningham" <nospam@nspam.c omwrote in message news:

I have put together this program that seems to do what I want without
error checking added yet. If I just run the program it produces a
segmentation fault. If I add the proper value say 43.56 it's fine. Does
anyone see what's wrong ? I have a c99 compiler. Thanks.
>
#include <stdio.h>
#include <stdlib.h>
>
int main ( int argc, char *argv[] ) {
FILE*fp;
double x;
x=strtod(argv[1],NULL);
>

If argc is 1 this passes a null pointer to strtod, which could well cause a
segfault.

>
if (argc !=2) {
fprintf(stderr, "usage error\n");
exit(EXIT_FAILU RE);
}
fp=fopen( "data", "a");
>

You also need to check fp for nullness here.

>
ftell(fp);
fseek(fp,sizeof (double),SEEK_C UR);
fprintf(fp,"%.2 f\n",x);
fclose(fp);
}
>
>

--
Free games and programming goodies.

http://www.personal.leeds.ac.uk/~bgy1mm

[Bill Cunningham]

Re: seg fault


"Malcolm McLean" <regniztar@btin ternet.comwrote in message
news:7u-dnQEqJ7c7g8XVnZ 2dnUVZ8tSdnZ2d@ bt.com...

"Bill Cunningham" <nospam@nspam.c omwrote in message news:

> I have put together this program that seems to do what I want without
>error checking added yet. If I just run the program it produces a
>segmentation fault. If I add the proper value say 43.56 it's fine. Does
>anyone see what's wrong ? I have a c99 compiler. Thanks.
>>
>#include <stdio.h>
>#include <stdlib.h>
>>
>int main ( int argc, char *argv[] ) {
> FILE*fp;
> double x;
> x=strtod(argv[1],NULL);
>>

If argc is 1 this passes a null pointer to strtod, which could well cause
a segfault.

This may be where it is. Just running the program argv[0] would be
execution, giving no arguments like I didn't would be NULL.

>>
> if (argc !=2) {
> fprintf(stderr, "usage error\n");
> exit(EXIT_FAILU RE);
> }
> fp=fopen( "data", "a");
>>

You also need to check fp for nullness here.

>>
> ftell(fp);
> fseek(fp,sizeof (double),SEEK_C UR);
> fprintf(fp,"%.2 f\n",x);
> fclose(fp);
>}
>>
>>

>

[santosh]

Re: seg fault

Bill Cunningham wrote:

I have put together this program that seems to do what I want
without
error checking added yet. If I just run the program it produces a
segmentation fault. If I add the proper value say 43.56 it's fine.
Does anyone see what's wrong ? I have a c99 compiler. Thanks.
>
#include <stdio.h>
#include <stdlib.h>
>
int main ( int argc, char *argv[] ) {
FILE*fp;
double x;
x=strtod(argv[1],NULL);
if (argc !=2) {
fprintf(stderr, "usage error\n");
exit(EXIT_FAILU RE);
}

This test should come before the conversion with strtod. Otherwise
strtod is passed a null pointer, which is what causes the segmentation
fault.

fp=fopen( "data", "a");
ftell(fp);

What is the purpose of calling ftell and discarding the return?

fseek(fp,sizeof (double),SEEK_C UR);

When you open a file in the append mode the file position indicator is
already positioned after any contents the file may have. You are now
trying to seek sizeof(double) bytes beyond the end of the file, which
will return an error. Exactly what do you hope to accomplish by doing
so?

fprintf(fp,"%.2 f\n",x);
fclose(fp);
}

[Johannes Bauer]

Re: seg fault

Bill Cunningham schrieb:

This may be where it is. Just running the program argv[0] would be
execution, giving no arguments like I didn't would be NULL.

"may be"? Say do you think debugging C-programs is like guessing where
the fault could occur? Why don't you use a helper tool, say, uhmm, a
debugger?

With a program that short however you could well have inserted some
fprintf(stderr, "xyz\n") statements after every line and found it yourself.

Regards,
Johannes

--
"Wer etwas kritisiert muss es noch lange nicht selber besser können. Es
reicht zu wissen, daß andere es besser können und andere es auch
besser machen um einen Vergleich zu bringen." - Wolfgang Gerber
in de.sci.electron ics <47fa8447$0$115 45$9b622d9e@new s.freenet.de>

[Bill Cunningham]

Re: seg fault


"santosh" <santosh.k83@gm ail.comwrote in message
news:g397jo$a5r $1@registered.m otzarella.org.. .

Bill Cunningham wrote:
>

> I have put together this program that seems to do what I want
> without
>error checking added yet. If I just run the program it produces a
>segmentation fault. If I add the proper value say 43.56 it's fine.
>Does anyone see what's wrong ? I have a c99 compiler. Thanks.
>>
>#include <stdio.h>
>#include <stdlib.h>
>>
>int main ( int argc, char *argv[] ) {
> FILE*fp;
> double x;
> x=strtod(argv[1],NULL);
> if (argc !=2) {
> fprintf(stderr, "usage error\n");
> exit(EXIT_FAILU RE);
> }

>
This test should come before the conversion with strtod. Otherwise
strtod is passed a null pointer, which is what causes the segmentation
fault.
>

> fp=fopen( "data", "a");
> ftell(fp);

>
What is the purpose of calling ftell and discarding the return?
>

> fseek(fp,sizeof (double),SEEK_C UR);

>
When you open a file in the append mode the file position indicator is
already positioned after any contents the file may have. You are now
trying to seek sizeof(double) bytes beyond the end of the file, which
will return an error. Exactly what do you hope to accomplish by doing
so?
>

> fprintf(fp,"%.2 f\n",x);
> fclose(fp);
>}

Well I've added error checking to ftell, fseek, and fopen and the
program works. It will still segfault if the program is run and nothing
entered. I've used these return values.
For ftell and fseek -1. For fopen NULL. I believe those are the values
to test against.

Bill

[Richard]

Re: seg fault

"Bill Cunningham" <nospam@nspam.c omwrites:

I have put together this program that seems to do what I want without
error checking added yet. If I just run the program it produces a
segmentation fault. If I add the proper value say 43.56 it's fine. Does
anyone see what's wrong ? I have a c99 compiler. Thanks.
>
#include <stdio.h>
#include <stdlib.h>
>
int main ( int argc, char *argv[] ) {
FILE*fp;
double x;
x=strtod(argv[1],NULL);
if (argc !=2) {
fprintf(stderr, "usage error\n");
exit(EXIT_FAILU RE);
}
fp=fopen( "data", "a");
ftell(fp);
fseek(fp,sizeof (double),SEEK_C UR);
fprintf(fp,"%.2 f\n",x);
fclose(fp);
}

Try using a debugger. How many more times?

[Bill Cunningham]

Re: seg fault


"santosh" <santosh.k83@gm ail.comwrote in message
news:g397jo$a5r $1@registered.m otzarella.org.. .

Bill Cunningham wrote:
>

> I have put together this program that seems to do what I want
> without
>error checking added yet. If I just run the program it produces a
>segmentation fault. If I add the proper value say 43.56 it's fine.
>Does anyone see what's wrong ? I have a c99 compiler. Thanks.
>>
>#include <stdio.h>
>#include <stdlib.h>
>>
>int main ( int argc, char *argv[] ) {
> FILE*fp;
> double x;
> x=strtod(argv[1],NULL);
> if (argc !=2) {
> fprintf(stderr, "usage error\n");
> exit(EXIT_FAILU RE);
> }

>
This test should come before the conversion with strtod. Otherwise
strtod is passed a null pointer, which is what causes the segmentation
fault.

Oh OK

> fp=fopen( "data", "a");
> ftell(fp);

>
What is the purpose of calling ftell and discarding the return?

Where do I put it?

> fseek(fp,sizeof (double),SEEK_C UR);

>
When you open a file in the append mode the file position indicator is
already positioned after any contents the file may have. You are now
trying to seek sizeof(double) bytes beyond the end of the file, which
will return an error. Exactly what do you hope to accomplish by doing
so?
>

> fprintf(fp,"%.2 f\n",x);
> fclose(fp);
>}

People tell me look at the docs. I read the sentnece or two that
describes the functions in man pages and it's return values and stick it in
code. Hell I don't know what ftell does.

http://www.cppreference.com/stdio/index.html

Just look at the descriptions of functions on this page. You better
already know what they do before you read. I thought fseek would take as a
3rd paramter 0,1, or 2.

Bill

[Bill Cunningham]

Re: seg fault


"Richard" <rgrdev@gmail.c omwrote in message
news:g39964$fss $1@registered.m otzarella.org.. .

Try using a debugger. How many more times?

RIGHT.

[santosh]

Re: seg fault

Bill Cunningham wrote:

>
"santosh" <santosh.k83@gm ail.comwrote in message
news:g397jo$a5r $1@registered.m otzarella.org.. .

>Bill Cunningham wrote:
>>

>> I have put together this program that seems to do what I want
>> without
>>error checking added yet. If I just run the program it produces a
>>segmentatio n fault. If I add the proper value say 43.56 it's fine.
>>Does anyone see what's wrong ? I have a c99 compiler. Thanks.
>>>
>>#include <stdio.h>
>>#include <stdlib.h>
>>>
>>int main ( int argc, char *argv[] ) {
>> FILE*fp;
>> double x;
>> x=strtod(argv[1],NULL);
>> if (argc !=2) {
>> fprintf(stderr, "usage error\n");
>> exit(EXIT_FAILU RE);
>> }

>>
>This test should come before the conversion with strtod. Otherwise
>strtod is passed a null pointer, which is what causes the
>segmentation fault.
>>

>> fp=fopen( "data", "a");
>> ftell(fp);

>>
>What is the purpose of calling ftell and discarding the return?
>>

>> fseek(fp,sizeof (double),SEEK_C UR);

>>
>When you open a file in the append mode the file position indicator
>is already positioned after any contents the file may have. You are
>now trying to seek sizeof(double) bytes beyond the end of the file,
>which will return an error. Exactly what do you hope to accomplish by
>doing so?
>>

>> fprintf(fp,"%.2 f\n",x);
>> fclose(fp);
>>}

>
Well I've added error checking to ftell, fseek, and fopen and the
program works. It will still segfault if the program is run and
nothing entered.

That's expected. In the case of no arguments argv[1] is a null pointer
and passing it to strtod results in undefined behaviour.

I've used these return values.
For ftell and fseek -1. For fopen NULL. I believe those are the
values to test against.

Yes.

[santosh]

Re: seg fault

Bill Cunningham wrote:

>
"santosh" <santosh.k83@gm ail.comwrote in message
news:g397jo$a5r $1@registered.m otzarella.org.. .

>Bill Cunningham wrote:
>>

>> I have put together this program that seems to do what I want
>> without
>>error checking added yet. If I just run the program it produces a
>>segmentatio n fault. If I add the proper value say 43.56 it's fine.
>>Does anyone see what's wrong ? I have a c99 compiler. Thanks.
>>>
>>#include <stdio.h>
>>#include <stdlib.h>
>>>
>>int main ( int argc, char *argv[] ) {
>> FILE*fp;
>> double x;
>> x=strtod(argv[1],NULL);
>> if (argc !=2) {
>> fprintf(stderr, "usage error\n");
>> exit(EXIT_FAILU RE);
>> }

>>
>This test should come before the conversion with strtod. Otherwise
>strtod is passed a null pointer, which is what causes the
>segmentation fault.

>
Oh OK
>

>> fp=fopen( "data", "a");
>> ftell(fp);

>>
>What is the purpose of calling ftell and discarding the return?

>
Where do I put it?

What is the purpose of this program. Is it to append to a text file a
double value? If so, then you do not need the ftell above since upon
opening the file with the "a" mode, the file position indicator is
already correctly positioned.

>> fseek(fp,sizeof (double),SEEK_C UR);

>>
>When you open a file in the append mode the file position indicator
>is already positioned after any contents the file may have. You are
>now trying to seek sizeof(double) bytes beyond the end of the file,
>which will return an error. Exactly what do you hope to accomplish by
>doing so?
>>

>> fprintf(fp,"%.2 f\n",x);
>> fclose(fp);
>>}

>
People tell me look at the docs. I read the sentnece or two that
describes the functions in man pages and it's return values and stick
it in code.

Reading a "sentence or two" is not good enough. You need to completely
and systematically read the standard's description and your
implementation' s description of each standard library function before
using it. If you don't understand what a function does even after
reading it's documentation, then you can ask here.

Hell I don't know what ftell does.

Then read it's documentation in n1256 below:

<http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf>

http://www.cppreference.com/stdio/index.html

I do not know how good the above link is, but other than the standard
itself the following documentation is very good as a reference for the
C99 standard library.

<http://www.dinkumware. com/manuals/>

Just look at the descriptions of functions on this page. You
better already know what they do before you read.

Not at all.

I thought fseek would take
as a 3rd paramter 0,1, or 2.

No. The possible values are SEEK_SET, SEEK_CUR and SEEK_END.

[user923005]

Re: seg fault

On Jun 17, 1:22 pm, "Bill Cunningham" <nos...@nspam.c omwrote:

    I have put together this program that seems to do what I want without
error checking added yet. If I just run the program it produces a
segmentation fault. If I add the proper value say 43.56 it's fine. Does
anyone see what's wrong ? I have a c99 compiler. Thanks.
>
#include <stdio.h>
#include <stdlib.h>
>
int main ( int argc, char *argv[] ) {
    FILE*fp;
    double x;
    x=strtod(argv[1],NULL);
    if (argc !=2) {
       fprintf(stderr, "usage error\n");
       exit(EXIT_FAILU RE);
       }
    fp=fopen( "data", "a");
    ftell(fp);
    fseek(fp,sizeof (double),SEEK_C UR);
    fprintf(fp,"%.2 f\n",x);
    fclose(fp);
>
>
>
}

While the advice to use a debugger is good advice, the entire solution
to this problem can be found via static analysis. Splint is free:

http://www.splint.org

Here is the analysis using splint and pc-lint:

#include <stdio.h>
#include <stdlib.h>

int main ( int argc, char *argv[] ) {
FILE*fp;
double x;
x=strtod(argv[1],NULL);
if (argc !=2) {
fprintf(stderr, "usage error\n");
exit(EXIT_FAILU RE);
}
fp=fopen( "data", "a");
ftell(fp);
fseek(fp,sizeof (double),SEEK_C UR);
fprintf(fp,"%.2 f\n",x);
fclose(fp);
}
/*
Splint output:
==============
C:\tmp>splint bug.c
Splint 3.1.1 --- 12 Mar 2007

bug.c: (in function main)
bug.c(13,11): Possibly null storage fp passed as non-null param: ftell
(fp)
A possibly null pointer is passed as a parameter corresponding to a
formal
parameter with no /*@null@*/ annotation. If NULL may be used for
this
parameter, add a /*@null@*/ annotation to the function parameter
declaration.
(Use -nullpass to inhibit warning)
bug.c(12,8): Storage fp may become null
bug.c(13,5): Return value (type long int) ignored: ftell(fp)
Result returned by function call is not used. If this is intended,
can cast
result to (void) to eliminate message. (Use -retvalother to inhibit
warning)
bug.c(14,29): Function fseek expects arg 2 to be long int gets size_t:
sizeof(double)
To allow arbitrary integral types to match long unsigned, use
+longintegral.
bug.c(14,5): Return value (type int) ignored: fseek(fp, sizeof...
Result returned by function call is not used. If this is intended,
can cast
result to (void) to eliminate message. (Use -retvalint to inhibit
warning)
bug.c(16,5): Return value (type int) ignored: fclose(fp)
bug.c(17,2): Path with no return in function declared to return int
There is a path through a function declared to return a value on
which there
is no return statement. This means the execution may fall through
without
returning a meaningful result to the caller. (Use -noret to inhibit
warning)

Finished checking --- 6 code warnings

Lint output:
============
C:\tmp>"C:\Lint \Lint-nt" +v -i"C:\Lint" std.lnt -os(_LINT.TMP)
bug.c
PC-lint for C/C++ (NT) Vers. 8.00u, Copyright Gimpel Software
1985-2006

--- Module: bug.c (C)

C:\tmp>type _LINT.TMP | more

--- Module: bug.c (C)
_
ftell(fp);
bug.c(13) : Warning 534: Ignoring return value of function
'ftell(struct _iobuf
*)' (compare with line 257, file C:\Program Files\Microsoft Visual
Studio
8\VC\INCLUDE\st dio.h)
C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\st dio.h(257) :
Info 830:
Location cited in prior message
_
ftell(fp);
bug.c(13) : Warning 668: Possibly passing a null pointer to function
'ftell(struct _iobuf *)', arg. no. 1 [Reference: file bug.c: line
12]
bug.c(12) : Info 831: Reference cited in prior message
_
}
bug.c(17) : Warning 533: function 'main(int, char **)' should return a
value
(see line 4)
bug.c(4) : Info 830: Location cited in prior message
_
}
bug.c(17) : Note 952: Parameter 'argv' (line 4) could be declared
const ---
Eff. C++ 3rd Ed. item 3
bug.c(4) : Info 830: Location cited in prior message
_
}
bug.c(17) : Info 818: Pointer parameter 'argv' (line 4) could be
declared as
pointing to const --- Eff. C++ 3rd Ed. item 3
bug.c(4) : Info 830: Location cited in prior message
_
}
bug.c(17) : Note 952: Parameter 'argc' (line 4) could be declared
const ---
Eff. C++ 3rd Ed. item 3
bug.c(4) : Info 830: Location cited in prior message

*/

A few minutes with Splint or PC-Lint and a C book can tell you exactly
what is wrong.
It will also behoove you to learn how to use a debugger. It is a very
bad idea to try to program by the seat of your pants (meaning making
*guesses* about what various program constructs are supposed to be
doing). If you learn the correct meanings of the language constructs
and also how to use tools at your disposal then you can learn to be an
effective programmer. If you do not learn these things then you will
never learn to be an effective programmer. It is not difficult to do
it, though it can be a bit tedious.

[Bill Cunningham]

Re: seg fault


"Richard" <rgrdev@gmail.c omwrote in message
news:g39ant$ofd $1@registered.m otzarella.org.. .

"Bill Cunningham" <nospam@nspam.c omwrites:
>

>"Richard" <rgrdev@gmail.c omwrote in message
>news:g39964$fs s$1@registered. motzarella.org. ..

>>Try using a debugger. How many more times?

>>
>RIGHT.

>
Because I actually think you are too stuck in your ways to bother to
learn how to use one and you seem incapable of using Google I provide
you this link: (I think you mentioned you use gcc)
>

http://dirac.org/linux/gdb/

>
Read the "What is a debugger" part thoroughly.
>

http://dirac.org/linux/gdb/01-Introduction.php#whatisadebugger

>
Many people suggest using printf's. This is, IMO, amateurish at best.
>
From this web page:
>

[snip]

I use fprintfs to stderr so there's an error only if there's an error. I've
tried learning gdb. I don't read debugging symbols and gdb looks very
overwhelming atleast to me. I have it in my system and looked over the docs.
I thought about putting breakpoints into my program and gave up because
things were too complicated. With the trouble I'm having with C and I want
to stay with it I think my plate's pretty full right now. But I'll look at
your sites.

Bill

[Kenny McCormack]

Re: seg fault

In article <g39ant$ofd$1@r egistered.motza rella.org>,
Richard <rgrdev@gmail.c omwrote:

>"Bill Cunningham" <nospam@nspam.c omwrites:
>

>"Richard" <rgrdev@gmail.c omwrote in message
>news:g39964$fs s$1@registered. motzarella.org. ..

>>Try using a debugger. How many more times?

>>
>RIGHT.

>
>Because I actually think you are too stuck in your ways to bother to
>learn how to use one and you seem incapable of using Google I provide
>you this link: (I think you mentioned you use gcc)

Let me put in a word for the other side.

The problem with debuggers (at least all the ones I've used, including
gdb), is that they are very unfriendly, and mostly undocumented. I have
no doubt that when fully understood, they are quite powerful, but I have
never been able to wrap my head around one (of the type that we are
discussing here). man pages are no help. There's no built-in help.
There's no built-in useful error messages.

To continue this rant, I'm sure if I downloaded and studied (for a few
days and/or weeks) the voluminous documentation (in some weird GNU
format), I could probably become an expert in it, but it just ain't
worth the trouble.

[Richard]

Re: seg fault

"Bill Cunningham" <nospam@nspam.c omwrites:

"Richard" <rgrdev@gmail.c omwrote in message
news:g39ant$ofd $1@registered.m otzarella.org.. .

>"Bill Cunningham" <nospam@nspam.c omwrites:
>>

>>"Richard" <rgrdev@gmail.c omwrote in message
>>news:g39964$f ss$1@registered .motzarella.org ...
>>>Try using a debugger. How many more times?
>>>
>>RIGHT.

>>
>Because I actually think you are too stuck in your ways to bother to
>learn how to use one and you seem incapable of using Google I provide
>you this link: (I think you mentioned you use gcc)
>>
>http://dirac.org/linux/gdb/
>>
>Read the "What is a debugger" part thoroughly.
>>
>http://dirac.org/linux/gdb/01-Introd...hatisadebugger
>>
>Many people suggest using printf's. This is, IMO, amateurish at best.
>>
>From this web page:
>>

[snip]
>
I use fprintfs to stderr so there's an error only if there's an error. I've
tried learning gdb. I don't read debugging symbols and gdb looks very
overwhelming atleast to me. I have it in my system and looked over the docs.
I thought about putting breakpoints into my program and gave up because
things were too complicated. With the trouble I'm having with C and I want
to stay with it I think my plate's pretty full right now. But I'll look at
your sites.
>
Bill

It is one site. And it is there to help people. It could not be
easier. If you can not follow the instructions there then you should
really consider giving up - you will never be a programmer.