«

<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

Mike Wahler wrote:
>
> "pete" <> wrote in message
> news:...
> > 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