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"))!=EF);
if ((fpr=fopen("data","r"))!=EF);
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

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"))!=EF);
>
It isn't an idiom. It's just a bug.

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

My point was that my S 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."

Thu, 03 Jul 2008 10:11:47 +0000, Richard Heathfield posted:

Ron Ford said:
>
>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"))!=EF);

It isn't an idiom. It's just a bug.
>>
>When I have to do I with C, I use safegets, but I don't think that that
>is what you mean.
>>
>My point was that my S doesn't say nay to me on a char basis.
>>
>I'm curious what you mean.
>
The fopen function never returns EF, ever. Since EF is an int, and since
fopen returns a FILE *, testing the return value of fopen against EF is
completely pointless. (In this case, the semicolon makes it doubly
pointless.)

I see. What I was getting at was more like:
putchar(anything)!=EF

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

EF has alwyas been negative one on my impkementation.
--

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"))!=EF);
>if ((fpr=fopen("data","r"))!=EF);
>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

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

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"))!=EF);
if ((fpr=fopen("data","r"))!=EF);
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

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

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

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>

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 EF:

if (iscntrl(ch)) {
if (putchar('^') == EF ||
putchar(ch == '\177' ? '?' :
ch | 0100) == EF)
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 EF 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

Ron Ford wrote:

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 EF:
>
if (iscntrl(ch)) {
if (putchar('^') == EF ||
putchar(ch == '\177' ? '?' :
ch | 0100) == EF)
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.

Tue, 08 Jul 2008 18:01:00 -0400, CBFalconer posted:

Ron Ford wrote:
>santosh posted:
Ron Ford wrote:

snip

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.
>
No, they take "putc(char, FILE*);" and "getc(FILE*);" as the
primitives. From these you can build the rest. But not from
putchar/getchar.

I'm not sure what "primitive" or "elemental" means exactly, but putc and
getc enter K&R2 in chapter seven while putchar and getchar are what the
first chapter is about almost entirely.

Now that I've seen how openbsd putchar uses __sputc(), I wouldn't be able
to talk about generalities.
--
For it is mutual trust, even more than mutual interest that holds human
associations together. friends seldom profit us but they make us feel
safe. Marriage is a scheme to accomplish exactly that same end.
H. L. Mencken

Ron Ford wrote:

Tue, 08 Jul 2008 18:01:00 -0400, CBFalconer posted:
>
>Ron Ford wrote:
santosh posted:
Ron Ford wrote:

>snip

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.
>>
>No, they take "putc(char, FILE*);" and "getc(FILE*);" as the
>primitives. From these you can build the rest. But not from
>putchar/getchar.
>
I'm not sure what "primitive" or "elemental" means exactly, but putc
and getc enter K&R2 in chapter seven while putchar and getchar are
what the first chapter is about almost entirely.
>
Now that I've seen how openbsd putchar uses __sputc(), I wouldn't be
able to talk about generalities.

The Standard describes all stream I/ as a sequence of fgetc/fputc
calls. In practise however, as you have found, implementations need to
consider various other things and usually cannot uphold the abstract
elegance of the Standard's model.

Wed, 09 Jul 2008 14:47:04 +0530, santosh posted:

Ron Ford wrote:
>
>Tue, 08 Jul 2008 18:01:00 -0400, CBFalconer posted:
>>
Ron Ford wrote:
santosh posted:
Ron Ford wrote:

snip

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.

No, they take "putc(char, FILE*);" and "getc(FILE*);" as the
primitives. From these you can build the rest. But not from
putchar/getchar.
>>
>I'm not sure what "primitive" or "elemental" means exactly, but putc
>and getc enter K&R2 in chapter seven while putchar and getchar are
>what the first chapter is about almost entirely.
>>
>Now that I've seen how openbsd putchar uses __sputc(), I wouldn't be
>able to talk about generalities.
>
The Standard describes all stream I/ as a sequence of fgetc/fputc
calls. In practise however, as you have found, implementations need to
consider various other things and usually cannot uphold the abstract
elegance of the Standard's model.

I didn't know that. What do fgetc/fputc return on success/failure?
--
If women believed in their husbands they would be a good deal happier and
also a good deal more foolish.
H. L. Mencken

Ron Ford wrote:
Wed, 09 Jul 2008 14:47:04 +0530, santosh posted:

<snip>

>The Standard describes all stream I/ as a sequence of fgetc/fputc
>calls. In practise however, as you have found, implementations need
>to consider various other things and usually cannot uphold the
>abstract elegance of the Standard's model.
>
I didn't know that. What do fgetc/fputc return on success/failure?

Extract from n1256.pdf:

7.19.7 Character input/output functions
7.19.7.1 The fgetc function
Synopsis
1 #include <stdio.h>
int fgetc(FILE *stream);
Description
2 If the end-of-file indicator for the input stream pointed to by stream
is not set and a next character is present, the fgetc function obtains
that character as an unsigned char converted to an int and advances
the associated file position indicator for the stream (if defined).
Returns
3 If the end-of-file indicator for the stream is set, or if the stream
is at end-of-file, the end-of-file indicator for the stream is set and
the fgetc function returns EF. , the fgetc function returns
the next character from the input stream pointed to by stream. If a
read error occurs, the error indicator for the stream is set and the
fgetc function returns EF.[255]

[255] An end-of-file and a read error can be distinguished by use of the
feof and ferror functions.

7.19.7.3 The fputc function
Synopsis
1 #include <stdio.h>
int fputc(int c, FILE *stream);
Description
2 The fputc function writes the character specified by c (converted to
an unsigned char) to the output stream pointed to by stream, at the
position indicated by the associated file position indicator for the
stream (if defined), and advances the indicator appropriately. If the
file cannot support positioning requests, or if the stream was opened
with append mode, the character is appended to the output stream.
Returns
3 The fputc function returns the character written. If a write error
occurs, the error indicator for the stream is set and fputc returns
EF.

Sat, 12 Jul 2008 00:16:15 +0530, santosh posted:

Ron Ford wrote:
>Wed, 09 Jul 2008 14:47:04 +0530, santosh posted:
>
<snip>
>
The Standard describes all stream I/ as a sequence of fgetc/fputc
calls. In practise however, as you have found, implementations need
to consider various other things and usually cannot uphold the
abstract elegance of the Standard's model.
>>
>I didn't know that. What do fgetc/fputc return on success/failure?
>
Extract from n1256.pdf:
>
7.19.7 Character input/output functions
7.19.7.1 The fgetc function
Synopsis
1 #include <stdio.h>
int fgetc(FILE *stream);
Description
2 If the end-of-file indicator for the input stream pointed to by stream
is not set and a next character is present, the fgetc function obtains
that character as an unsigned char converted to an int and advances
the associated file position indicator for the stream (if defined).
Returns
3 If the end-of-file indicator for the stream is set, or if the stream
is at end-of-file, the end-of-file indicator for the stream is set and
the fgetc function returns EF. , the fgetc function returns
the next character from the input stream pointed to by stream. If a
read error occurs, the error indicator for the stream is set and the
fgetc function returns EF.[255]
>
[255] An end-of-file and a read error can be distinguished by use of the
feof and ferror functions.
>
7.19.7.3 The fputc function
Synopsis
1 #include <stdio.h>
int fputc(int c, FILE *stream);
Description
2 The fputc function writes the character specified by c (converted to
an unsigned char) to the output stream pointed to by stream, at the
position indicated by the associated file position indicator for the
stream (if defined), and advances the indicator appropriately. If the
file cannot support positioning requests, or if the stream was opened
with append mode, the character is appended to the output stream.
Returns
3 The fputc function returns the character written. If a write error
occurs, the error indicator for the stream is set and fputc returns
EF.

I ended up with a little down time in which I did the same thing: poked
through n1256.pdf for putc. The return types are consistent with what one
would guess. I also found this:

5.2.2 Character display semantics
1 The active position is that location on a display device where the next
character output by
the fputc function would appear.

C has a display device? I thought it was stygian witch lacking a monitor.
--
For centuries, theologians have been explaining the unknowable in terms of
the-not-worth-knowing.
H. L. Mencken

Fri, 11 Jul 2008 21:35:27 +0000, Richard Heathfield posted:

Ron Ford said:
>
<snip>
>
>5.2.2 Character display semantics
>1 The active position is that location on a display device where the next
>character output by
>the fputc function would appear.
>>
>C has a display device?
>
No, but some computers do.
>
>I thought it was stygian witch lacking a monitor.
>
Who said anything about a monitor?

I think monitors fall into the class of objects that C doesn't have like
they do other places: monitors, classes and objects. Classes are down the
hall, and objects are not object-oriented.

To answer the question without using passive voice, I'll say, "Keith and
others." It might be an instance of Keith making things simpler for a
windows guy, which this windows guy appreciates. I also claim that he says
that the only mention of fortran is that it is a common extension. That's
not literally true but look at the answer he saved me from:

1 The fortran function specifier may be used in a function declaration to
indicate that
calls suitable for FRTRAN should be generated, or that a different
representation for the
external name is to be generated (6.7.4).


Display devices can be monitors, but
they can also be printers, teletypes, ticker tapes, fax machines, LED
arrays C isn't picky. What's more, the Standard doesn't actually
mandate a display device - it merely describes a little of the semantics,
should such a device happen to be connected to the system.

I see, half on my monitor and half using the stygian urim and thummim. I
find 2 places where "display device" enters the standard. §5.2.2 has
semantics and then in J-1, and I'm not sure how I found J-1, as I can't
seem to replicate it. Anyways, J-1 is in the appendix for unspecified
behavior while §5.2.2 talks of an "active position." I like this talk as
it reminds of quantum mechanics.

Monitors, printers, teletypes, ticker tapes, fax machines, LED arrays and
clickers have events that correspond to observables. You can make all
kinds of Schroedinger apparatuses, but I like the notion that fputc was
supposed to put something, somewhere observable. This argues against a
character in the output being doomed to non-observance.

course, monitors can be lizards like any others.

--
The chief contribution of Protestantism to human thought is its massive
proof that God is a bore.
H. L. Mencken