469,352 Members | 1,661 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,352 developers. It's quick & easy.

Redirecting input from file

Hi All, I am working on a program to take input from a txt file, do
some calculations, and then output the results to another txt file.
The program that I've written compiles fine for me, however, when I
run it, it stalls and does nothing. I'm wondering if there's something
obvious that I'm missing. My code is below and any help would be
appreciated.

Thanks,
Dave

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

int main(int argc, char *argv[])
{
/* Variable Declarations */
const int arraylength = 5000;
const int errorcode = -1;
float sum = 0;
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
long* date = (long*)NULL;
FILE *fpin;
FILE *fpout;

fpin = fopen(argv[1],"r+");
fpout = fopen(argv[2],"w");

/* Array Allocation */
precipvals = (float*)malloc(sizeof(int) * arraylength);
precip3hrs = (float*)malloc(sizeof(int) * arraylength);
date = (long*)malloc(sizeof(int) * arraylength);

/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%l,%f", &date[count], &precipvals[count]);
if(feof(fpin)) {
fclose(fpin);
return -3;
}
if(count == 1) {
precip3hrs[count] = precipvals[count];
}
if(count == 2) {
precip3hrs[count] = precipvals[count] + precip3hrs[count-1];
}
if(count 2) {
precip3hrs[count] = precipvals[count] + precipvals[count-1] +
precipvals[count-2];
}
}

/* Output section */
for(count = 1; count <= arraylength; count++) {
if(count == 1) {
printf("One hour precipitation: %2.2f Three hour precipitation %2.2f
\n",precipvals[count],precip3hrs[count]);
}
if(count == 2) {
printf("One hour precipitation: %2.2f Three hour precipitation %2.2f
\n",precipvals[count],precip3hrs[count]);
}
if(count 2) {
printf("One hour precipitation: %2.2f Three hour precipitation %2.2f
\n",precipvals[count],precip3hrs[count]);
}
}

/* Write to file */
for(count = 1; count <= arraylength; count++) {
if(count == 1) {
fprintf(fpout, "One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count == 2) {
fprintf(fpout,"One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count 2) {
fprintf(fpout,"One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
}
fclose(fpin);
fclose(fpout);

/* Deallocation */
free(date);
date = (long*)NULL;
free(precipvals);
precipvals = (float*)NULL;
free(precip3hrs);
precip3hrs = (float*)NULL;
return 0;
}

Jun 28 '07
116 4025
Barry Schwarz said:
On Wed, 04 Jul 2007 14:19:10 +0000, Richard Heathfield wrote:
>>dm******@cox.net said:
>>Cannot convert 'void*' to 'float*' in function main(int, char * *)

Either:

(a) you forgot to #include <stdlib.h>

Then the message would say "cannot convert int to float*"
Oh, well done, sir. Yes, okay, so much for (a).

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 4 '07 #51
On Jul 4, 7:12 am, "Army1987" <please....@for.itwrote:
Are you compiling it with a C++ compiler?
(If so, I'd be surprised of knowing free() works even without
casting the argument to void*).
In C++ there is an implicit conversion from
any object pointer type to void*, so there is
no need to cast any argument to free().

(Follow-ups set to c.l.c++)

Jul 4 '07 #52
Old Wolf wrote:
On Jul 4, 7:12 am, "Army1987" <please....@for.itwrote:
>Are you compiling it with a C++ compiler? (If so, I'd be surprised
of knowing free() works even without casting the argument to void*).

In C++ there is an implicit conversion from any object pointer type
to void*, so there is no need to cast any argument to free().

(Follow-ups set to c.l.c++)
Wrong. In C++ there is NO such implicit conversion. That is in C
only. Follow-ups set to c.l.c.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jul 5 '07 #53
On Jul 5, 11:26 am, CBFalconer <cbfalco...@yahoo.comwrote:
Old Wolf wrote:
On Jul 4, 7:12 am, "Army1987" <please....@for.itwrote:
Are you compiling it with a C++ compiler? (If so, I'd be
surprised of knowing free() works even without casting the
argument to void*).
In C++ there is an implicit conversion from any object pointer
type to void*, so there is no need to cast any argument to
free().

Wrong. In C++ there is NO such implicit conversion.
ISO/IEC 14882:1998, 4.10/2:
An rvalue of type "pointer to cv T," where T is an
object type, can be converted to an rvalue of type
"pointer to cv void." The result of converting a
"pointer to cv T" to a "pointer to cv void" points
to the start of the storage location where the object
of type T resides

You must be thinking of something else (perhaps
the fact that there's no implicit conversion
from void * to other pointer types).
That is in C only. Follow-ups set to c.l.c.
Not sure why you want to discuss C++ in c.l.c.

Jul 5 '07 #54
CBFalconer wrote:
Old Wolf wrote:
In C++ there is an implicit conversion from any object pointer type
to void*, so there is no need to cast any argument to free().

(Follow-ups set to c.l.c++)

Wrong. In C++ there is NO such implicit conversion. That is in C
only. Follow-ups set to c.l.c.

Yeah, there is. What's lacking is the implicit conversion from void* to
object pointer. Hence malloc() and friends require a cast in C++.


Brian
Jul 5 '07 #55
Old Wolf wrote:

In C++ there is an implicit conversion from
any object pointer type to void*, so there is
no need to cast any argument to free().

(Follow-ups set to c.l.c++)
Don't set follow-ups unless when the post wasn't cross there in the
first place.

Brian

Jul 5 '07 #56
CBFalconer <cb********@yahoo.comwrote:
Richard Heathfield wrote:

Drop all those silly casts. If that gives you diagnostic messages
at compile time or breaks the behaviour at runtime, *tell us*, and
we'll show you how to fix it. 99.9908237% of the time, casts
aren't the right fix. ^^^^^^^^^^

Are you implying that 1,000,000,000 (or 1e9) casts have been
generated by programmers since C89 was published? Or are you
counting multiple use of the same cast, when a program is
recompiled, copied, etc.? :-)
No; he's implying that of every 108976 casts written since C89 was
published, no more than 10 were The Right Thing. This would mean that
0.00917633240346...% of casts were right; but since there is only a
limited amount of certainty in the starting data, we should clip this
to, say, five significant digits, leaving 0.0091763% of right casts, and
therefore 99.9908237% wrong ones.

I must say, what with the enormous amount of badly written OS code out
there, much of it C-wannabe-C++, those figures sound reasonable to me.

Richard
Jul 5 '07 #57
Here is my code as of now, as well as an input file and my output. I
am aware that I've got more error proofing to do, but this is what I
have right now.

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

int main(int argc, char *argv[])
{
/* Variable Declarations */
const int arraylength = 5000;
const int exiterrorcode = -1;
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
long* date = (long*)NULL;
FILE *fpin;
FILE *fpout;

fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");

if(fpin == NULL || fpout == NULL) {
printf("Insufficient arguments\n");
exit(exiterrorcode);
}

/* Array Allocation */
precipvals = (float*)malloc(sizeof(float) * arraylength);
precip3hrs = (float*)malloc(sizeof(float) * arraylength);
date = (long*)malloc(sizeof(long) * arraylength);

/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date[count],
&precipvals[count]);
if(count == 0) {
precip3hrs[count] = precipvals[count];
}
if(count == 1) {
precip3hrs[count] = precipvals[count] + precip3hrs[count-1];
}
if(count 1) {
precip3hrs[count] = precipvals[count] + precipvals[count-1] +
precipvals[count-2];
}
count++;
}

/* Output section */
for(count = 0; count < arraylength; count++) {
if(!(precipvals[count] == 0 && precip3hrs[count] == 0)) {
if(count == 0) {
printf("One hour precipitation: %2.2f Three hour precipitation
%2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count == 1) {
printf("One hour precipitation: %2.2f Three hour precipitation
%2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count 1) {
printf("One hour precipitation: %2.2f Three hour precipitation
%2.2f\n",precipvals[count],precip3hrs[count]);
}
}
}
/* Write to file */
for(count = 0; count < arraylength; count++) {
if(!(precipvals[count] == 0 && precip3hrs[count] == 0)) {
if(count == 0) {
fprintf(fpout,"One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count == 1) {
fprintf(fpout, "One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count 1) {
fprintf(fpout, "One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
}
}

fclose(fpin);
fclose(fpout);

/* Deallocation */
free(precipvals);
precipvals = (float*)NULL;
free(precip3hrs);
precip3hrs = (float*)NULL;
date = (long*)NULL;
free(date);

return 0;
}

Input file
200701010000,3.58
200701010100,2.33
200701010200,4.55
200701010300,.29
200701010400,5.18
200701010500,0
200701010600,0
200701010700,0
200701010800,0
200701010900,.34

Output file
One hour precipitation: 3.58 Three hour precipitation 3.58
One hour precipitation: 2.33 Three hour precipitation 5.91
One hour precipitation: 4.55 Three hour precipitation 10.46
One hour precipitation: 0.29 Three hour precipitation 7.17
One hour precipitation: 5.18 Three hour precipitation 10.02
One hour precipitation: 0.00 Three hour precipitation 5.47
One hour precipitation: 0.00 Three hour precipitation 5.18
One hour precipitation: 0.34 Three hour precipitation 0.34
One hour precipitation: 0.00 Three hour precipitation 0.34

TIA
Dave

Jul 5 '07 #58
Now that I look at the code some more, I think there's a few areas
that I can remove i.e if(count = 0) etc. but I'm not sure.

Dave

Jul 5 '07 #59
"dm******@cox.net" wrote:
>
Here is my code as of now, as well as an input file and my output.
I am aware that I've got more error proofing to do, but this is
what I have right now.

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

int main(int argc, char *argv[])
{
/* Variable Declarations */
To start with, control your indentation. 3 spaces is enough.
Don't use tabs for Usenet display.
const int arraylength = 5000;
const int exiterrorcode = -1;
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
long* date = (long*)NULL;
The above casts are unnecessary, and only serve to hide possible
errors. This is not C++.
FILE *fpin;
FILE *fpout;

fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");

if(fpin == NULL || fpout == NULL) {
printf("Insufficient arguments\n");
exit(exiterrorcode);
}
I believe passing NULL to fopen results in undefined behaviour.
Use argc.
>
/* Array Allocation */
precipvals = (float*)malloc(sizeof(float) * arraylength);
precip3hrs = (float*)malloc(sizeof(float) * arraylength);
date = (long*)malloc(sizeof(long) * arraylength);
Again, the casts are unnecessary etc.
>
/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date[count],
&precipvals[count]);
Here unless 'condition' is 2 fscanf failed. I also gave up
following the code.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jul 5 '07 #60
"dm******@cox.net" <dm******@cox.netwrites:
Here is my code as of now, as well as an input file and my output. I
am aware that I've got more error proofing to do, but this is what I
have right now.
You have not taken some of the advice already given but, what the
hell, lets have another go...
#include <stdio.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
/* Variable Declarations */
No need for comments like this. If the reader needs it, they will get
lost very soon. If they don't who is it for?
const int arraylength = 5000;
const int exiterrorcode = -1;
C already has name for this: EXIT_FAILURE. It is standard and already
defined (I know here you got your version from and it is not the worst
thing in the course notes, but it is still much worse than using
EXIT_FAILURE).
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
long* date = (long*)NULL;
None of the casts in the program are required (the same is true, I
think, for all the casts in your course notes as well) and they just
serve to confuse the reader.
FILE *fpin;
FILE *fpout;

fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");

if(fpin == NULL || fpout == NULL) {
printf("Insufficient arguments\n");
exit(exiterrorcode);
}
It is too late by this time. You could write this:

fpin = argc 1 ? fopen(argv[1], "r") : NULL);
fpout = argc 2 ? fopen(argv[2], "w") : NULL);

and then your test will work but, really, you should report unopenable
files as distinct from not enough arguments.
/* Array Allocation */
precipvals = (float*)malloc(sizeof(float) * arraylength);
precip3hrs = (float*)malloc(sizeof(float) * arraylength);
date = (long*)malloc(sizeof(long) *
arraylength);
the form: 'date = malloc(arraylength * sizeof *date);' has so much
going for it, I can't see why it not morewidely used!

....and you know you need to test the results.
/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date[count],
&precipvals[count]);
condition will never get to EOF if there is an error in the input
format. fscanf can return 1 or 0 and will continue to do so for ever
if the input is malformed. It is much better to test for everything
be hunky-dory:

while (count < array_length &&
fscanf(fpin, "%ld,%f", &date[count], &precipvals[count]) == 2) {

Note I have also checked count (first). You must not read data into
storage that does not exist.
if(count == 0) {
precip3hrs[count] = precipvals[count];
}
if(count == 1) {
precip3hrs[count] = precipvals[count] + precip3hrs[count-1];
}
if(count 1) {
precip3hrs[count] = precipvals[count] + precipvals[count-1] +
precipvals[count-2];
}
count++;
}
Personally, I would read the data, and then do the partial sums.
/* Output section */
for(count = 0; count < arraylength; count++) {
if(!(precipvals[count] == 0 && precip3hrs[count] == 0)) {
if(count == 0) {
printf("One hour precipitation: %2.2f Three hour precipitation
%2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count == 1) {
printf("One hour precipitation: %2.2f Three hour precipitation
%2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count 1) {
printf("One hour precipitation: %2.2f Three hour precipitation
%2.2f\n",precipvals[count],precip3hrs[count]);
}
}
}
I can't see the point of all those tests. You do the same thing in
every case. If you *do* want to do thing differently for different
counts, I'd put the special cases outside the loop and run the loop
from count = 2.
/* Write to file */
for(count = 0; count < arraylength; count++) {
if(!(precipvals[count] == 0 && precip3hrs[count] == 0)) {
if(count == 0) {
fprintf(fpout,"One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count == 1) {
fprintf(fpout, "One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count 1) {
fprintf(fpout, "One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
}
}
Ditto.
fclose(fpin);
fclose(fpout);

/* Deallocation */
free(precipvals);
precipvals = (float*)NULL;
free(precip3hrs);
precip3hrs = (float*)NULL;
date = (long*)NULL;
free(date);
That must be a typo. Surely you want to free(date) then set it to
NULL? Personally, I would just write:

free(precipvals);
free(precip3hrs);
free(date);

--
Ben.
Jul 5 '07 #61
On Jul 5, 1:34 pm, Ben Bacarisse <ben.use...@bsb.me.ukwrote:
"dmora...@cox.net" <dmora...@cox.netwrites:
Here is my code as of now, as well as an input file and my output. I
am aware that I've got more error proofing to do, but this is what I
have right now.

You have not taken some of the advice already given but, what the
hell, lets have another go...
#include <stdio.h>
#include <stdlib.h>
int main(int argc, char *argv[])
{
/* Variable Declarations */

No need for comments like this. If the reader needs it, they will get
lost very soon. If they don't who is it for?
const int arraylength = 5000;
const int exiterrorcode = -1;

C already has name for this: EXIT_FAILURE. It is standard and already
defined (I know here you got your version from and it is not the worst
thing in the course notes, but it is still much worse than using
EXIT_FAILURE).
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
long* date = (long*)NULL;

None of the casts in the program are required (the same is true, I
think, for all the casts in your course notes as well) and they just
serve to confuse the reader.
FILE *fpin;
FILE *fpout;
fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");
if(fpin == NULL || fpout == NULL) {
printf("Insufficient arguments\n");
exit(exiterrorcode);
}

It is too late by this time. You could write this:

fpin = argc 1 ? fopen(argv[1], "r") : NULL);
fpout = argc 2 ? fopen(argv[2], "w") : NULL);

and then your test will work but, really, you should report unopenable
files as distinct from not enough arguments.
/* Array Allocation */
precipvals = (float*)malloc(sizeof(float) * arraylength);
precip3hrs = (float*)malloc(sizeof(float) * arraylength);
date = (long*)malloc(sizeof(long) *
arraylength);

the form: 'date = malloc(arraylength * sizeof *date);' has so much
going for it, I can't see why it not morewidely used!

...and you know you need to test the results.
/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date[count],
&precipvals[count]);

condition will never get to EOF if there is an error in the input
format. fscanf can return 1 or 0 and will continue to do so for ever
if the input is malformed. It is much better to test for everything
be hunky-dory:

while (count < array_length &&
fscanf(fpin, "%ld,%f", &date[count], &precipvals[count]) == 2) {

Note I have also checked count (first). You must not read data into
storage that does not exist.
if(count == 0) {
precip3hrs[count] = precipvals[count];
}
if(count == 1) {
precip3hrs[count] = precipvals[count] + precip3hrs[count-1];
}
if(count 1) {
precip3hrs[count] = precipvals[count] + precipvals[count-1] +
precipvals[count-2];
}
count++;
}

Personally, I would read the data, and then do the partial sums.
/* Output section */
for(count = 0; count < arraylength; count++) {
if(!(precipvals[count] == 0 && precip3hrs[count] == 0)) {
if(count == 0) {
printf("One hour precipitation: %2.2f Three hour precipitation
%2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count == 1) {
printf("One hour precipitation: %2.2f Three hour precipitation
%2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count 1) {
printf("One hour precipitation: %2.2f Three hour precipitation
%2.2f\n",precipvals[count],precip3hrs[count]);
}
}
}

I can't see the point of all those tests. You do the same thing in
every case. If you *do* want to do thing differently for different
counts, I'd put the special cases outside the loop and run the loop
from count = 2.
/* Write to file */
for(count = 0; count < arraylength; count++) {
if(!(precipvals[count] == 0 && precip3hrs[count] == 0)) {
if(count == 0) {
fprintf(fpout,"One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count == 1) {
fprintf(fpout, "One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
if(count 1) {
fprintf(fpout, "One hour precipitation: %2.2f Three hour
precipitation %2.2f\n",precipvals[count],precip3hrs[count]);
}
}
}

Ditto.
fclose(fpin);
fclose(fpout);
/* Deallocation */
free(precipvals);
precipvals = (float*)NULL;
free(precip3hrs);
precip3hrs = (float*)NULL;
date = (long*)NULL;
free(date);

That must be a typo. Surely you want to free(date) then set it to
NULL? Personally, I would just write:

free(precipvals);
free(precip3hrs);
free(date);

--
Ben.
Most of these I caught before I read your post. Thanks.

Dave

Jul 5 '07 #62
date = (long*)NULL;
free(date);
For some reason, my boss told me that when she reversed these two
lines, it wouldn't compile. It looked strange to me when I first saw
it, but I just went with it.

Dave

Jul 5 '07 #63
dm******@cox.net said:
>
date = (long*)NULL;
free(date);
For some reason, my boss told me that when she reversed these two
lines, it wouldn't compile. It looked strange to me when I first saw
it, but I just went with it.
It sounds like your boss needs to put the mouse down, and step away from
the keyboard. Programming by trial-and-error is never going to work.

Whilst it's legal to pass a null pointer to free(), it's also utterly
pointless.

If

free(date);
date = NULL;

doesn't compile, then there'll be a good reason for it, and the compiler
will issue a sensible message explaining that reason. I suggest you
read the message, and act on it.

Incidentally, the cast is pointless, so remove it. C ***GUARANTEES***
that you can assign a void * to an object pointer and back without loss
of information, and an automatic conversion is supplied.

If you're not getting that automatic conversion, you're not using a C
compiler.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 5 '07 #64
Richard Heathfield <rj*@see.sig.invalidwrites:
dm******@cox.net said:
> date = (long*)NULL;
free(date);
Incidentally, the cast is pointless, so remove it. C ***GUARANTEES***
that you can assign a void * to an object pointer and back without loss
of information, and an automatic conversion is supplied.

If you're not getting that automatic conversion, you're not using a C
compiler.
The usual reason that posters say this kind of thing in
comp.lang.c is because the conversion of interest is implicitly
allowed in C but not in C++. This case is a little difference:
this particular conversion is allowed in both C and C++. It
makes me wonder what language the OP is using, or alternatively
what C or C++ implementation diagnoses assigning NULL to an
object of type "long *".
--
"Structure padding is the use of extraneous materials to
enhance the shape of a struct and make it more attractive to
members of the opposite struct. (See also "struct silicone.")"
--Eric Sosman
Jul 5 '07 #65
It sounds like your boss needs to put the mouse down, and step away from
the keyboard. Programming by trial-and-error is never going to work.
Mind you, neither of us are programmers. We both took one introductory
class each and that was it. She's a civil engineer and I'm a
meteorologist and a mathematician.
>
Whilst it's legal to pass a null pointer to free(), it's also utterly
pointless.

If

free(date);
date = NULL;

doesn't compile, then there'll be a good reason for it, and the compiler
will issue a sensible message explaining that reason. I suggest you
read the message, and act on it.
We have asked many other more experienced C programmers and none of
them could figure out why we got the error message that we got nor did
they say that we shouldn't do it this way. This was the first issue
that I brought up when I looked at the code for the first time.

If you're not getting that automatic conversion, you're not using a C
compiler.
I don't think we are; we're using g++, which I am told is the only
thing we have. I tried to use cc, but it doesn't seem to be on the
system.

Jul 5 '07 #66
dm******@cox.net said:
>It sounds like your boss needs to put the mouse down, and step away
from the keyboard. Programming by trial-and-error is never going to
work.

Mind you, neither of us are programmers. We both took one introductory
class each and that was it. She's a civil engineer and I'm a
meteorologist and a mathematician.
>>
Whilst it's legal to pass a null pointer to free(), it's also utterly
pointless.

If

free(date);
date = NULL;

doesn't compile, then there'll be a good reason for it, and the
compiler will issue a sensible message explaining that reason. I
suggest you read the message, and act on it.

We have asked many other more experienced C programmers and none of
them could figure out why we got the error message that we got nor did
they say that we shouldn't do it this way. This was the first issue
that I brought up when I looked at the code for the first time.
Okay, here's what I suggest:

1) remove ALL casts from your program.
2) add all the error checking you can think of.
3) don't "code around" the compiler; code to the problem.
4) post your best-shot code here, with those casts GONE and those error
checks ADDED (I already did this for you once, and I don't plan to do
it again), together with enough information about the data to allow us
to construct sample data for ourselves (or just provide sample data, if
it's in text format).

You'd be astounded at how much C experience is available in comp.lang.c
- and you're not doing anything terribly difficult. This is taking way
longer than it should to fix, because you're not taking our suggestions
on board, so we keep finding the same old problems over and over. Until
those are dealt with, you're going to struggle to find the other
problems.
>If you're not getting that automatic conversion, you're not using a C
compiler.

I don't think we are; we're using g++, which I am told is the only
thing we have. I tried to use cc, but it doesn't seem to be on the
system.
gcc should be there.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 5 '07 #67
dm******@cox.net wrote:

If

free(date);
date = NULL;

doesn't compile, then there'll be a good reason for it, and the
compiler will issue a sensible message explaining that reason. I
suggest you read the message, and act on it.

We have asked many other more experienced C programmers and none of
them could figure out why we got the error message that we got nor did
they say that we shouldn't do it this way. This was the first issue
that I brought up when I looked at the code for the first time.
Well, for us to help we would need to see the entire program
(preferablly reduced to minimum program that still displays the
problem), along with an exact copy of the compiler messages.
>
If you're not getting that automatic conversion, you're not using a
C compiler.

I don't think we are; we're using g++, which I am told is the only
thing we have. I tried to use cc, but it doesn't seem to be on the
system.
What compiler ARE you using. Most C++ toolsets come with a C compiler
as well. It's probably there if you know how to invoke it.

If you really are using C++, you should post in comp.lang.c++.

Brian
Jul 5 '07 #68
Default User said:
dm******@cox.net wrote:
<snip>
we're using g++, <snip>
What compiler ARE you using.
I think they're using g++.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 5 '07 #69
"dm******@cox.net" <dm******@cox.netwrites:
We have asked many other more experienced C programmers and none of
them could figure out why we got the error message that we got nor did
they say that we shouldn't do it this way. This was the first issue
that I brought up when I looked at the code for the first time.
What was the actual error message? I don't recall seeing it
mentioned in this thread.
--
"It would be a much better example of undefined behavior
if the behavior were undefined."
--Michael Rubenstein
Jul 5 '07 #70
Richard Heathfield wrote:
Default User said:
dm******@cox.net wrote:

<snip>
we're using g++, <snip>
What compiler ARE you using.

I think they're using g++.
Then gcc is most likely available.


Brian
Jul 5 '07 #71
On 5 Jul, 15:16, "dmora...@cox.net" <dmora...@cox.netwrote:
Here is my code as of now, as well as an input file and my output. I
am aware that I've got more error proofing to do, but this is what I
have right now.
I'm just going to address one point:
fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");

if(fpin == NULL || fpout == NULL) {
printf("Insufficient arguments\n");
exit(exiterrorcode);
}
Others have pointed out that you need to verify that
argv[1] and argv[2] are not NULL before you call fopen,
and that's important but not the point I'm addressing.

If fopen() fails, you shouldn't make up your own error
message. The system provides you with a text string
describing why fopen failed. eg:

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

int
main( int argc, char **argv)
{
FILE *ifp;
char *name;
int status = EXIT_SUCCESS;

if( argc 1 )
ifp = fopen( name = argv[ 1 ], "r" );
else
ifp = stdin;

if( ifp == NULL ) {
fprintf( stderr, "Unable to open %s: %s\n",
name, strerror( errno ));
status = EXIT_FAILURE;
}
/* fclose() omitted for simplicity. */
return status;
}

Sample output:
$ ./a.out foo; ./a.out foo2; ./a.out /dev/hda
Unable to open foo: Permission denied
Unable to open foo2: No such file or directory
Unable to open /dev/hda: No medium found
You can also simplify things a little and replace the fprintf()
with the simpler call:
perror( name );

Note that an implementation is not required to set
errno when fopen fails, and on such implementations
the error message will be obfuscated, but this
works well for many implementations. If necessary,
you could code it as:

fprintf( stderr, "Unable to open %s%s%s\n",name,
#ifdef BRAIN_DAMAGED_IMPLEMENTATION
"last system error: "
#else
": "
#endif
, strerror( errno )
);

Jul 5 '07 #72
Richard Heathfield wrote:
Default User said:
dm******@cox.net wrote:

<snip>
we're using g++, <snip>
What compiler ARE you using.

I think they're using g++.

I guess my reading skills are off today. I blame in on taking vacation
(holiday for you) the first part of the week. Today's effectively
Monday for me, although one followed immediatedly by Friday (which
ain't all bad).


Brian
Jul 5 '07 #73
dm******@cox.net wrote:
>It sounds like your boss needs to put the mouse down, and step away from
the keyboard. Programming by trial-and-error is never going to work.

Mind you, neither of us are programmers. We both took one introductory
class each and that was it. She's a civil engineer and I'm a
meteorologist and a mathematician.
>Whilst it's legal to pass a null pointer to free(), it's also utterly
pointless.

If

free(date);
date = NULL;

doesn't compile, then there'll be a good reason for it, and the compiler
will issue a sensible message explaining that reason. I suggest you
read the message, and act on it.

We have asked many other more experienced C programmers and none of
them could figure out why we got the error message that we got nor did
they say that we shouldn't do it this way. This was the first issue
that I brought up when I looked at the code for the first time.

>If you're not getting that automatic conversion, you're not using a C
compiler.

I don't think we are; we're using g++, which I am told is the only
thing we have. I tried to use cc, but it doesn't seem to be on the
system.
If your project is of more than casual interest to you and your boss,
consider inviting a C programming consultant to spend an hour or two
with you. It won't break the bank.

If you have g++ (a C++ compiler) you might have gcc as well. Try 'gcc
--version' and see what happens. gcc is the C compiler of the GNU family.

Try 'info info' and see what happens. A whole new world might open to you.

--
Joe Wright
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---
Jul 5 '07 #74
William Pursell wrote:

Others have pointed out that you need to verify that
argv[1] and argv[2] are not NULL before you call fopen,
and that's important but not the point I'm addressing.

If fopen() fails, you shouldn't make up your own error
message. The system provides you with a text string
describing why fopen failed.
This is not required by the standard, and in fact some implementations
do not set errno in this case.


Brian
Jul 5 '07 #75
What was the actual error message? I don't recall seeing it
mentioned in this thread.
I'd have to look tomorrow when I get to the office.
Jul 5 '07 #76
David Moran wrote:
>
What was the actual error message? I don't recall seeing it
mentioned in this thread.

I'd have to look tomorrow when I get to the office.
Please don't strip the attribution lines, the part at the top of the
message that indicates who said what.


Brian
Jul 5 '07 #77
dm******@cox.net wrote, On 05/07/07 21:41:

<snip>
>free(date);
date = NULL;

doesn't compile, then there'll be a good reason for it, and the compiler
will issue a sensible message explaining that reason. I suggest you
read the message, and act on it.

We have asked many other more experienced C programmers and none of
them could figure out why we got the error message that we got nor did
they say that we shouldn't do it this way. This was the first issue
that I brought up when I looked at the code for the first time.
The most likely reason for this is you did not show them your real code.
>If you're not getting that automatic conversion, you're not using a C
compiler.

I don't think we are; we're using g++, which I am told is the only
thing we have.
g++ is a C++ compiler. Either use a C compiler or ask in a C++ group.
The languages are significantly different.
I tried to use cc, but it doesn't seem to be on the
system.
Try gcc. If that does not work, ask somewhere your OS is topical how to
get a C compiler installed.
--
Flash Gordon
Jul 5 '07 #78
"dm******@cox.net" wrote:
>
.... snip ...
>
>If you're not getting that automatic conversion, you're not using
a C compiler.

I don't think we are; we're using g++, which I am told is the only
thing we have. I tried to use cc, but it doesn't seem to be on the
system.
Try gcc. Use "-ansi -pedantic -W -Wall" with it. If you don't
have it it is available free.

Please don't strip attributions for material you quote.
Attributions are those initial lines of the form "whozit wrote:".

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jul 5 '07 #79
"dm******@cox.net" <dm******@cox.netwrites:
>If you're not getting that automatic conversion, you're not using a C
compiler.
The above was written by Richard Heathfield. Please leave attribution
lines in place; they make it substantially easier to follow the
conversation (and quoting someone else's words without attribution is
considered rude).

The line above:
"dm******@cox.net" <dm******@cox.netwrites:
is an attribution line. There should have been a similar one
crediting RH for what he wrote.
I don't think we are; we're using g++, which I am told is the only
thing we have. I tried to use cc, but it doesn't seem to be on the
system.
The following is slightly off-topic, since it deals with specific
implemntations rather than with the language.

"gcc" originally stood for "GNU C Compiler"; it was later changed to
"GNU Compiler Collection". The name "gcc" refers to a collection of
compilers for various languages. It's also the command name used to
invoke the C compiler portion of the gcc system (yes, it's a bit
confusing). "g++" is the command used to invoke the C++ compiler.

If you're compiling C code, use the "gcc" command, *not* the "g++"
command. (If you really want to program in C++, that's fine; use the
"g++" command, but ask about it in comp.lang.c++.)

Richard's advices is very good. Remove *all* the casts, use "gcc"
rather than "g++" to compile your sources, and try to correct any
problems *without* adding casts. There are cases where casts are
appropriate, but I don't think any of them occur in your program.

If you end up with something that you just can't get to compile, post
it here along with the *exact* copy-and-pasted error messages, and we
can help. If you end up with something that compiles but doesn't
work, post it here and tell us *exactly* how it doesn't work.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 5 '07 #80
"Default User" <de***********@yahoo.comwrites:
William Pursell wrote:
>Others have pointed out that you need to verify that
argv[1] and argv[2] are not NULL before you call fopen,
and that's important but not the point I'm addressing.

If fopen() fails, you shouldn't make up your own error
message. The system provides you with a text string
describing why fopen failed.

This is not required by the standard, and in fact some implementations
do not set errno in this case.
As William acknowledged later in the same article.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 5 '07 #81
Keith Thompson wrote:
"Default User" <de***********@yahoo.comwrites:
This is not required by the standard, and in fact some
implementations do not set errno in this case.

As William acknowledged later in the same article.

Bah, not my day.


Brian
Jul 5 '07 #82
William Pursell wrote:
>
.... snip ...
>
If fopen() fails, you shouldn't make up your own error
message. The system provides you with a text string
describing why fopen failed. eg:
I believe that should read "_may_ provide you with a text string
describing ..."

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jul 5 '07 #83
On Jul 5, 1:41 pm, "dmora...@cox.net" <dmora...@cox.netwrote:
>
If you're not getting that automatic conversion, you're not using a C
compiler.

I don't think we are; we're using g++, which I am told is the only
thing we have. I tried to use cc, but it doesn't seem to be on the
system.
If you've got g++ then you've also got gcc (unless you have a very
strange environment).

g++ is a C++ compiler suite, use it to build C++ programs.

gcc is a C compiler suite, use it to build C programs.

If you're trying to write C yet build it as if it were C++, you're
heading into a world of confusion and complication.

Jul 5 '07 #84
On 5 Jul, 22:40, "Default User" <defaultuse...@yahoo.comwrote:
William Pursell wrote:
Others have pointed out that you need to verify that
argv[1] and argv[2] are not NULL before you call fopen,
and that's important but not the point I'm addressing.
If fopen() fails, you shouldn't make up your own error
message. The system provides you with a text string
describing why fopen failed.

This is not required by the standard, and in fact some implementations
do not set errno in this case.
A point which I addressed later in my post.
I believe that properly describing the error encountered with
as much detail as possible is extremely important, and the
response that it is not 100% portable is often used as
an excuse to avoid even attempting to print reasonable
error messages. I won't even dare estimate how many hours
have been wasted in the history of computing simply because
of error messages that didn't provide adequate information.
POSIX guarantees that errno will be set
by fopen, and often that's portable enough.
IMO, an implementation that fails to provide
a reason for an fopen failure is brain dead. I acknowledge
the existence of such systems, and hope I never have
to deal with one.

Jul 6 '07 #85
On Jul 5, 4:50 pm, "David Moran" <dmora...@NOSPAMcox.netwrote:
What was the actual error message? I don't recall seeing it
mentioned in this thread.

I'd have to look tomorrow when I get to the office.

Here's the code; it now compiles, but seg faults when I run it. (Error
proofing will be done later)

int main(int argc, char *argv[])
{
/* Variable Declarations */
const int arraylength = 5;
const int errorcode = -1;
float sum = 0;
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
char date[12];
FILE *fpin;
FILE *fpout;

fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");

/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date, &precipvals[count]);
if(count == 0) {
precip3hrs[count] = precipvals[count];
}
if(count == 1) {
precip3hrs[count] = precipvals[count] + precip3hrs[count-1];
}
if(count 1) {
precip3hrs[count] = precipvals[count] + precipvals[count-1] +
precipvals[count-2];
}
if(condition != EOF) {
printf("Date: %s, One hour precipitation: %2.2f Three hour
precipitation: %2.2f\n",date,precipvals[count],precip3hrs[count]);
fprintf(fpout, "Date: %s, One hour precipitation: %2.2f Three
hour precipitation: %2.2f\n",date, precipvals[count],
precip3hrs[count]);
}
count++;
}

/* Write to file */
fclose(fpin);
fclose(fpout);

/* Deallocation */
free(precipvals);
free(precip3hrs);
free(date);

return 0;
}

Jul 6 '07 #86
On Fri, 06 Jul 2007 07:30:46 -0700, dm******@cox.net wrote:
On Jul 5, 4:50 pm, "David Moran" <dmora...@NOSPAMcox.netwrote:
What was the actual error message? I don't recall seeing it
mentioned in this thread.

I'd have to look tomorrow when I get to the office.


Here's the code; it now compiles, but seg faults when I run it. (Error
proofing will be done later)

int main(int argc, char *argv[])
{
/* Variable Declarations */
const int arraylength = 5;
const int errorcode = -1;
float sum = 0;
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
char date[12];
FILE *fpin;
FILE *fpout;

fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");
I have already told you several ways this could segfault, but you
didn't hear... Why should I waste more time?
>
/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date, &precipvals[count]);
I'll answer this one because it is *really* obvious. What did you
expect writing at the place pointed by a null pointer? (And that
same statement has other errors, too. Finding them is left as an
exercise.)
[snip]
return 0;
}
--
Army1987
(Replace "NOSPAM" with "email")

Jul 6 '07 #87
On Jul 6, 9:40 am, Army1987 <army1...@NOSPAM.itwrote:
On Fri, 06 Jul 2007 07:30:46 -0700, dmora...@cox.net wrote:
On Jul 5, 4:50 pm, "David Moran" <dmora...@NOSPAMcox.netwrote:
What was the actual error message? I don't recall seeing it
mentioned in this thread.
I'd have to look tomorrow when I get to the office.
Here's the code; it now compiles, but seg faults when I run it. (Error
proofing will be done later)
int main(int argc, char *argv[])
{
/* Variable Declarations */
const int arraylength = 5;
const int errorcode = -1;
float sum = 0;
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
char date[12];
FILE *fpin;
FILE *fpout;
fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");

I have already told you several ways this could segfault, but you
didn't hear... Why should I waste more time?
/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date, &precipvals[count]);

I'll answer this one because it is *really* obvious. What did you
expect writing at the place pointed by a null pointer? (And that
same statement has other errors, too. Finding them is left as an
exercise.)
[snip]
return 0;
}

--
Army1987
(Replace "NOSPAM" with "email")

Hey, I'm trying my best here.

Dave

Jul 6 '07 #88
dm******@cox.net said:

<snip>
Here's the code; it now compiles, but seg faults when I run it. (Error
proofing will be done later)
Let us know when it's ready. In the meantime, remove all the casts.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 6 '07 #89
On Jul 6, 9:57 am, Richard Heathfield <r...@see.sig.invalidwrote
Let us know when it's ready. In the meantime, remove all the casts.
I thought I did.

Dave

Jul 6 '07 #90
"dm******@cox.net" <dm******@cox.netwrites:
On Jul 5, 4:50 pm, "David Moran" <dmora...@NOSPAMcox.netwrote:
What was the actual error message? I don't recall seeing it
mentioned in this thread.

I'd have to look tomorrow when I get to the office.

Here's the code; it now compiles, but seg faults when I run it. (Error
proofing will be done later)

int main(int argc, char *argv[])
{
[snip]
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
Lose the casts.

What does your input file look like?

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 6 '07 #91
On Jul 6, 10:05 am, Keith Thompson <k...@mib.orgwrote:
What does your input file look like?
200701010000,3.58
200701010100,2.33
200701010200,4.55
200701010300,.29
200701010400,5.18
200701010500,0
200701010600,0
200701010700,0
200701010800,0
200701010900,.34

Jul 6 '07 #92
On Fri, 06 Jul 2007 07:49:00 -0700, dm******@cox.net wrote:
On Jul 6, 9:40 am, Army1987 <army1...@NOSPAM.itwrote:
>On Fri, 06 Jul 2007 07:30:46 -0700, dmora...@cox.net wrote:
On Jul 5, 4:50 pm, "David Moran" <dmora...@NOSPAMcox.netwrote:
What was the actual error message? I don't recall seeing it
mentioned in this thread.
>I'd have to look tomorrow when I get to the office.
Here's the code; it now compiles, but seg faults when I run it. (Error
proofing will be done later)
int main(int argc, char *argv[])
{
/* Variable Declarations */
const int arraylength = 5;
const int errorcode = -1;
float sum = 0;
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
char date[12];
FILE *fpin;
FILE *fpout;
fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");

I have already told you several ways this could segfault, but you
didn't hear... Why should I waste more time?
/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date, &precipvals[count]);

I'll answer this one because it is *really* obvious. What did you
expect writing at the place pointed by a null pointer? (And that
same statement has other errors, too. Finding them is left as an
exercise.)
[snip]
return 0;
}
[Signature snipped. Do not quote signatures unless you're
commenting about them.]
Hey, I'm trying my best here.
If so, why did you remove all the checks we suggested to you?
--
Army1987
(Replace "NOSPAM" with "email")

Jul 6 '07 #93
dm******@cox.net said:

<snip>
Look, I'm doing the best I can. Not only am I working on this, but
I've got other projects I'm working on
So have we all.
and I'm REALLY TRYING to learn.
Good. If you ask for advice, learn to take notice of the advice you are
given.
The insinuation that I'm not is insulting.
The evidence that you are not is overwhelming.

When I compile the code you posted (after fixing it for Usenet linewrap,
which we'll overlook), I get the following diagnostic messages:

foo.c: In function `main':
foo.c:9: `NULL' undeclared (first use in this function)
foo.c:9: (Each undeclared identifier is reported only once
foo.c:9: for each function it appears in.)
foo.c:12: `FILE' undeclared (first use in this function)
foo.c:12: `fpin' undeclared (first use in this function)
foo.c:12: warning: statement with no effect
foo.c:13: `fpout' undeclared (first use in this function)
foo.c:13: warning: statement with no effect
foo.c:15: warning: implicit declaration of function `fopen'
foo.c:19: `EOF' undeclared (first use in this function)
foo.c:20: warning: implicit declaration of function `fscanf'
foo.c:20: warning: long int format, different type arg (arg 3)
foo.c:32: warning: implicit declaration of function `printf'
foo.c:33: warning: implicit declaration of function `fprintf'
foo.c:40: warning: implicit declaration of function `fclose'
foo.c:44: warning: implicit declaration of function `free'
foo.c:6: warning: unused variable `sum'
foo.c:5: warning: unused variable `errorcode'
foo.c:4: warning: unused variable `arraylength'
foo.c:1: warning: unused parameter `argc'
make: *** [foo.o] Error 1

It's tricky to see how you can get a segfault from something that
doesn't compile.

So okay, I add the missing header, and now I only get:

foo.c: In function `main':
foo.c:22: warning: long int format, different type arg (arg 3)
foo.c:46: warning: implicit declaration of function `free'
foo.c:8: warning: unused variable `sum'
foo.c:7: warning: unused variable `errorcode'
foo.c:6: warning: unused variable `arraylength'
foo.c:3: warning: unused parameter `argc'

The first of these diagnostic messages refers to this line:

condition = fscanf(fpin,"%ld,%f", &date, &precipvals[count]);

Since date has type char[12], it's not going to match to %ld any time
soon. (There's your segfault right there.) Based on your subsequent
usage of date, I chose to change the format specifier rather than the
type.

The next message related to free() - indicating a missing header. But no
such warning occurs for malloc or calloc or realloc, which it would, if
you'd used them. So you're freeing memory you never allocated. (There's
your segfault right there.)

You don't use sum, errorcode, or arraylength, so I removed them.

You don't use argc, so you're not checking that your filenames exist
before you try to use them as filenames. (There's your segfault right
there.)

You don't check whether the files were opened successfully before you
try to read from and write to them. (There's your segfault right
there.)

You attempt to write through a null pointer several times during your
loop. (There's your segfault right there.)

So there you are - I've identified many of the places where your program
could be segfaulting. Many of these are places that have already been
identified to you as trouble spots, and it has already been recommended
to you that you fix them.

You can misread excellent advice as an insult if you like, but that's
your problem, not mine.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
Jul 6 '07 #94
On Jul 6, 10:31 am, Army1987 <army1...@NOSPAM.itwrote:
On Fri, 06 Jul 2007 07:49:00 -0700, dmora...@cox.net wrote:
On Jul 6, 9:40 am, Army1987 <army1...@NOSPAM.itwrote:
On Fri, 06 Jul 2007 07:30:46 -0700, dmora...@cox.net wrote:
On Jul 5, 4:50 pm, "David Moran" <dmora...@NOSPAMcox.netwrote:
What was the actual error message? I don't recall seeing it
mentioned in this thread.
I'd have to look tomorrow when I get to the office.
Here's the code; it now compiles, but seg faults when I run it. (Error
proofing will be done later)
int main(int argc, char *argv[])
{
/* Variable Declarations */
const int arraylength = 5;
const int errorcode = -1;
float sum = 0;
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
char date[12];
FILE *fpin;
FILE *fpout;
fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");
I have already told you several ways this could segfault, but you
didn't hear... Why should I waste more time?
/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date, &precipvals[count]);
I'll answer this one because it is *really* obvious. What did you
expect writing at the place pointed by a null pointer? (And that
same statement has other errors, too. Finding them is left as an
exercise.)
[snip]
return 0;
}

[Signature snipped. Do not quote signatures unless you're
commenting about them.]
Hey, I'm trying my best here.

If so, why did you remove all the checks we suggested to you?
--
Army1987
(Replace "NOSPAM" with "email")

Ok I found the version with the checks. I thought it'd be easier to
deal with getting it to run and then going back to put in the checks.

Jul 6 '07 #95
You can misread excellent advice as an insult if you like, but that's
your problem, not mine.
All, I apologize for my behavior...I'm just really frustrated. I
appreciate the help.

Jul 6 '07 #96
On Jul 6, 10:46 am, "dmora...@cox.net" <dmora...@cox.netwrote:
On Jul 6, 10:31 am, Army1987 <army1...@NOSPAM.itwrote:
>
Ok I found the version with the checks. I thought it'd be easier to
deal with getting it to run and then going back to put in the checks.
Sorry for not snipping.

Dave

Jul 6 '07 #97
William Pursell wrote:
On 5 Jul, 22:40, "Default User" <defaultuse...@yahoo.comwrote:
This is not required by the standard, and in fact some
implementations do not set errno in this case.

A point which I addressed later in my post.
Yeah, yeah. I didn't read the whole thing. The caveat would have been
better up front, but you did mention it.


Brian
Jul 6 '07 #98
"dm******@cox.net" wrote:
>
.... snip ...
>
Here's the code; it now compiles, but seg faults when I run it.
(Error proofing will be done later)

int main(int argc, char *argv[])
{
/* Variable Declarations */
const int arraylength = 5;
const int errorcode = -1;
float sum = 0;
int count = 0;
int condition = 1;
float* precipvals = (float*)NULL;
float* precip3hrs = (float*)NULL;
get rid of the casts. Useless, and just hide errors. NULL is
undefined.
char date[12];
FILE *fpin;
FILE *fpout;
Without #including stdin, these can't work.
>
fpin = fopen(argv[1],"r");
fpout = fopen(argv[2],"w");
Failed to check for success and exit on failure. Bad.
>
/* Calculation Section */
while(condition != EOF) {
condition = fscanf(fpin,"%ld,%f", &date, &precipvals[count]);
Thus ignoring errors. fscanf failed if it didn't return 2.
if(count == 0) {
precip3hrs[count] = precipvals[count];
}
if(count == 1) {
precip3hrs[count] = precipvals[count] + precip3hrs[count-1];
}
if(count 1) {
precip3hrs[count] = precipvals[count] + precipvals[count-1] +
precipvals[count-2];
}
if(condition != EOF) {
printf("Date: %s, One hour precipitation: %2.2f Three hour
precipitation: %2.2f\n",date,precipvals[count],precip3hrs[count]);
You can break up overly long strings. For example:
printf("Date: %s, One hour precipitation: %2.2f"
" Three hour precipitation: .2f\n",
date, precipvals[count], precip3hrs[count]);

Note the lack of commas, etc. between the broken-up strings.
fprintf(fpout, "Date: %s, One hour precipitation: %2.2f Three
hour precipitation: %2.2f\n",date, precipvals[count],
precip3hrs[count]);
}
count++;
}

/* Write to file */
fclose(fpin);
fclose(fpout);

/* Deallocation */
free(precipvals);
free(precip3hrs);
free(date);

return 0;
}
Only post COMPLETE compilable extracts. The reader should be able
to cut, paste into an editor, save, and compile.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jul 6 '07 #99
"dm******@cox.net" wrote:
>
.... snip ...
>
Look, I'm doing the best I can. Not only am I working on this, but
I've got other projects I'm working on and I'm REALLY TRYING to
learn. The insinuation that I'm not is insulting.
Live with it. Also learn to snip irrelevant quoted material.

--
<http://www.cs.auckland.ac.nz/~pgut001/pubs/vista_cost.txt>
<http://www.securityfocus.com/columnists/423>
<http://www.aaxnet.com/editor/edit043.html>
cbfalconer at maineline dot net

--
Posted via a free Usenet account from http://www.teranews.com

Jul 6 '07 #100

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

reply views Thread by Christophe HELFER | last post: by
6 posts views Thread by Christophe Helfer | last post: by
3 posts views Thread by Jan Danielsson | last post: by
1 post views Thread by Gaijinco | last post: by
3 posts views Thread by Sudesh | last post: by
8 posts views Thread by Morpheus | last post: by
13 posts views Thread by =?Utf-8?B?Um9iS2lubmV5MQ==?= | last post: by
omerbutt
8 posts views Thread by omerbutt | last post: by
1 post views Thread by CARIGAR | last post: by
reply views Thread by zhoujie | last post: by
reply views Thread by suresh191 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.