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_FAILURE);
}
fp=fopen( "data", "a");
ftell(fp);
fseek(fp,sizeof(double),SEEK_CUR);
fprintf(fp,"%.2f\n",x);
fclose(fp);
}

[Malcolm McLean]

"Bill Cunningham" <no****@nspam.comwrote 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_FAILURE);
}
fp=fopen( "data", "a");

You also need to check fp for nullness here.

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

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Bill Cunningham]

"Malcolm McLean" <re*******@btinternet.comwrote in message
news:7u******************************@bt.com...

"Bill Cunningham" <no****@nspam.comwrote 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_FAILURE);
}
fp=fopen( "data", "a");

You also need to check fp for nullness here.

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

[santosh]

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

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

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,"%.2f\n",x);
fclose(fp);
}

[Johannes Bauer]

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.electronics <47***********************@news.freenet.de>

[Bill Cunningham]

"santosh" <sa*********@gmail.comwrote in message
news:g3**********@registered.motzarella.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_FAILURE);
}

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

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,"%.2f\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]

"Bill Cunningham" <no****@nspam.comwrites:

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_FAILURE);
}
fp=fopen( "data", "a");
ftell(fp);
fseek(fp,sizeof(double),SEEK_CUR);
fprintf(fp,"%.2f\n",x);
fclose(fp);
}

Try using a debugger. How many more times?

[Bill Cunningham]

"santosh" <sa*********@gmail.comwrote in message
news:g3**********@registered.motzarella.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_FAILURE);
}

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

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,"%.2f\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.comwrote in message
news:g3**********@registered.motzarella.org...

Try using a debugger. How many more times?

RIGHT.

[santosh]

Bill Cunningham wrote:

>
"santosh" <sa*********@gmail.comwrote in message
news:g3**********@registered.motzarella.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_FAILURE);
}

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

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,"%.2f\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*********@gmail.comwrote in message
news:g3**********@registered.motzarella.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_FAILURE);
}

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

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,"%.2f\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" <[e-mail]:

* * 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_FAILURE);
* * * *}
* * fp=fopen( "data", "a");
* * ftell(fp);
* * fseek(fp,sizeof(double),SEEK_CUR);
* * fprintf(fp,"%.2f\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_FAILURE);
}
fp=fopen( "data", "a");
ftell(fp);
fseek(fp,sizeof(double),SEEK_CUR);
fprintf(fp,"%.2f\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\stdio.h)
C:\Program Files\Microsoft Visual Studio 8\VC\INCLUDE\stdio.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.comwrote in message
news:g3**********@registered.motzarella.org...

"Bill Cunningham" <no****@nspam.comwrites:

>"Richard" <rg****@gmail.comwrote 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

[Kenny McCormack]

In article <g3**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:

>"Bill Cunningham" <no****@nspam.comwrites:

>"Richard" <rg****@gmail.comwrote 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)

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]

"Bill Cunningham" <no****@nspam.comwrites:

"Richard" <rg****@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

>"Bill Cunningham" <no****@nspam.comwrites:

>>"Richard" <rg****@gmail.comwrote 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

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.

[Richard]

ga*****@xmission.xmission.com (Kenny McCormack) writes:

In article <g3**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:

>>"Bill Cunningham" <no****@nspam.comwrites:

>>"Richard" <rg****@gmail.comwrote 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)

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.

Or alternatively you could just read the tutorial I linked to ....

Using a debugger is a lot easier than sprinkling prints around,
recompiling etc.

And with Bill's attention span god knows that he will mess up when he
keeps re-editing the code to add and remove printfs.

[Kenny McCormack]

In article <g3**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:

>ga*****@xmission.xmission.com (Kenny McCormack) writes:

>In article <g3**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:

>>>"Bill Cunningham" <no****@nspam.comwrites:

"Richard" <rg****@gmail.comwrote 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)

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.

Or alternatively you could just read the tutorial I linked to ....

Using a debugger is a lot easier than sprinkling prints around,
recompiling etc.

And with Bill's attention span god knows that he will mess up when he
keeps re-editing the code to add and remove printfs.

Like I said, I've tried. I've tried all those so-called tutorials.

There seems to be a cult associated with C debuggers, much like the cult
associated with this newsgroup. The "It was hard for me; it should be
hard for you" cult.

[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.?

[Richard]

ga*****@xmission.xmission.com (Kenny McCormack) writes:

In article <g3**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:

>>ga*****@xmission.xmission.com (Kenny McCormack) writes:

>>In article <g3**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:
"Bill Cunningham" <no****@nspam.comwrites:

"Richard" <rg****@gmail.comwrote 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)

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.

Or alternatively you could just read the tutorial I linked to ....

Using a debugger is a lot easier than sprinkling prints around,
recompiling etc.

And with Bill's attention span god knows that he will mess up when he
keeps re-editing the code to add and remove printfs.

Like I said, I've tried. I've tried all those so-called tutorials.

There seems to be a cult associated with C debuggers, much like the cult
associated with this newsgroup. The "It was hard for me; it should be
hard for you" cult.

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.

[santosh]

Kenny McCormack wrote:

In article <g3**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:

>>"Bill Cunningham" <no****@nspam.comwrites:

>>"Richard" <rg****@gmail.comwrote 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)

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.

The GDB manual is one of the largest of GNU's manuals.

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.

info gdb

There's no
built-in help.

Try typing 'help' at the GDB prompt.

There's no built-in useful error messages.

GDB has often been accused of excessive verbosity, but this accusation
is the first I'm seeing.

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]

santosh <sa*********@gmail.comwrites:

Kenny McCormack wrote:

>In article <g3**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:

>>>"Bill Cunningham" <no****@nspam.comwrites:

"Richard" <rg****@gmail.comwrote 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)

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.

The GDB manual is one of the largest of GNU's manuals.

For a reason : it does a lot. But the CORE functionality is simple and
VERY easy to use.

>

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

info gdb

Same info as the man pages normally. And I agree it is only useful for
reference - certainly not for a tutorial unless you are experienced
enough.

[Richard Tobin]

In article <g3**********@news.xmission.com>,
Kenny McCormack <ga*****@xmission.xmission.comwrote:

>>Using a debugger is a lot easier than sprinkling prints around,
recompiling etc.

>Like I said, I've tried. I've tried all those so-called tutorials.

There seems to be a cult associated with C debuggers, much like the cult
associated with this newsgroup. The "It was hard for me; it should be
hard for you" cult.

Some people find it easier to use debuggers, some to use other
methods. But when a program gets a segmentation fault, it's hard to
see what could be easier as the first step than running it under a
debugger (typically you just type "run" followed by the arguments
you want) and looking to see where the error occurred (typically
by typing "where"). Looking at the value of variables involved in
the line in question is also trivial ("print x", for example).

Often at this point the error becomes obvious, and even if you do
nothing else with the debugger you've probably got your money's worth.

-- Richard

--
In the selection of the two characters immediately succeeding the numeral 9,
consideration shall be given to their replacement by the graphics 10 and 11 to
facilitate the adoption of the code in the sterling monetary area. (X3.4-1963)

[Bill Cunningham]

"Richard" <rg****@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

ga*****@xmission.xmission.com (Kenny McCormack) writes:

>In article <g3**********@registered.motzarella.org>,
Richard <rg****@gmail.comwrote:

>>>"Bill Cunningham" <no****@nspam.comwrites:

"Richard" <rg****@gmail.comwrote in message
news:g3**********@registered.motzarella.org.. .

And with Bill's attention span god knows that he will mess up when he
keeps re-editing the code to add and remove printfs.

Concentration. Try 1 mg Klonopin 3x a day for several years. If you know
where your driving to good for you. The my head is the best debuggers we
better get ready to lose the planet.

Bill

[Bill Cunningham]

"Richard" <rg****@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

ga*****@xmission.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

[Bill Cunningham]

"santosh" <sa*********@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

Try typing 'help' at the GDB prompt.

GDB has often been accused of excessive verbosity, but this accusation
is the first I'm seeing.

That's when all hell breaks lose. When you type help you get a list of
commands that you need to type help 'command' to and get a sparse
desciption. Been there and don't want to go back.

Bill

[santosh]

Bill Cunningham wrote:

>
"Richard" <rg****@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

>ga*****@xmission.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.comwrites:

"Richard" <rg****@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

>ga*****@xmission.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.

[Richard]

"Bill Cunningham" <no****@nspam.comwrites:

"santosh" <sa*********@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

>Try typing 'help' at the GDB prompt.

GDB has often been accused of excessive verbosity, but this accusation
is the first I'm seeing.

That's when all hell breaks lose. When you type help you get a list of
commands that you need to type help 'command' to and get a sparse
desciption. Been there and don't want to go back.

Bill

Which is why you read the tutorial which introduces it bit by bit. Duh.

[santosh]

Bill Cunningham wrote:

>
"santosh" <sa*********@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

>Try typing 'help' at the GDB prompt.

[ ... ]

That's when all hell breaks lose. When you type help you get a
list of commands that you need to type help 'command' to and get a
sparse desciption. Been there and don't want to go back.

Then try 'info gdb' at the command prompt.

[Richard]

santosh <sa*********@gmail.comwrites:

Bill Cunningham wrote:

>>
"santosh" <sa*********@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

>>Try typing 'help' at the GDB prompt.

[ ... ]

> That's when all hell breaks lose. When you type help you get a
list of commands that you need to type help 'command' to and get a
sparse desciption. Been there and don't want to go back.

Then try 'info gdb' at the command prompt.

Santosh, why on earth would you recommend him the info pages? he has
already stated that he can't cope with them. They are way too
complicated for him. There are oodles of simple tutorials that would
much better suit his abilities at this stage.

[santosh]

Richard wrote:

santosh <sa*********@gmail.comwrites:

>Bill Cunningham wrote:

>>>
"santosh" <sa*********@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

Try typing 'help' at the GDB prompt.

[ ... ]

>> That's when all hell breaks lose. When you type help you get a
list of commands that you need to type help 'command' to and get
a sparse desciption. Been there and don't want to go back.

Then try 'info gdb' at the command prompt.

Santosh, why on earth would you recommend him the info pages? he has
already stated that he can't cope with them. They are way too
complicated for him. There are oodles of simple tutorials that would
much better suit his abilities at this stage.

Oh, I must have missed his statement of inability to follow GDB's info
documentation. He did say that he got nothing useful from 'man gdb',
but that's expected, as the man page is just a synopsis of GDB's
options and commands. The info page is a full-fledged tutorial and
manual, coauthored by Stallman. At least, that was my introduction to
GDB, and I found (and still find) it easy and useful.

But maybe he should try a tutorial with a gentler learning curve. The
one hosted at dirac.org seems appropriate.

[Lew Pitcher]

In comp.lang.c, Malcolm McLean wrote:

"Bill Cunningham" <no****@nspam.comwrote 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.

Agreed.
I would recommend that the OP move the strtod() call to a point after the
argc test below...

> if (argc !=2) {
fprintf(stderr,"usage error\n");
exit(EXIT_FAILURE);
}

At this point, argv[1] is guaranteed to be a non-null pointer. So, the op's
strtod() code should work properly here.

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

This fopen() opens the file for appending only. That means, "open or create
text �le for writing at end-of-�le"

You also need to check fp for nullness here.

Agreed.

> ftell(fp);

Now, what is the above ftell() doing here? You (the OP) don't store the
results anywhere, and there are no usefull side-effects with ftell()

> fseek(fp,sizeof(double),SEEK_CUR);

Hmmmm.... According to the standards,
"Opening a �le with append mode ('a' as the �rst character in the mode
argument) causes all subsequent writes to the �le to be forced to the
then current end-of-�le, regardless of intervening calls to the fseek
function."
and
"For a text stream, either offset shall be zero, or offset shall be a
value returned by an earlier successful call to the ftell function on a
stream associated with the same �le and whence shall be SEEK_SET."

I'm afraid that this call won't reposition the "active position" in the file
for the next write (the fprintf() below). Not only does append mode negate
the fseek() call, but the whence value (SEEK_CUR) is not legal for the
(implied) file type (text, in the absence of a "b" mode character on the
fopen() call). Finally, /if/ this fseek worked, it wouold leave a
double-sized hole in the file (that being the movement implied by the
sizeof(double) against SEEK_CUR). Text files are rarely (never, in my
memory) sparse files; I'm not sure what that hole would do to subsequent
processing.

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

While I realize that, under C99, the 'falling off the edge' of the main()
function involves an implicit return of a value of 0 (which is the
equivalent termination status to EXIT_SUCCESS), it would be good to
a) check the results of the fclose(fp) call, and provide an explicit
EXIT_FAILURE if the file doesn't close properly, and
b) provide an explicit return of EXIT_SUCCESS otherwise
considering that you (the OP) have already used an explicit return of
EXIT_FAILURE in part of the logic above. Consistency is good.

>}

--
Lew Pitcher

Master Codewright & JOAT-in-training | Registered Linux User #112576
http://pitcher.digitalfreehold.ca/ | GPG public key available by request
---------- Slackware - Because I know what I'm doing. ------

[Bill Cunningham]

Your gdb says the segment fault I it's telling everything is in strtod
or strtod_internal.

Bill

[Bill Cunningham]

"Johannes Bauer" <df***********@gmx.dewrote in message
news:nt************@joeserver.homelan.net...

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

This is what gdb said
$1=1
$2=0

Do you know what it's saying. I can strip these executables of debugging
symbols and still get a partial symbol table. I sure would like to know
about BFDs like ELF COFF and win32/pe. Can gdb or a hexdump of the different
parts of a file show this ?

Bill

[Bill Cunningham]

"user923005" <dc*****@connx.comwrote in message
news:12**********************************@m73g2000 hsh.googlegroups.com...

[snip]

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.

Ok here's the program.
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv[])
{
FILE *fp;
double x;
if ((x = strtod (argv[1], NULL)) == '\0') /*segfault */
{
puts ("strtod error");
exit (EXIT_FAILURE);
}
if (argc 2)
{
fprintf (stderr, "usage error\n");
exit (EXIT_FAILURE);
}
if ((fp = fopen ("data", "a")) == NULL)
{
puts ("fopen error");
exit (EXIT_FAILURE);
}
if ((ftell (fp)) == -1)
{
puts ("ftell error");
exit (EXIT_FAILURE);
}
if ((fseek (fp, sizeof (double), SEEK_CUR)) == -1)
{
puts ("fseek error");
exit (EXIT_FAILURE);
}
fprintf (fp, "%.2f\n", x);
fclose (fp);
}

gdb says

$1=1
$2=0

Bill

[Richard]

"Bill Cunningham" <no****@nspam.comwrites:

Your gdb says the segment fault I it's telling everything is in strtod
or strtod_internal.

Bill

So there's your answer. The reason is obviously trivial.

[Richard]

"Bill Cunningham" <no****@nspam.comwrites:

"Johannes Bauer" <df***********@gmx.dewrote in message
news:nt************@joeserver.homelan.net...

>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

This is what gdb said
$1=1
$2=0

Do you know what it's saying. I can strip these executables of debugging
symbols and still get a partial symbol table. I sure would like to know
about BFDs like ELF COFF and win32/pe. Can gdb or a hexdump of the different
parts of a file show this ?

Bill

Try learning the very basics before bandying around big words.

[Richard]

"Bill Cunningham" <no****@nspam.comwrites:

"user923005" <dc*****@connx.comwrote in message
news:12**********************************@m73g2000 hsh.googlegroups.com...

[snip]

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.

Ok here's the program.
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv[])
{
FILE *fp;
double x;
if ((x = strtod (argv[1], NULL)) == '\0') /*segfault */
{
puts ("strtod error");
exit (EXIT_FAILURE);
}
if (argc 2)
{
fprintf (stderr, "usage error\n");
exit (EXIT_FAILURE);
}
if ((fp = fopen ("data", "a")) == NULL)
{
puts ("fopen error");
exit (EXIT_FAILURE);
}
if ((ftell (fp)) == -1)
{
puts ("ftell error");
exit (EXIT_FAILURE);
}
if ((fseek (fp, sizeof (double), SEEK_CUR)) == -1)
{
puts ("fseek error");
exit (EXIT_FAILURE);
}
fprintf (fp, "%.2f\n", x);
fclose (fp);
}

gdb says

$1=1
$2=0

Bill

Maybe time for you to give up Bill? You seem to get nowhere fast. You
know you should provide context. What the hell do you mean "gdb says"
here? It says it when? After you have done what? On what line of code?
Did you read the tutorial I linked to you where you are specifically
shown LINE BY LINE how to examine what caused a segfault? You know, the
one by RMS you said you would read?

[santosh]

Bill Cunningham wrote:

Your gdb says the segment fault I it's telling everything is in
strtod or strtod_internal.

Yes. Make sure that you pass strtod a pointer that actually points to
the string to be converted.

[Richard Heathfield]

santosh said:

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?

What are you suggesting, santosh - that there might be an error even if
there isn't an error?

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Richard]

santosh <sa*********@gmail.comwrites:

Bill Cunningham wrote:

> Your gdb says the segment fault I it's telling everything is in
strtod or strtod_internal.

Yes. Make sure that you pass strtod a pointer that actually points to
the string to be converted.

Don't spoon feed him or he will never learn. Teach him how to think and
work out the issue himself. Now he will probably just do a null check
and not learn anything at all and come whining back with the same issues
in about 16 hours. Learn how to use the tools to help yourself.

[Richard Heathfield]

Richard Tobin said:

In article <g3**********@news.xmission.com>,
Kenny McCormack <ga*****@xmission.xmission.comwrote:

>>>Using a debugger is a lot easier than sprinkling prints around,
recompiling etc.

>>Like I said, I've tried. I've tried all those so-called tutorials.

There seems to be a cult associated with C debuggers, much like the cult
associated with this newsgroup. The "It was hard for me; it should be
hard for you" cult.

Some people find it easier to use debuggers, some to use other
methods. But when a program gets a segmentation fault, it's hard to
see what could be easier as the first step than running it under a
debugger (typically you just type "run" followed by the arguments
you want) and looking to see where the error occurred (typically
by typing "where").

Let me open your eyes, then. Easier than the steps you mention is to type:

gdb ./foo core
(gdb) bt

which tells you what line the segfault occurred on. From there, it's
normally pretty easy to find out what went wrong.

Note that "normally" != "always".

Those who advocate debugger programs are doing a fine thing. Those who
advocate debugging without such a program are also doing a fine thing.
Those who advocate using the right tool at the right time, the tool that
does the job *for you*, are doing an even finer thing. But those who
advocate mindless adherence to one view or the other could do the world a
favour by becoming politicians instead of programmers.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Bill Cunningham]

"Richard" <rg****@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

"Bill Cunningham" <no****@nspam.comwrites:

Maybe time for you to give up Bill?

On C? No

You seem to get nowhere fast.

That's for damn sure.

You

know you should provide context. What the hell do you mean "gdb says"
here? It says it when? After you have done what? On what line of code?
Did you read the tutorial I linked to you where you are specifically
shown LINE BY LINE how to examine what caused a segfault? You know, the
one by RMS you said you would read?

Yep. On windows then switched to my linux system and started to use gdb
and looks like I forgot what I read or what I thought I read. I run a dual
boot.

Bill

>

[Bill Cunningham]

"Richard" <rg****@gmail.comwrote in message
news:g3**********@registered.motzarella.org...

Don't spoon feed him or he will never learn.

Not quite.

Teach him how to think

impossible probably.

and
work out the issue himself.

I've worked on issuses for years and not learned. Alot is because I wasn't
taught right.

Now he will probably just do a null check

and not learn anything at all and come whining back with the same issues
in about 16 hours. Learn how to use the tools to help yourself.

I say nothing beats understanding C. A debugger doesn't teach. It helps
point things out. Fprintf redirected to bash's stderr is still pretty damn
good.

Bill

[santosh]

Bill Cunningham wrote:

<snip>

Ok here's the program.
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv[])
{
FILE *fp;
double x;
if ((x = strtod (argv[1], NULL)) == '\0') /*segfault */

Oh dear. What are you doing comparing strtod's return value with a null
character?

Strtod return +/-HUGE_VAL in case of overflow and zero in case of
underflow and failure to convert for other reasons. If either overflow
or underflow has occurred errno will contain ERANGE.

So a better method of using strtod is:

#include <errno.h>
#include <stdlib.h>
#include <math.h>

int main(int argc, char **argv) {
double x;
char *endptr;
if (argc < 2) {
/* insufficient arguments */
exit(EXIT_FAILURE);
}
errno = 0;
x = strtod(argv[1], endptr);
if (errno == ERANGE) {
if (fabs(x) == HUGE_VAL) {
fprintf(stderr, "Overflow.\n");
}
else if (x == 0) {
fprintf(stderr, "Underflow.\n");
}
exit(EXIT_FAILURE);
}
else if (x == 0) {
fprintf(stderr, "Conversion failure. Stopped at %s\n", endptr);
exit(EXIT_FAILURE);
}
/* proceed */

{
puts ("strtod error");
exit (EXIT_FAILURE);
}
if (argc 2)
{
fprintf (stderr, "usage error\n");
exit (EXIT_FAILURE);
}

As you were told previously, checking of argc must come *before* the
call to strtod.

if ((fp = fopen ("data", "a")) == NULL)
{
puts ("fopen error");
exit (EXIT_FAILURE);
}
if ((ftell (fp)) == -1)
{
puts ("ftell error");
exit (EXIT_FAILURE);
}
if ((fseek (fp, sizeof (double), SEEK_CUR)) == -1)
{
puts ("fseek error");
exit (EXIT_FAILURE);
}
fprintf (fp, "%.2f\n", x);
fclose (fp);
}

gdb says

$1=1
$2=0

Bill

[santosh]

Richard Heathfield wrote:

santosh said:

>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?

What are you suggesting, santosh - that there might be an error even
if there isn't an error?

I was asking Bill why "there's an error only if there's an error" only
when he is using fprintf. :-)

One or more errors could have occurred before the fprintf call, perhaps
after it, perhaps in the call itself. Fprintf doesn't guarantee that
you will spot all your errors.

[Richard Heathfield]

santosh said:

Richard Heathfield wrote:

>santosh said:

>>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?

What are you suggesting, santosh - that there might be an error even
if there isn't an error?

I was asking Bill why "there's an error only if there's an error" only
when he is using fprintf. :-)

One or more errors could have occurred before the fprintf call, perhaps
after it, perhaps in the call itself. Fprintf doesn't guarantee that
you will spot all your errors.

I've never heard of Fprintf - but you can't begin a sentence with a lower
case letter! Ain't the English/C boundary wonderful? :-)

Seriously, you are obviously right - it's our job to spot bugs, and fprintf
is at best a tool that can help us to do that (just as a debugger is only
a tool). Tools are useful, but only fools rely on them to do things they
are not designed to do. We can *use* tools to do things they are not
designed to do, but if we are wise we will recognise that they may not
achieve the goal we intend.

In this case, the best approach is probably to use a debugger to find out
where the seg fault is occurring, and then apply one's brain to find the
cause. Debuggers /can/ help with this, especially good ones that let you
explore the state of the call stack (e.g. the Visual C++ debugger, or
gdb), but they are no magic wand, and no substitute for a clear head and a
knowledge of the language.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999

[Sensei]

On 2008-06-17 23:50:05 +0200, ga*****@xmission.xmission.com (Kenny
McCormack) said:

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 [...]

Ok, I will now add an heresy. Why don't we suggest an IDE so that a
debugger is at one click away? The command line may come later.

--

Sensei*<Sensei's e-mail is at Mac-dot-com>

Three things are certain
Death, taxes, and lost data
Guess which has occurred. (Computer's Haiku)

[Barry Schwarz]

On Tue, 17 Jun 2008 20:22:03 GMT, "Bill Cunningham" <no****@nspam.com>
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

So you actually want the program to produce a segmentation fault? What
is the problem then?

>segmentation fault. If I add the proper value say 43.56 it's fine. Does

Given the number of errors in your code, that is unlikely.

>anyone see what's wrong ? I have a c99 compiler. Thanks.

Which compiler are you using that you think is C99?

>
#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_FAILURE);
}
fp=fopen( "data", "a");
ftell(fp);
fseek(fp,sizeof(double),SEEK_CUR);

You open the file for text. What do you think the sizeof(double) has
to do with anything in a text file?

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

Remove del for email

[Barry Schwarz]

On Wed, 18 Jun 2008 02:31:44 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:

>Ok here's the program.
#include <stdio.h>
#include <stdlib.h>

int
main (int argc, char *argv[])
{
FILE *fp;
double x;
if ((x = strtod (argv[1], NULL)) == '\0') /*segfault */

Why are you bothering to post? You ignored all the people who told
five hours before this message you how to fix this.

Why do you think that x being assigned a value of 0 (or 0.0 if you
prefer) is an error? It's a perfectly valid result from strtod.

{
puts ("strtod error");

Why does this error go to stdout ...

exit (EXIT_FAILURE);
}
if (argc 2)
{
fprintf (stderr, "usage error\n");

while this one goes to stderr?

exit (EXIT_FAILURE);
}
if ((fp = fopen ("data", "a")) == NULL)
{
puts ("fopen error");
exit (EXIT_FAILURE);
}
if ((ftell (fp)) == -1)

What happens if ftell doesn't fail? You never save the value it
returns. What is the purpose of calling the function?

{
puts ("ftell error");
exit (EXIT_FAILURE);
}
if ((fseek (fp, sizeof (double), SEEK_CUR)) == -1)

At least three errors here:

fseek is not guaranteed to return -1 on error. It returns
non-zero.

You open fp for text. For a text file, the offset must be 0
or a value returned by ftell. sizeof(double) is neither. For a
non-zero offset, the origin must be SEEK_SET.

{
puts ("fseek error");
exit (EXIT_FAILURE);
}
fprintf (fp, "%.2f\n", x);
fclose (fp);
}

Remove del for email