468,170 Members | 2,006 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

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

read and write columns

I don't think I can do this without some help or hints. Here is the code
I have.

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

double input(double input) {
int count=0,div=0;
double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;
if ((fpw=fopen("data","w"))!=EOF);
if ((fpr=fopen("data","r"))!=EOF);
if ((fscanf(fpr,input,linput,mean))==0;
fprintf(fpw,"%d\t%d\t%d\n",input,input+linput,mean );
}

It's very much incomplete. I have two stream open one for reading and one
for writing but the count that I have been speaking of, I don't know how to
increment it.

Bill
Jul 3 '08 #1
63 2739
Bill Cunningham said:
I don't think I can do this without some help or hints. Here is the
code
I have.

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

double input(double input) {
int count=0,div=0;
div is a standard C library function prototyped in <stdlib.h>, so this
definition of div "shadows" that function, preventing you from using it.
It is best to avoid using standard C library function names except when
referring to standard C library functions.
double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;
if ((fpw=fopen("data","w"))!=EOF);
You have K&R2. Look up fopen's return value on failure. You've been told
about this before, and quite recently too.

--
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
Jul 3 '08 #2
On Thu, 03 Jul 2008 00:12:03 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:
I don't think I can do this without some help or hints. Here is the code
I have.

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

double input(double input) {
int count=0,div=0;
White space is free. Use it make your code readable.
double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;
What is the value of count? Are you allowed to divide by that value?
if ((fpw=fopen("data","w"))!=EOF);
Didn't your compiler generate a diagnostic here? What type and range
of EOF? What type of value does fopen return to be stored in fpw? Are
the two in any way compatible.
if ((fpr=fopen("data","r"))!=EOF);
if ((fscanf(fpr,input,linput,mean))==0;
You couldn't figure out that you are missing a right parenthesis here?
What do you expect that superfluous semicolon to do?

What are the arguments to fscanf supposed to be? Other than fpr, do
any of yours meet the criteria?

Admit it, you didn't even try to compile the code.
fprintf(fpw,"%d\t%d\t%d\n",input,input+linput,mean );
}
What type of argument does %d promise? What are the types of your
arguments.
>
It's very much incomplete. I have two stream open one for reading and one
for writing but the count that I have been speaking of, I don't know how to
increment it.
If you don't know how to increment count, you need to start with
programs that are very much more basic than this. Strange that you
didn't have any trouble incrementing input above. OK, so you did have
trouble but at least you knew (lucky guess?) which operator to use.


Remove del for email
** Posted from http://www.teranews.com **
Jul 3 '08 #3
On Jul 3, 5:12 am, "Bill Cunningham" <nos...@nspam.comwrote:
I don't think I can do this without some help or hints. Here is the code
I have.

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

double input(double input) {
int count=0,div=0;
double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;
What exactly do you mean? input + (linput / count) or (input +
linput) / count. Do you see a divide by zero problem here? Since input
and linput are define as double, your mean equals infinity.
if ((fpw=fopen("data","w"))!=EOF);
if ((fpr=fopen("data","r"))!=EOF);
May be next time you should remember fopen returns FILE * and the
error checking is done against NULL.
So if ((fpw = fopen("data", "w")) != NULL);
But heck; even now it is meaning-less(that ;, if you didn't notice).
Check for NULL and then do nothing - just proceed with the code.
if ((fscanf(fpr,input,linput,mean))==0;
Again, check for error and do nothing. And this won't compile on any
known compiler(missing parenthesis).
fprintf(fpw,"%d\t%d\t%d\n",input,input+linput,mean );
}
input, input + linput are doubles. mean is a double and equals
infinity. %d, if you have a look at the doc, is meant for signed
integers.
It's very much incomplete. I have two stream open one for reading and one
for writing but the count that I have been speaking of, I don't know how to
increment it.
I don't know but it looks like to me that you created this mess on
purpose. There are better ways to have fun if that is what you are
trying to have over here.
Jul 3 '08 #4
Barry Schwarz said:
On Thu, 03 Jul 2008 00:12:03 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:
> I don't think I can do this without some help or hints. Here is the
code
I have.

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

double input(double input) {
int count=0,div=0;

White space is free. Use it make your code readable.
> double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;

What is the value of count? Are you allowed to divide by that value?
Good spot, Barry. I missed that completely.
> if ((fpw=fopen("data","w"))!=EOF);

Didn't your compiler generate a diagnostic here?
Just a thought here - Bill Cunningham is a self-confessed slow learner, so
it might be quicker for us and more productive for him if we just point
out the *first* mistake. Maybe over time BC will begin to understand that
he's not going to get help with problem B for so long as his code
continues to exhibit problem A, and he might - just *might* - work out
that eliminating problem A from all his code is therefore a productive
thing for him to do.

--
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
Jul 3 '08 #5
On Jul 3, 5:12 am, "Bill Cunningham" <nos...@nspam.comwrote:
I don't think I can do this without some help or hints. Here is the code
I have.

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

double input(double input) {
Though it is legal, naming the parameter the same as your function
name is not a good practice.
Jul 3 '08 #6
On Thu, 03 Jul 2008 04:57:37 +0000, Richard Heathfield posted:
Barry Schwarz said:
>On Thu, 03 Jul 2008 00:12:03 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:
>> I don't think I can do this without some help or hints. Here is the
code
I have.

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

double input(double input) {
int count=0,div=0;

White space is free. Use it make your code readable.
>> double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;

What is the value of count? Are you allowed to divide by that value?

Good spot, Barry. I missed that completely.
>> if ((fpw=fopen("data","w"))!=EOF);

Didn't your compiler generate a diagnostic here?

Just a thought here - Bill Cunningham is a self-confessed slow learner, so
it might be quicker for us and more productive for him if we just point
out the *first* mistake. Maybe over time BC will begin to understand that
he's not going to get help with problem B for so long as his code
continues to exhibit problem A, and he might - just *might* - work out
that eliminating problem A from all his code is therefore a productive
thing for him to do.

I think this idiom is largely unnecessary:
>> if ((fpw=fopen("data","w"))!=EOF);
If every char you put has to be tested for EOF, then you have a deficient
OS. I gave windows 40 gigs today. It prompts me annoyingly for lack of
hog space.

That the C programming language must be constarined to the average clicker
is a distortion.
--
Ron Ford
Jul 3 '08 #7
Ron Ford said:

<snip>
>

I think this idiom is largely unnecessary:
>>> if ((fpw=fopen("data","w"))!=EOF);
It isn't an idiom. It's just a bug.

--
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
Jul 3 '08 #8
On Thu, 03 Jul 2008 09:27:48 +0000, Richard Heathfield posted:
Ron Ford said:

<snip>
>>

I think this idiom is largely unnecessary:
>>>> if ((fpw=fopen("data","w"))!=EOF);

It isn't an idiom. It's just a bug.
When I have to do IO with C, I use safegets, but I don't think that that is
what you mean.

My point was that my OS doesn't say nay to me on a char basis.

I'm curious what you mean.
--
Ron Ford
"Close enough to Texas to feel disinformation."
Jul 3 '08 #9
Ron Ford said:
On Thu, 03 Jul 2008 09:27:48 +0000, Richard Heathfield posted:
>Ron Ford said:

<snip>
>>>

I think this idiom is largely unnecessary:

> if ((fpw=fopen("data","w"))!=EOF);

It isn't an idiom. It's just a bug.

When I have to do IO with C, I use safegets, but I don't think that that
is what you mean.

My point was that my OS doesn't say nay to me on a char basis.

I'm curious what you mean.
The fopen function never returns EOF, ever. Since EOF is an int, and since
fopen returns a FILE *, testing the return value of fopen against EOF is
completely pointless. (In this case, the semicolon makes it doubly
pointless.)

--
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
Jul 3 '08 #10
On Thu, 03 Jul 2008 10:11:47 +0000, Richard Heathfield posted:
Ron Ford said:
>On Thu, 03 Jul 2008 09:27:48 +0000, Richard Heathfield posted:
>>Ron Ford said:

<snip>
I think this idiom is largely unnecessary:

>> if ((fpw=fopen("data","w"))!=EOF);

It isn't an idiom. It's just a bug.

When I have to do IO with C, I use safegets, but I don't think that that
is what you mean.

My point was that my OS doesn't say nay to me on a char basis.

I'm curious what you mean.

The fopen function never returns EOF, ever. Since EOF is an int, and since
fopen returns a FILE *, testing the return value of fopen against EOF is
completely pointless. (In this case, the semicolon makes it doubly
pointless.)
I see. What I was getting at was more like:
putchar(anything)!=EOF ....

The test against anything for a putchar call seems prudent but ends up
being a lot of extra keystrokes and code.

EOF has alwyas been negative one on my impkementation.
--
Jul 3 '08 #11
In article <u8*****************************@40tude.net>,
Ron Ford <ro*@nowhere.netwrote:
>I see. What I was getting at was more like:
putchar(anything)!=EOF ....

The test against anything for a putchar call seems prudent but ends up
being a lot of extra keystrokes and code.
Depending on the application, it may be reasonable just to use
ferror() to test the stream at the end of the output, or at other
natural times such as before reading input. But be sure to also check
the return value of fclose(): buffering both within the stdio library
and in the operating system may mean that errors are not detected
until the file is closed.
>EOF has alwyas been negative one on my impkementation.
EOF must be a negative int.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Jul 3 '08 #12
Ron Ford <ro*@nowhere.netwrote:
I see. What I was getting at was more like:
putchar(anything)!=EOF ....
You may have tried to get at that, but since it wasn't in the OP's
posted code, it would be hard to reach it.
The test against anything for a putchar call seems prudent but ends up
being a lot of extra keystrokes and code.
A lot? Rather an exaggeration, isn't it? If you do it right, that check
for EOF will double as your loop termination condition, which you would
have needed anyway.
EOF has alwyas been negative one on my impkementation.
That's as may be, and it is indeed by far the most common value, but all
the Standard demands is that EOF is negative. Besides, EOF is both
clearer, and only a single character longer, than -1.

Richard
Jul 3 '08 #13
On 3 Jul, 01:12, "Bill Cunningham" <nos...@nspam.comwrote:
* * I don't think I can do this without some help or hints. Here is the code
I have.

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

double input(double input) {
* * * *int count=0,div=0;
* * * *double mean=0,linput=0;
* * * *FILE *fpr, *fpw;
* * * *mean=input+linput/count;
* * * *if ((fpw=fopen("data","w"))!=EOF);
* * * *if ((fpr=fopen("data","r"))!=EOF);
* * * *if ((fscanf(fpr,input,linput,mean))==0;
* * * *fprintf(fpw,"%d\t%d\t%d\n",input,input+linput,mea n);
* * * *}

It's very much incomplete. I have two stream open one for reading and one
for writing but the count that I have been speaking of, I don't know how to
increment it.
WHAT ARE YOU TRYING TO DO

--
Nick Keighley
Jul 3 '08 #14
"Bill Cunningham" <no****@nspam.comwrites:
I don't think I can do this without some help or hints. Here is the code
I have.

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

double input(double input) {
int count=0,div=0;
double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;
if ((fpw=fopen("data","w"))!=EOF);
if ((fpr=fopen("data","r"))!=EOF);
if ((fscanf(fpr,input,linput,mean))==0;
fprintf(fpw,"%d\t%d\t%d\n",input,input+linput,mean );
}

It's very much incomplete. I have two stream open one for reading and one
for writing but the count that I have been speaking of, I don't know how to
increment it.
Look up the word "increment" in your C textbook.

I thought you were going to run your code through "indent" before
posting it.

You have no "main" function.

The code you posted doesn't compile. Did you even try compiling it
before posting?

You attempt to open the same file, "data", for writing and reading,
using two separate streams. This makes no sense.

You have 3 if statements. You don't do anything in any of them. Just
how do you think an if statement works?

Why are you comparing the result of fopen() to EOF? Read the
documentation for fopen(). Don't guess.

You're calling fscanf() with four arguments: a FILE* (good) and three
doubles. Read the documentation for fscanf. For the umpteenth time,
don't guess.

You haven't said what the code is supposed to do. For the umpteenth
time, state the problem you're trying to solve. If you haven't done
that, writing even a single line of code is a waste of time.

This appears to be similar in intent to something that was discussed
at length in another thread, but I'm not going to assume that there's
any correlation; you never offered a decent problem definition in that
thread either.

In the absence of any problem definition, here's a correct program
that meets all the requirements you've stated:

int main(void)
{
}

If you can tell us what functionality is missing from that program,
*maybe* we can start to help you.

But I doubt it.

I honestly think you need to go back a few steps. Pick a simpler
problem to solve. Define the problem clearly in plain English. Then,
and only then, try to write a program to solve the problem. Never
write a call to a library function without first understanding what
arguments the function expects, what result it returns, and what each
and every argument and result means. This requires reading the
documentation.

Get a copy of K&R2 if you don't already have one. Start at the
beginning and work your way through it. Do all the exercises.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 3 '08 #15
Bill Cunningham wrote:
I don't think I can do this without some help or hints. Here is the
code
I have.

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

double input(double input) {
int count=0,div=0;
double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;
if ((fpw=fopen("data","w"))!=EOF);
if ((fpr=fopen("data","r"))!=EOF);
if ((fscanf(fpr,input,linput,mean))==0;
fprintf(fpw,"%d\t%d\t%d\n",input,input+linput,mean );
}

It's very much incomplete. I have two stream open one for reading and one
for writing but the count that I have been speaking of, I don't know how
to increment it.
Bill,

For this task you need to use a union. Find below a small program that
demonstrates the following:

(1) how to use structs, unions, and enums.

(2) how to open a text file for input.

(3) how to read text representations of floating point numbers from a
text file.

(4) how to open a text file for output.

(5) how to calculate sum and mean from the numbers acquired in step (3).

(6) how to write text representations of floating point numbers calculated
in step (5) to a text file.
with the this input (data.txt),

10.50
10.25
10.00
10.75
11.00

the following output (out.txt) is produced

10.50 10.50 10.50
10.25 20.75 10.38
10.00 30.75 10.25
10.75 41.50 10.38
11.00 52.50 10.50

Enjoy.

/* begin coltxt.c (released to public domain) */
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <errno.h>

static const char *datafile = "data.txt";
static const char *outfile = "out.txt";

struct foo {
float number;
float sum;
float mean;
};

union bar {
FILE *fi;
FILE *fo;
};

enum baz {
P_OK = 0,
P_EOF = -1,
P_OPEN = -2,
P_READ = -3,
P_WRITE = -4,
P_TOOLONG = -5,
P_TOOSHORT = -6,
P_BADNUMBER = -7,
P_RANGE = -8,
P_NOMEM = -9,
P_LASTERR = -10
};

char *my_strerr(int);
int fgetf(float *, FILE *);
#define getf(x) fgetf((x), stdin)

int main(void)
{
struct foo *foo;
union bar bar;
int ch, chp;
size_t i, j, nlines;

if((bar.fi = fopen(datafile, "r")) == NULL) {
fprintf(stderr, "%s: %s.\n", my_strerr(P_OPEN), datafile);
return EXIT_FAILURE;
}

nlines = 0; chp = '\n';
for(;;) {
ch = fgetc(bar.fi);
if(ch == '\n' || (ch == EOF && chp != '\n'))
nlines++;
if((chp = ch) == EOF)
break;
}

if(nlines == 0) {
fprintf(stderr, "File %s contains 0 lines.\n", datafile);
fclose(bar.fi);
return EXIT_FAILURE;
}

if((foo = malloc(sizeof * foo * nlines)) == NULL) {
fprintf(stderr, "%s.\n", my_strerr(P_NOMEM));
fclose(bar.fi);
return EXIT_FAILURE;
}

fprintf(stdout,
"Reading %lu lines from %s, please wait...\n",
(unsigned long)nlines, datafile);

rewind(bar.fi);

for(i = j = 0; i < nlines; i++) {
float f; int res;
struct foo *p;
if((res = fgetf(&f, bar.fi)) != 0) {
if(res == P_EOF)
break;
else if(res == P_TOOSHORT) /* ignore emty lines */
continue;
fprintf(stderr,
"Problem reading line %lu from %s: %s.\n",
(unsigned long)i, datafile, my_strerr(res));
free(foo);
fclose(bar.fi);
return EXIT_FAILURE;
}
p = foo + j++;
p->number = f;
p->sum = p->mean = 0.f;
}
if(j < nlines) {
struct foo * tmp = realloc(foo, sizeof * tmp * j);
if(tmp)
foo = tmp;
nlines = j;
}
fclose(bar.fi);

if((bar.fo = fopen(outfile, "w")) == NULL) {
fprintf(stderr, "%s: %s.\n", my_strerr(P_OPEN), datafile);
free(foo);
return EXIT_FAILURE;
}

fprintf(stdout,
"Writing %lu lines to %s, please wait...\n",
(unsigned long)nlines, outfile);

for(i = 0; i < nlines; i++) {
for(j = 0; j <= i; j++)
foo[i].sum += foo[j].number;
foo[i].mean = foo[i].sum / (i+1);
if(fprintf(bar.fo, "%.2f %.2f %.2f\n",
foo[i].number, foo[i].sum, foo[i].mean) < 0) {
fprintf(stderr, "%s: %s\n", my_strerr(P_WRITE), outfile);
free(foo);
fclose(bar.fo);
return EXIT_FAILURE;
}
}
fprintf(stdout, "All done!\n");

free(foo);
fclose(bar.fo);

return EXIT_SUCCESS;
}

/*
* getf(): read and interpret single line from f as float
*/
int fgetf(float *res, FILE *f)
{
char buf[2048], *p, *q;
size_t len;
float result;

if(fgets(buf, sizeof buf, f) != buf) {
if(feof(f)) return P_EOF;
else return P_READ;
}
p = buf; len = strlen(p);
if(len && *(p + len - 1) != '\n') {
int ch = fgetc(f);
if(ch != EOF) {
while(ch != '\n' && ch != EOF)
ch = fgetc(f);
return P_TOOLONG;
}
}
else
*(p + --len) = '\0';
if(len == 0)
return P_TOOSHORT;

p = buf + len - 1;
while(*p == ' ' || *p == '\t') {
*p-- = '\0'; len--;
}
p = buf;
while(*p == ' ' || *p == '\t') {
p++; len--;
}
if(len == 0)
return P_TOOSHORT;

errno = 0;
result = strtod(p, &q);
if(*q != '\0')
return P_BADNUMBER;
if(errno == ERANGE)
return P_RANGE;

if(res)
*res = result;
return 0;
}

char *my_strerr(int errnum)
{
static char *rr[] = {
"No error",
"EOF",
"Error opening file",
"Read error",
"Write error",
"Line too long",
"Line too short",
"Not a valid number",
"Number out of range",
"Out of memory",
"Unknown error",
};
if(errnum < P_LASTERR || errnum 0) errnum = P_LASTERR;
return rr[-errnum];
}
/* end coltxt.c */

--
John J. Smith

Jul 3 '08 #16
John J. Smith <jj*@localhost.invalidwrites:
Bill Cunningham wrote:
> I don't think I can do this without some help or hints. Here is the
code
I have.

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

double input(double input) {
int count=0,div=0;
double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;
if ((fpw=fopen("data","w"))!=EOF);
if ((fpr=fopen("data","r"))!=EOF);
if ((fscanf(fpr,input,linput,mean))==0;
fprintf(fpw,"%d\t%d\t%d\n",input,input+linput,mean );
}

It's very much incomplete. I have two stream open one for reading and one
for writing but the count that I have been speaking of, I don't know how
to increment it.

Bill,

For this task you need to use a union.
[snip]

Nonsense.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 3 '08 #17

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
I honestly think you need to go back a few steps. Pick a simpler
problem to solve. Define the problem clearly in plain English. Then,
and only then, try to write a program to solve the problem. Never
write a call to a library function without first understanding what
arguments the function expects, what result it returns, and what each
and every argument and result means. This requires reading the
documentation.

Get a copy of K&R2 if you don't already have one. Start at the
beginning and work your way through it. Do all the exercises.
I have kandr2 but I use a little pocket reference here at the desk. It
says you can use "t" for text with fopen. That's not the standard I guess.

Now I think I've caught onto a little more but with fopen's mode. "w"
will create a file but would "w+" or "r+" ? I will try two stream one to
create a text file the other to read and write from. I still don't get the
increment part. If someone would just show me that part and not a long
program with structs and the like then I think I can catch on quicker. I
would understand one more thing.

Bill
Jul 3 '08 #18
"Bill Cunningham" <no****@nspam.comwrites:
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>I honestly think you need to go back a few steps. Pick a simpler
problem to solve. Define the problem clearly in plain English. Then,
and only then, try to write a program to solve the problem. Never
write a call to a library function without first understanding what
arguments the function expects, what result it returns, and what each
and every argument and result means. This requires reading the
documentation.

Get a copy of K&R2 if you don't already have one. Start at the
beginning and work your way through it. Do all the exercises.

I have kandr2 but I use a little pocket reference here at the desk. It
says you can use "t" for text with fopen. That's not the standard I guess.
Your pocket reference is lying to you. Stop using it. Consider
throwing it away.

(That's a little harsh; it's probably referring to some particular
implementation that happens to accept "t", which is a valid extension.
But if it doesn't tell you that "t" is non-portable, it's leading you
astray.)

K&R2 is an excellent book on C. It's more of a tutorial than a
reference manual, though there is a reference section at the end.

I've advised you to start at the beginning of K&R2 and work through
it. You can ignore my advice if you like, but then I can't help you.
Now I think I've caught onto a little more but with fopen's mode. "w"
will create a file but would "w+" or "r+" ?
Why are you asking us?

Look. It. Up.
I will try two stream one to
create a text file the other to read and write from.
You want two streams: one to read from the existing file, and the
other to create and write to the new file. There's no reason to read
and write to the same stream.

This is based on some reasonable assumptions about what you're trying
to do, since you have refused to tell us. You need to define the
****ing problem before you worry about fopen modes and incrementing
counters.
I still don't get the
increment part. If someone would just show me that part and not a long
program with structs and the like then I think I can catch on quicker. I
would understand one more thing.
count++;

Hope that helps.

--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Jul 3 '08 #19
On Jul 4, 12:51 am, "Bill Cunningham" <nos...@nspam.comwrote:
"Keith Thompson" <ks...@mib.orgwrote in message
Get a copy of K&R2 if you don't already have one. Start at the
beginning and work your way through it. Do all the exercises.

I have kandr2 but I use a little pocket reference here at the desk. It
says you can use "t" for text with fopen. That's not the standard I guess.
read this post: <wSE5k.40580$lE3.20244@trnddc05>
Here, let me help you get this right: 't' is non-standard. I hope from
now on you won't have to *guess*, you will *know* it is not standard.
Jul 3 '08 #20

"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
I've advised you to start at the beginning of K&R2 and work through
it. You can ignore my advice if you like, but then I can't help you.
Ok I guess that's simple begin at chapter one. Maybe do a chapter a day.

Thanks Keith for all your help. If I get confused or something I'll come to
the group.

Bill
Jul 4 '08 #21
John J. Smith wrote:
Bill Cunningham wrote:
> I don't think I can do this without some help or hints. Here is the
code
I have.

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

double input(double input) {
int count=0,div=0;
double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;
if ((fpw=fopen("data","w"))!=EOF);
if ((fpr=fopen("data","r"))!=EOF);
if ((fscanf(fpr,input,linput,mean))==0;
fprintf(fpw,"%d\t%d\t%d\n",input,input+linput,mean );
}

It's very much incomplete. I have two stream open one for reading and one
for writing but the count that I have been speaking of, I don't know how
to increment it.
For this task you need to use a union.
I like the demo,
but nobody hardly ever needs a union for anything.

You need a union to force alignment of an object
on a boundary of another type, which isn't very often.

You need a union to save space in certain specific dire circumstances;
uncommonly dire circumstances.

And that's all.
Anything else that you can do with a union,
can also be done another way without one.

union bar {
FILE *fi;
FILE *fo;
};
That would have been funnier this way:

union bar {
FILE *fi;
FILE *fo;
FILE *fum;
};

--
pete
Jul 4 '08 #22
pete wrote:
John J. Smith wrote:
<snip>
>union bar {
FILE *fi;
FILE *fo;
};

That would have been funnier this way:

union bar {
FILE *fi;
FILE *fo;
FILE *fum;
};
It would be even funnier this way:

union bar {
FILE *fee;
FILE *fi;
FILE *fo;
FILE *fum;
};

Jul 4 '08 #23
On Fri, 04 Jul 2008 01:28:55 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:
>
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>I've advised you to start at the beginning of K&R2 and work through
it. You can ignore my advice if you like, but then I can't help you.

Ok I guess that's simple begin at chapter one. Maybe do a chapter a day.
No, don't do a chapter a day! Stay on a chapter until you understand
everything in it and you have done all the exercises. It would
probably be good to not do more than one exercise a day. And don't
start the next exercise until you have finished the current one.
Remove del for email
Jul 4 '08 #24
Barry Schwarz said:
On Fri, 04 Jul 2008 01:28:55 GMT, "Bill Cunningham" <no****@nspam.com>
wrote:
>>
"Keith Thompson" <ks***@mib.orgwrote in message
news:ln************@nuthaus.mib.org...
>>I've advised you to start at the beginning of K&R2 and work through
it. You can ignore my advice if you like, but then I can't help you.

Ok I guess that's simple begin at chapter one. Maybe do a chapter a
day.

No, don't do a chapter a day!
Even a sentence a day can be quite a challenge. K&R2's information density
is simply colossal.
Stay on a chapter until you understand
everything in it and you have done all the exercises. It would
probably be good to not do more than one exercise a day. And don't
start the next exercise until you have finished the current one.
Finished it, understood it, and able to rewrite it without looking anything
up or asking anyone about it. It's okay to look stuff up, and it's okay to
ask, but if you keep doing the exercise from scratch until you can do it
blindfolded, you'll *know* that you've absorbed the lessons it was
supposed to teach.

--
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
Jul 4 '08 #25
pete wrote:
John J. Smith wrote:
>Bill Cunningham wrote:
>> I don't think I can do this without some help or hints. Here is the
code
I have.

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

double input(double input) {
int count=0,div=0;
double mean=0,linput=0;
FILE *fpr, *fpw;
mean=input+linput/count;
if ((fpw=fopen("data","w"))!=EOF);
if ((fpr=fopen("data","r"))!=EOF);
if ((fscanf(fpr,input,linput,mean))==0;
fprintf(fpw,"%d\t%d\t%d\n",input,input+linput,mean );
}

It's very much incomplete. I have two stream open one for reading and
one
for writing but the count that I have been speaking of, I don't know how
to increment it.
>For this task you need to use a union.

I like the demo,
.... but I have some problems with it.

static const char *datafile = "data.txt";
static const char *outfile = "out.txt";

I wouldn't use global variables without a special reason.

float f; int res;
I wouldn't use float instead of double without a special reason.

int main(void)
{
size_t i, j, nlines;

if((bar.fi = fopen(datafile, "r")) == NULL) {

If you're really going to mock me right,
then the demo program program also has to create the input file.

--
pete
Jul 4 '08 #26

"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:6u******************************@bt.com...
Even a sentence a day can be quite a challenge. K&R2's information density
is simply colossal.
What about your book Richard? "C Unleashed" I have a copy of it too. In
your opinion would it be better for me personally to learn from your book
first anyway? It's much larger but might be more digestable.

Bill
Jul 4 '08 #27
Bill Cunningham said:
>
"Richard Heathfield" <rj*@see.sig.invalidwrote in message
news:6u******************************@bt.com...
>Even a sentence a day can be quite a challenge. K&R2's information
density is simply colossal.

What about your book Richard? "C Unleashed" I have a copy of it too.
In
your opinion would it be better for me personally to learn from your book
first anyway? It's much larger but might be more digestable.
K&R2 is a tutorial. That is, it is designed to teach C to people who don't
know it.

"C Unleashed" assumes you already know C. Just as it may be possible to
build a 25-storey building out of nothing but balsa wood, so it may be
possible to learn C from "C Unleashed". That does not imply that the
attempt should be made.

--
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
Jul 4 '08 #28
On Thu, 03 Jul 2008 12:02:58 GMT, Richard Bos posted:
Ron Ford <ro*@nowhere.netwrote:
>I see. What I was getting at was more like:
putchar(anything)!=EOF ....

You may have tried to get at that, but since it wasn't in the OP's
posted code, it would be hard to reach it.
>The test against anything for a putchar call seems prudent but ends up
being a lot of extra keystrokes and code.

A lot? Rather an exaggeration, isn't it? If you do it right, that check
for EOF will double as your loop termination condition, which you would
have needed anyway.

Out of n tests against EOF, how many do you think were unnecessary?
>
>EOF has alwyas been negative one on my impkementation.

That's as may be, and it is indeed by far the most common value, but all
the Standard demands is that EOF is negative. Besides, EOF is both
clearer, and only a single character longer, than -1.
My impkemenation is sometimes more clever than the monkey on the keyboard.
--
The theory seems to be that as long as a man is a failure he is one of
God's children, but that as soon as he succeeds he is taken over by the
Devil.
H. L. Mencken
Jul 6 '08 #29
Ron Ford wrote:
On Thu, 03 Jul 2008 12:02:58 GMT, Richard Bos posted:
>Ron Ford <ro*@nowhere.netwrote:
>>I see. What I was getting at was more like:
putchar(anything)!=EOF ....

You may have tried to get at that, but since it wasn't in the OP's
posted code, it would be hard to reach it.
>>The test against anything for a putchar call seems prudent but ends
up being a lot of extra keystrokes and code.

A lot? Rather an exaggeration, isn't it? If you do it right, that
check for EOF will double as your loop termination condition, which
you would have needed anyway.

Out of n tests against EOF, how many do you think were unnecessary?
None. In a typical read loop each return of getc must be tested for EOF.
If feof and ferror are called for each character for ensuring against
unlikely situations then the number of tests are doubled.

Jul 6 '08 #30
In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>>>I see. What I was getting at was more like:
putchar(anything)!=EOF ....
[...]
>None. In a typical read loop each return of getc must be tested for EOF.
Somewhere along the line the question seems to have changed from
putchar() to getc(). It's certainly not always necessary to test
every return value while writing.

-- Richard

--
Please remember to mention me / in tapes you leave behind.
Jul 6 '08 #31
Richard Tobin wrote:
In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>>>>I see. What I was getting at was more like:
putchar(anything)!=EOF ....

[...]
>None. In a typical read loop each return of getc must be tested for EOF.

Somewhere along the line the question seems to have changed from
putchar() to getc(). It's certainly not always necessary to test
every return value while writing.
For standard output, especially in a non interactive program,
I usually don't test for EOF,
and the reason is because
I really don't have an alternative course of action
that makes any difference.

--
pete
Jul 6 '08 #32
Richard Tobin wrote:
In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>>>>I see. What I was getting at was more like:
putchar(anything)!=EOF ....

[...]
>>None. In a typical read loop each return of getc must be tested for
EOF.

Somewhere along the line the question seems to have changed from
putchar() to getc(). It's certainly not always necessary to test
every return value while writing.
Oops missed that. For putchar, testing for EOF may be over-engineering,
at least for stdout and stderr.

Jul 6 '08 #33
santosh wrote:
Richard Tobin wrote:
>In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>>>>>I see. What I was getting at was more like:
>putchar(anything)!=EOF ....

[...]
>>>None. In a typical read loop each return of getc must be tested for
EOF.

Somewhere along the line the question seems to have changed from
putchar() to getc(). It's certainly not always necessary to test
every return value while writing.

Oops missed that. For putchar, testing for EOF may be
over-engineering, at least for stdout and stderr.
No correct that. Any write to stdout must certainly be verified and any
failure reported on stderr. But there is no point in verifying writes
to stderr, since there is usually nothing that can be done on failure.

But I wonder how much C code meticulously tests putchar/printf etc. In
much code that I have encountered even writes to named files were
unverified.

If there is one thing that I find somewhat frustrating in C, it is the
necessity to constantly test the execution of almost every standard
library and user-defined function at each call, if you want robust
code.

Jul 6 '08 #34
In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>>Somewhere along the line the question seems to have changed from
putchar() to getc(). It's certainly not always necessary to test
every return value while writing.
>Oops missed that. For putchar, testing for EOF may be
over-engineering, at least for stdout and stderr.
>No correct that. Any write to stdout must certainly be verified and any
failure reported on stderr.
I said you don't have to test every return value, not that you don't
have to test for errors. For output it's often adequate to test
for errors at the end of the output instead of after every call:
extra failing writes are usually unimportant.

Obviously this doesn't apply to input, where the values read usually
determine when you stop reading.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Jul 6 '08 #35
santosh wrote:
No correct that. Any write to stdout must certainly be verified and any
failure reported on stderr. But there is no point in verifying writes
to stderr, since there is usually nothing that can be done on failure.
Would you expect greater success with the standard error stream
if it were associated with the same file as the standard input stream?

I could see why you might;
they're two different streams which are possibly buffered differently.

But in practice, I'm unfamiliar with any write errors that weren't
caused by a problem with the file.

--
pete
Jul 6 '08 #36
Richard Tobin wrote:
santosh <sa*********@gmail.comwrote:
.... snip ...
>
>None. In a typical read loop each return of getc must be tested
for EOF.

Somewhere along the line the question seems to have changed from
putchar() to getc(). It's certainly not always necessary to test
every return value while writing.
If you can affort to ignore write errors. Which is usually so, or
they are extremely rare.

--
[mail]: Chuck F (cbfalconer at maineline dot net)
[page]: <http://cbfalconer.home.att.net>
Try the download section.

Jul 6 '08 #37
pete wrote:
santosh wrote:
>No correct that. Any write to stdout must certainly be verified and any
failure reported on stderr. But there is no point in verifying writes
to stderr, since there is usually nothing that can be done on failure.

Would you expect greater success with the standard error stream
if it were associated with the same file as the standard input stream?
That should be "as the standard output stream?"
I could see why you might;
they're two different streams which are possibly buffered differently.

But in practice, I'm unfamiliar with any write errors that weren't
caused by a problem with the file.

--
pete
Jul 6 '08 #38
In article <48***************@yahoo.com>,
CBFalconer <cb********@maineline.netwrote:
>Somewhere along the line the question seems to have changed from
putchar() to getc(). It's certainly not always necessary to test
every return value while writing.
>If you can affort to ignore write errors. Which is usually so, or
they are extremely rare.
I don't suggest ignoring them in general, just not checking after every
character. Real i/o errors are rare on general-purpose computers, but
write errors caused by full disks, unplugged memory sticks, and closed
terminal sessions are quite common.

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Jul 6 '08 #39
pete wrote:
pete wrote:
>santosh wrote:
>>No correct that. Any write to stdout must certainly be verified and
any failure reported on stderr. But there is no point in verifying
writes to stderr, since there is usually nothing that can be done on
failure.

Would you expect greater success with the standard error stream
if it were associated with the same file as the standard input
stream?

That should be "as the standard output stream?"
No. However, in many cases stdout happens to be redirected to a disk
file while stderr is still linked to the terminal. In such cases it
might be worthwhile to log failure on stdout to stderr.

<snip>

Jul 6 '08 #40
CBFalconer <cb********@yahoo.comwrote:
Richard Tobin wrote:

Somewhere along the line the question seems to have changed from
putchar() to getc(). It's certainly not always necessary to test
every return value while writing.

If you can affort to ignore write errors.
Or you check for them (via ferror) at the end, like most people do.

-- Larry Jones

These child psychology books we bought were such a waste of money.
-- Calvin's Mom
Jul 6 '08 #41
Ron Ford <ro*@nowhere.netwrote:
On Thu, 03 Jul 2008 12:02:58 GMT, Richard Bos posted:
Ron Ford <ro*@nowhere.netwrote:
EOF has alwyas been negative one on my impkementation.
That's as may be, and it is indeed by far the most common value, but all
the Standard demands is that EOF is negative. Besides, EOF is both
clearer, and only a single character longer, than -1.

My impkemenation is sometimes more clever than the monkey on the keyboard.
Exactly. So use EOF, which is guaranteed by the Standard to be valid for
all implementations, not -1, which your monkey believes to be valid
right here, right now.

Richard
Jul 7 '08 #42
On Sun, 06 Jul 2008 22:51:59 +0530, santosh posted:
pete wrote:
>pete wrote:
>>santosh wrote:

No correct that. Any write to stdout must certainly be verified and
any failure reported on stderr. But there is no point in verifying
writes to stderr, since there is usually nothing that can be done on
failure.

Would you expect greater success with the standard error stream
if it were associated with the same file as the standard input
stream?

That should be "as the standard output stream?"

No. However, in many cases stdout happens to be redirected to a disk
file while stderr is still linked to the terminal. In such cases it
might be worthwhile to log failure on stdout to stderr.

<snip>
I found the snippet that I was thinking was overcautious with checking
against EOF:

if (iscntrl(ch)) {
if (putchar('^') == EOF ||
putchar(ch == '\177' ? '?' :
ch | 0100) == EOF)
break;
continue;
}

It was an uphill climb for me to understand this at all, and without Keith
commenting on it at length, I would have been stalled. In simpler versions
that I wrote, I left off the checks against EOF as I was concentrating on
understanding the short-circuit thing, the ? : syntax and the mask.

Then I thought "under what circumstances is windows with 40 gigs of free
space going to tell my puny C program that there's no room for the next
char, and what the heck could I do about it anyways?"
--
Puritanism. The haunting fear that someone, somewhere, may be happy.
H. L. Mencken
Jul 8 '08 #43
Ron Ford wrote:
On Sun, 06 Jul 2008 22:51:59 +0530, santosh posted:
>pete wrote:
>>pete wrote:
santosh wrote:

No correct that. Any write to stdout must certainly be verified
and any failure reported on stderr. But there is no point in
verifying writes to stderr, since there is usually nothing that
can be done on failure.

Would you expect greater success with the standard error stream
if it were associated with the same file as the standard input
stream?

That should be "as the standard output stream?"

No. However, in many cases stdout happens to be redirected to a disk
file while stderr is still linked to the terminal. In such cases it
might be worthwhile to log failure on stdout to stderr.

<snip>

I found the snippet that I was thinking was overcautious with checking
against EOF:

if (iscntrl(ch)) {
if (putchar('^') == EOF ||
putchar(ch == '\177' ? '?' :
ch | 0100) == EOF)
break;
continue;
}
[ ... ]
Then I thought "under what circumstances is windows with 40 gigs of
free space going to tell my puny C program that there's no room for
the next char, and what the heck could I do about it anyways?"
Things other than disk files or terminals are possible too, and could
fail. Consider that stdout has been redirected with a pipe and that the
pipe is closed by the reading process.

Jul 8 '08 #44
In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>Things other than disk files or terminals are possible too, and could
fail. Consider that stdout has been redirected with a pipe and that the
pipe is closed by the reading process.
In unix, this very common case (consider "ls | more") will typically
cause the writing process to receive a SIGPIPE rather than getting an
error from putchar().

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Jul 8 '08 #45
On 8 Jul 2008 01:27:24 GMT, Richard Tobin posted:
In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>>Things other than disk files or terminals are possible too, and could
fail. Consider that stdout has been redirected with a pipe and that the
pipe is closed by the reading process.

In unix, this very common case (consider "ls | more") will typically
cause the writing process to receive a SIGPIPE rather than getting an
error from putchar().
Do you have a reference for what putchar() looks like for unix
implementations in as close to standard C as you can swing? I couldn't
turn up much with a google search "putchar() openbsd source."
--
Strike an average between what a woman thinks of her husband a month before
she marries him and what she thinks of him a year afterward, and you will
have the truth about him.
H. L. Mencken
Jul 8 '08 #46
Ron Ford wrote:
On 8 Jul 2008 01:27:24 GMT, Richard Tobin posted:
>In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:
>>>Things other than disk files or terminals are possible too, and could
fail. Consider that stdout has been redirected with a pipe and that
the pipe is closed by the reading process.

In unix, this very common case (consider "ls | more") will typically
cause the writing process to receive a SIGPIPE rather than getting an
error from putchar().

Do you have a reference for what putchar() looks like for unix
implementations in as close to standard C as you can swing? I
couldn't turn up much with a google search "putchar() openbsd source."
It's likely to look similar to:

int putchar(int c) {
return putc(c, stdout);
}

Jul 8 '08 #47
In article <1c*****************************@40tude.net>,
Ron Ford <wa********@netzero.netwrote:
>Do you have a reference for what putchar() looks like for unix
http://www.freebsd.org/cgi/cvsweb.cg...ib/libc/stdio/

-- Richard
--
Please remember to mention me / in tapes you leave behind.
Jul 8 '08 #48
On 8 Jul 2008 10:30:19 GMT, Richard Tobin posted:
In article <1c*****************************@40tude.net>,
Ron Ford <wa********@netzero.netwrote:
>>Do you have a reference for what putchar() looks like for unix

http://www.freebsd.org/cgi/cvsweb.cg...ib/libc/stdio/
Thanks, Richard, I've bookmarked that link. Not only does it have the
current version of putchar, it has the whole history of it, including
rationalizations for the changes. It starts out, 14 years ago, looking
like standard C to me:

#if defined(LIBC_SCCS) && !defined(lint)
static char sccsid[] = "@(#)putchar.c 8.1 (Berkeley) 6/4/93";
#endif /* LIBC_SCCS and not lint */

#include <stdio.h>

#undef putchar

/*
* A subroutine version of the macro putchar
*/
putchar(c)
int c;
{
register FILE *so = stdout;

return (__sputc(c, so));
}

#if defined(LIBC_SCCS) && !defined(lint)
#if 0
static char sccsid[] = "@(#)putchar.c 8.1 (Berkeley) 6/4/93";
#endif
static const char rcsid[] =
"$Id$";
#endif /* LIBC_SCCS and not lint */
Somewhere along the line, clc's Chris Torek became the "guy who writes
putchar for openbsd," and it adds on a couple non-standard headers that
apparently deal with threading:

#include <stdio.h>
#ifdef _THREAD_SAFE
#include <pthread.h>
#include "pthread_private.h"
#endif

#undef putchar

/*
* A subroutine version of the macro putchar
*/
int
putchar(c)
int c;
{
int retval;
register FILE *so = stdout;

#ifdef _THREAD_SAFE
_thread_flockfile(so,__FILE__,__LINE__);
#endif
retval = __sputc(c, so);
#ifdef _THREAD_SAFE
_thread_funlockfile(so);
#endif
return (retval);
}

The current version isn't shy about the non-standard headers:
#include "namespace.h"
#include <stdio.h>
#include "un-namespace.h"
#include "local.h"
#include "libc_private.h"
, but does the same thing: it undefines putchar and worries about something
being f locked. I was mildly surprised not to see a test against EOF.

I don't understand much of unix programming, but I find that the time I
spend on it bears dividends down the road. What a quirky thing to have a
header called un-namespace.h.
--
It is not materialism that is the chief curse of the world, as pastors
teach, but idealism. Men get into trouble by taking their visions and
hallucinations too seriously.
H. L. Mencken
Jul 8 '08 #49
On Tue, 08 Jul 2008 14:08:05 +0530, santosh posted:
Ron Ford wrote:
>On 8 Jul 2008 01:27:24 GMT, Richard Tobin posted:
>>In article <g4**********@registered.motzarella.org>,
santosh <sa*********@gmail.comwrote:

Things other than disk files or terminals are possible too, and could
fail. Consider that stdout has been redirected with a pipe and that
the pipe is closed by the reading process.

In unix, this very common case (consider "ls | more") will typically
cause the writing process to receive a SIGPIPE rather than getting an
error from putchar().

Do you have a reference for what putchar() looks like for unix
implementations in as close to standard C as you can swing? I
couldn't turn up much with a google search "putchar() openbsd source."

It's likely to look similar to:

int putchar(int c) {
return putc(c, stdout);
}
I would rather say that that has a K&R flavor to it, except that K&R takes
putchar and getchar as elemental for the exposition.
--
An idealist is one who, on noticing that roses smell better than a cabbage,
concludes that it will also make better soup.
H. L. Mencken
Jul 8 '08 #50

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

18 posts views Thread by jas | last post: by
8 posts views Thread by Patrik Malmström | last post: by
1 post views Thread by Nadja Schmitt | last post: by
10 posts views Thread by Tibby | last post: by
4 posts views Thread by Bruno | last post: by
1 post views Thread by gcdp | last post: by
reply views Thread by gcreed | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.