"streams"

[Kobu]

I have a question about C's abstract "streams" (that I can't seem to
FULLY understand from reading several tutorials).

Streams seems to suggest that input can be treated continously if
needed. Is this true?

So far as I know, I can only get a stream to "flow" when there is a
'\r'. At that point the '\r' is turned into a '\n' and the whole
stream is sent to some abstract area that is now only accessible to my
programs (meanwhile, other data is still piling into the input
"staging" area of the stream, waiting for another '\r' to free them-
allow them to flow).

Is this an accurate observation of C's model? Is there anyway I can
get more of a continuous stream action, instead of this '\r' triggered
stream? I am guessing there might be, but it would be a
C-extension!?!?
By the way, the first couple examples using getchar in K&R2 rely on
comparing (c=getchar()) with EOF. But, what happened to the final '\r'
that actually releases the EOF from it's input staging area? Does that
'\r' stay there waiting to release the next char that comes to the
input to the stream? Does that '\r' get converted to '\n' and sent on
it's way ready for immediate reading by an input function? Does that
'\n' disappear because of some relationship with EOF?
A link to comprehensive tutorials will be appreciated.

[Mike Wahler]

"Kobu" <ko********@gmail.com> wrote in message
news:11*********************@z14g2000cwz.googlegro ups.com...

I have a question about C's abstract "streams" (that I can't seem to
FULLY understand from reading several tutorials).

Streams seems to suggest that input can be treated continously if
needed. Is this true?
Yes, in the sense that i/o is implemented as a
continuous 'stream' of characters. ("continous"
being interruptible by an error condition or an
'end of file' indicator).
So far as I know, I can only get a stream to "flow" when there is a
'\r'.
No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.
At that point the '\r' is turned into a '\n'
Character translations (if any) are defined by a particular
implementation (probably most well known is the 'CR/LF' to/
form '\n' translation in DOS and Windows). Also note that this
'translation' is only applicable to streams opened with 'text
mode' (the default). Streams open in "binary mode" (expressed
with second argument to 'fopen()' of "b"), render the characters
as they are delivered by the attached device, with no 'translations'
at all.
and the whole
stream is sent to some abstract area that is now only accessible to my
programs (meanwhile, other data is still piling into the input
"staging" area of the stream, waiting for another '\r' to free them-
allow them to flow).
You're asking about 'buffering', which is defined by an implementation.
E.g. many/most systems where the standard stream 'stdin' is attached
to a keyboard, use 'line buffering', where the data is not sent to
the program until e.g. an 'Enter' or 'return' key is pressed. But this
is not required by the language.

Is this an accurate observation of C's model?
No, it seems to be your observation of a particular implementation
of C on a particular platform. This is admittedly a very common
behavior.
Is there anyway I can
get more of a continuous stream action, instead of this '\r' triggered
stream?
You're asking about 'nonblocking input', which is not required
(nor prohibited) by the language.
I am guessing there might be, but it would be a
C-extension!?!?

Yes, library extensions are the typical method for doing this
on platforms where it's applicable, e.g. those where 'stdin'
is attached to a line-buffered keyboard input. An implementation
or OS might also provide a facility (via another extension) to disable
'line buffering'. Check your compiler documentation.

-Mike

[pete]

Mike Wahler wrote:

No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.

Text streams are composed of lines, which are newline terminated.

--
pete

[Mike Wahler]

"pete" <pf*****@mindspring.com> wrote in message
news:41***********@mindspring.com...

Mike Wahler wrote:

No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.

Text streams are composed of lines, which are newline terminated.

I wrote 'stream', not 'text stream'.

Anyway, the below excerpt from 9899 indicates to me that
a text stream may contain zero or more newline characters.

7.19.2 Streams

2 A text stream is an ordered sequence of characters composed
into lines, each line consisting of zero or more characters
plus a terminating new-line character. Whether the last line
requires a terminating new-line character is implementation-
defined.

-Mike

[CBFalconer]

pete wrote:

Mike Wahler wrote:

No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.

Text streams are composed of lines, which are newline terminated.

No, they are just sequences of characters, which should include at
least one newline character at the end. There is no intrinsic
reason to limit the count of characters between newline chars in
C. It is just a useful convention to normally keep this below 72
or 80.

The fact that routines such as fgets deliver newline separated
chunks is again not germane to what a stream is.

--
"If you want to post a followup via groups.google.com, don't use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

[pete]

CBFalconer wrote:

pete wrote:

Mike Wahler wrote:

No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.

Text streams are composed of lines, which are newline terminated.

No

N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.

--
pete

[Joe Wright]

pete wrote:

CBFalconer wrote:

pete wrote:

Mike Wahler wrote:
No. A stream of characters need not contain a particular
value character. '\r' (or '\n', etc.) is just another
character.

Text streams are composed of lines, which are newline terminated.

No

N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.

Selective reading pete? Mike didn't specify text streams and the
same section you quote says..

[#3] A binary stream is an ordered sequence of characters
that can transparently record internal data. Data read in
from a binary stream shall compare equal to the data that
were earlier written out to that stream, under the same
implementation.
--
Joe Wright mailto:jo********@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[pete]

Joe Wright wrote:

pete wrote:

CBFalconer wrote:

pete wrote:

Mike Wahler wrote:
>No. A stream of characters need not contain a particular
>value character. '\r' (or '\n', etc.) is just another
>character.

Text streams are composed of lines, which are newline terminated.

No

N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.

Selective reading pete?

I'm just saying that text streams are made of lines.
If you don't want know that, you don't have to.

--
pete

[Mike Wahler]

"pete" <pf*****@mindspring.com> wrote in message
news:41***********@mindspring.com...

CBFalconer wrote:

pete wrote:

Mike Wahler wrote:

> No. A stream of characters need not contain a particular
> value character. '\r' (or '\n', etc.) is just another
> character.

Text streams are composed of lines, which are newline terminated.

No

N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.

You omitted:

Whether the last line requires a terminating new-line character
is implementation-defined.

-Mike

[Mike Wahler]

"pete" <pf*****@mindspring.com> wrote in message
news:41***********@mindspring.com...

Joe Wright wrote:

pete wrote:

CBFalconer wrote:

>pete wrote:
>
>>Mike Wahler wrote:
>>
>>
>>>No. A stream of characters need not contain a particular
>>>value character. '\r' (or '\n', etc.) is just another
>>>character.
>>
>>Text streams are composed of lines, which are newline terminated.
>
>No
N869
7.19.2 Streams
[#2] A text stream is an ordered sequence of characters
composed into lines each line consisting of zero or more
characters plus a terminating new-line character.
Selective reading pete?

I'm just saying

The ISO C standard says
that text streams are made of lines.
that a text stream may or may not contain one or more
newline characters.
If you don't want know that, you don't have to.

Back at ya. :-)

-Mike

[James McIninch]

<posted & mailed>

Kobu wrote:

I have a question about C's abstract "streams" (that I can't seem to
FULLY understand from reading several tutorials).
In C, they are FILEs.

Streams seems to suggest that input can be treated continously if
needed. Is this true?
More or less.
So far as I know, I can only get a stream to "flow" when there is a
'\r'. At that point the '\r' is turned into a '\n' and the whole
stream is sent to some abstract area that is now only accessible to my
programs (meanwhile, other data is still piling into the input
"staging" area of the stream, waiting for another '\r' to free them-
allow them to flow).
C states that input from stdin is line-buffered, but it doesn't say antyhing
about converting characters -- that's something peculiar to your
environment.

Is this an accurate observation of C's model? Is there anyway I can
get more of a continuous stream action, instead of this '\r' triggered
stream? I am guessing there might be, but it would be a
C-extension!?!?
Not in C, but chances are that for any given environment there's a way to do
it.
By the way, the first couple examples using getchar in K&R2 rely on
comparing (c=getchar()) with EOF. But, what happened to the final '\r'
that actually releases the EOF from it's input staging area? Does that
'\r' stay there waiting to release the next char that comes to the
input to the stream? Does that '\r' get converted to '\n' and sent on
it's way ready for immediate reading by an input function? Does that
'\n' disappear because of some relationship with EOF?
A link to comprehensive tutorials will be appreciated.

--
Remove '.nospam' from e-mail address to reply by e-mail

[pete]

Mike Wahler wrote:

"pete" <pf*****@mindspring.com> wrote in message
news:41***********@mindspring.com...

Joe Wright wrote:

pete wrote:
> CBFalconer wrote:
>
>>pete wrote:
>>
>>>Mike Wahler wrote:
>>>
>>>
>>>>No. A stream of characters need not contain a particular
>>>>value character. '\r' (or '\n', etc.) is just another
>>>>character.
>>>
>>>Text streams are composed of lines, which are newline terminated.
>>
>>No
>
>
> N869
> 7.19.2 Streams
> [#2] A text stream is an ordered sequence of characters
> composed into lines each line consisting of zero or more
> characters plus a terminating new-line character.
>
Selective reading pete?

I'm just saying

The ISO C standard says

that text streams are made of lines.

that a text stream may or may not contain one or more
newline characters.

If you don't want know that, you don't have to.

Back at ya. :-)

For maximum portability of code involving text streams and text files,
one should terminate text streams with newline characters
and also bear in mind the environmental limits regarding text files.

N869
7.19.2 Streams

Environmental limits

[#7] An implementation shall support text files with lines
containing at least 254 characters, including the
terminating new-line character.

--
pete