Re: CR-NL, NL and ftell
From: Eric Sosman (esosman_at_acm-dot-org.invalid)
Date: 02/21/05
- Next message: Mars: "Re: the algorithm of decimal<->binary conversion"
- Previous message: infobahn: "Re: CR-NL, NL and ftell"
- In reply to: Bart C: "Re: CR-NL, NL and ftell"
- Next in thread: Christian Kandeler: "Re: CR-NL, NL and ftell"
- Reply: Christian Kandeler: "Re: CR-NL, NL and ftell"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 21 Feb 2005 11:55:18 -0500
Bart C wrote:
> "Eric Sosman" <esosman@acm-dot-org.invalid> wrote in message
> news:nNGdnWUD6rBreoTfRVn-vA@comcast.com...
>
>>Bart C wrote:
>>
>>>[...]
>>>Why doesn't feof work as expected, ie return True when positioned at
>>>end-of-file? Is coding 'currfileposition' >= 'filesize' really that
>>>difficult.
>>
>> Yes. Keep in mind that feof() et al. operate on FILE*
>>streams, which may be connected to data sources (and sinks)
>>that are not fixed-size files. Explain, if you will, how
>>you would implement a "predictive" feof() on a stream taking
>>data from a TCP/IP socket, or even from your keyboard.
>
> I wouldn't. I would treat disk files differently from devices such as
> keyboards or i/o ports. The two kinds of data are different enough to
> warrant a separate set of functions
IMHO such a step would be a backwards step. The first
programming language I used had different I/O verbs for
different devices: "READ CARD," "PUNCH PAPER TAPE," and so
on. A program that had been written to generate output on
punched cards could not be persuaded to write a magnetic
tape instead; a program capable of both card and tape output
needed conditional logic at every output-generating point to
decide which verb was appropriate, which (as you can imagine)
was both ugly and bug-prone.
C's uniform I/O model relieves the programmer of such
headaches by pushing the details of handling different device
types out of the application arena and into the implementation.
Devices differ, of course, and this has two consequences: first,
some of the differences get "filed off" in the sense that the
unified I/O model can't exploit them (e.g., there's no portable
way for a C program to stream data to your sound card), and
second, some of the differences obtrude themselves through the
uniformity in ugly ways (e.g., setvbuf(), fflush() ...). Still
and all, I feel it's a pretty good trade most of the time.
> I also found some time back on this newgroup that reading a single key from
> the keyboard was not part of standard C!
"The keyboard" itself is not part of standard C.
> This is a problem I remember from
> mainframes in the 70s. It went away with microcomputers in the 80s, and now
> with C it's come back again. 2 major revisions of the C standard and
> something so basic is not in?
C has a perfectly good way of reading a single character
(or getting an EOF or error indication) from any input source:
it's called getc(). However, different input sources have
different ideas about how and when to provide their characters.
Users of systems with keyboards often like to be able to edit
their input while composing it, so most platforms gather keyed
input in a "batch and commit" mode. Some platforms provide a
way to change the mode, but since different platforms do it
differently, the C language Standard cannot legislate one
platform's solution over the others'.
Remember always that the C Standard carries no authority
beyond that voluntarily granted it by organizations that choose
to adopt and/or require it. If the Standard had required a
discipline for keyboard handling that was difficult for some
systems to support, the users of those systems would have been
less inclined to adopt the Standard.
>> Your experience with different file formats is clearly
>>not very extensive. Here are a few of the byte sequences
>>you might find in a file after puts("Hello") -- all of these
>>are from my own experience and none is a fabrication, although
>>I may have mis-remembered a detail here and there:
>>
>>H e l l o \n
>>H e l l o \r
>>H e l l o \r \n
>>\005 \000 H e l l o \000
>>H e l l o \040 \040 \040... (75 spaces all told)
>>\006 \000 \001 H e l l o
>>H e l l o \n \032... (plus 121 garbage characters)
>
> My specs for puts() say that '\n' is appended after the string argument.
> Whether that means cr-lf, cr or lf I'm not sure, but it's best to assume any
> of these when reading such a file.
All my examples have the '\n' present. You can't see
it in some of them because the '\n' is encoded differently
in different storage schemes, but that doesn't mean it's
missing.
> If you're getting all this extra garbage
> after your data (I don't mean padding bytes to fill up a disk sector) then
> I'd complain.
The point is that you *don't* get "all this extra garbage"
if you use a text stream to read the data back again: the C
library understands the local conventions for files, and mediates
between their idiosyncrasies and a simpler convention.
> If the OS, disk controller, modem, whatever wants to add extra bytes to
> that, that's fine provided they are transparent.
The text stream makes them so. And that's reason enough
(referring to your earlier message) to "bother with text mode
and all it's [sic] pitfalls."
-- Eric Sosman esosman@acm-dot-org.invalid
- Next message: Mars: "Re: the algorithm of decimal<->binary conversion"
- Previous message: infobahn: "Re: CR-NL, NL and ftell"
- In reply to: Bart C: "Re: CR-NL, NL and ftell"
- Next in thread: Christian Kandeler: "Re: CR-NL, NL and ftell"
- Reply: Christian Kandeler: "Re: CR-NL, NL and ftell"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
