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);
}

[Richard]

"Bill Cunningham" <no****@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]

"santosh" <sa*********@gm ail.comwrote in message
news:g3******** **@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]

"Richard" <rg****@gmail.c omwrote in message
news:g3******** **@registered.m otzarella.org.. .

Try using a debugger. How many more times?

RIGHT.

[santosh]

Bill Cunningham wrote:

>
"santosh" <sa*********@gm ail.comwrote in message
news:g3******** **@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]

Bill Cunningham wrote:

>
"santosh" <sa*********@gm ail.comwrote in message
news:g3******** **@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]

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_FAIL URE);
* * * *}
* * 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]

"Richard" <rg****@gmail.c omwrote in message
news:g3******** **@registered.m otzarella.org.. .

"Bill Cunningham" <no****@nspam.c omwrites:

>"Richard" <rg****@gmail.c omwrote in message
news:g3******* ***@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

[santosh]

Bill Cunningham wrote:

[ ... ]

I use fprintfs to stderr so there's an error only if there's an error.

How do you come to this conclusion?

I've tried learning gdb. I don't read debugging symbols

It's the purpose of the debugger to read debugging symbols. You
certainly are not expected to do so.

and gdb looks
very overwhelming atleast to me.

It is a complicated program, but it is fairly easy to learn a few basic
commands that would do in your case.

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.

Why don't you try one of the many GUI drivers available for GDB like
DDD, Eclipse's built-in debugger etc.?

[santosh]

Bill Cunningham wrote:

>
"Richard" <rg****@gmail.c omwrote in message
news:g3******** **@registered.m otzarella.org.. .

>ga*****@xmissio n.xmission.com

>Hmm. I am surprised. How hard can it be to do something like "step to
next line of code" and examine the local variables?

Or to type "backtrace" when their is a seg fault?

It's this easy:

http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html

Still, if you think it doesn't help you then all to their own.

Did Richard Stallman write the above? If so I'll try it.

Stallman will pleased to hear this.

[Richard]

"Bill Cunningham" <no****@nspam.c omwrites:

"Richard" <rg****@gmail.c omwrote in message
news:g3******** **@registered.m otzarella.org.. .

>ga*****@xmissio n.xmission.com

>Hmm. I am surprised. How hard can it be to do something like "step to
next line of code" and examine the local variables?

Or to type "backtrace" when their is a seg fault?

It's this easy:

http://www.unknownroad.com/rtfm/gdbtut/gdbsegfault.html

Still, if you think it doesn't help you then all to their own.

Did Richard Stallman write the above? If so I'll try it.

Bill

Try clicking on it and using your brain for a change. But the best
advice I can offer you is to give up. You'll never crack it. Prove me
wrong.