read and write columns

  • Thread starter Bill Cunningham
  • Start date
C

Chris Torek

Thanks, Richard, I've bookmarked that link. Not only does it have the
current version of putchar, it has the whole history of it ...

Well, it has the history of FreeBSD's version. (There are other
versions, some of whose history is largely unrelated.)
... It starts out, 14 years ago, looking like standard C to me ...

That was the one I wrote. Note, however, that the name __sputc
is reserved to the implementor (i.e., me).
Somewhere along the line, clc's Chris Torek became the "guy who writes
putchar for openbsd," ...

The only BSD version of putc I modified after the original releases
from Berkeley was the one in BSD/OS. None of the OpenBSD, NetBSD,
or FreeBSD changes are mine.
... 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.

The "locking" is for POSIX threads. (We had to add the same thing to
BSD/OS, though the added code was a bit different.)

Since all the real work is done by the __sputc() macro and the
function it calls, the putchar() code itself always remains trivial.
The macro is defined elsewhere (originally, in <stdio.h>, but it
may have moved in some versions).
 
R

Ron Ford

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

Ron Ford

Well, it has the history of FreeBSD's version. (There are other
versions, some of whose history is largely unrelated.)


That was the one I wrote. Note, however, that the name __sputc
is reserved to the implementor (i.e., me).


The only BSD version of putc I modified after the original releases
from Berkeley was the one in BSD/OS. None of the OpenBSD, NetBSD,
or FreeBSD changes are mine.


The "locking" is for POSIX threads. (We had to add the same thing to
BSD/OS, though the added code was a bit different.)

Since all the real work is done by the __sputc() macro and the
function it calls, the putchar() code itself always remains trivial.
The macro is defined elsewhere (originally, in <stdio.h>, but it
may have moved in some versions).

Well, hot damn! You're the bsd guy.

My sysadmin buddy is helping me build a robust linux partition. I'm gonna
have to brag that I know you if your name comes up. It may be an
embellishment but not a dangerous one.

I poked around more to see if I could pick up the trail on __sputc(), but
it's a bit of a needle in a haystack when you don't know where to look.
 
S

santosh

Ron said:
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/O 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.
 
R

Ron Ford

The Standard describes all stream I/O 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?
 
S

santosh

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


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 EOF. Otherwise, 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 EOF.[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
EOF.
 
R

Ron Ford

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


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 EOF. Otherwise, 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 EOF.[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
EOF.

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

Keith Thompson

Ron Ford said:
I didn't know that. What do fgetc/fputc return on success/failure?

Frankly, that's a very elementary question that you should be able to
answer in just a moment by consulting a reference book or online
documentation. One of the most important skills for any programmer is
knowing how to use the local resources that are available to you.
 
R

Ron Ford

Ron Ford said:



No, but some computers do.


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

Of course, monitors can be lizards like any others.
 
R

Ron Ford

Frankly, that's a very elementary question that you should be able to
answer in just a moment by consulting a reference book or online
documentation. One of the most important skills for any programmer is
knowing how to use the local resources that are available to you.

That wasn't the reason for the reply. I was more interested in the
abstract elegance of the Standard's model as seen from the point of view of
char io. I'm reminded of passages I didn't read in the Bible that say
"stitch these letters together into an all-compelling mosaic for ethics and
truth."
 
K

Keith Thompson

Ron Ford said:
Ron Ford said:
On Wed, 09 Jul 2008 14:47:04 +0530, santosh posted: [...]
The Standard describes all stream I/O 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?

Frankly, that's a very elementary question that you should be able to
answer in just a moment by consulting a reference book or online
documentation. One of the most important skills for any programmer is
knowing how to use the local resources that are available to you.

That wasn't the reason for the reply. I was more interested in the
abstract elegance of the Standard's model as seen from the point of view of
char io. I'm reminded of passages I didn't read in the Bible that say
"stitch these letters together into an all-compelling mosaic for ethics and
truth."

Well, when you wrote "What do fgetc/fputc return on success/failure?",
I just assumed that you wanted to know what fgetc and fputc return on
success and failure. If you had wanted to know something else, you
should have asked something else.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,731
Messages
2,569,432
Members
44,835
Latest member
KetoRushACVBuy

Latest Threads

Top