Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Reading beyond the end of file |
| Date | 2015-09-26 18:53 -0700 |
| Organization | None to speak of |
| Message-ID | <lnd1x48w6b.fsf@kst-u.example.com> (permalink) |
| References | (3 earlier) <kfnbndfql81.fsf@x-alumni2.alumni.caltech.edu> <lnsi6rt7id.fsf@kst-u.example.com> <kfnmvwskhqm.fsf@x-alumni2.alumni.caltech.edu> <ln613gmyel.fsf@kst-u.example.com> <kfnvbawgadb.fsf@x-alumni2.alumni.caltech.edu> |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> Keith Thompson <kst-u@mib.org> writes:
>>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>>> Keith Thompson <kst-u@mib.org> writes:
>>
>> [...]
>>
>>>>>> It never makes sense to store the value EOF in a char, signed char,
>>>>>> or unsigned char object. It's intended as an in-band signal,
>>>>>> distinct from any valid input character. [snip]
>>>>>
>>>>> Presumably you meant to say out-of-band rather than in-band.
>>>>
>>>> No, I meant to say in-band. It's possible I misused the term, but I
>>>> don't think so.
>>>>
>>>> Calling getchar() repeatedly gives you a sequence of int values. Most
>>>> of those values are going to represent character values in the range
>>>> 0..UCHAR_MAX. The value EOF in the same sequence does not represent a
>>>> character value.
>>>
>>> Which term applies depends on what is considered "the band". I
>>> think of getchar() as returning a character - the type is int,
>>> but what the value represents is a character. I think most C
>>> developers think of getchar() as returning a character. From
>>> this perspective, the value EOF, which is negative whereas all
>>> character values are non-negative (with the usual assumption that
>>> UCHAR_MAX <= INT_MAX), qualifies as an "out-of-band" value. To
>>> say this another way, there is no character that can be written
>>> to a file which when read back (under the same assumption as
>>> before) would give EOF.
>>>
>>> I agree of course that getchar() returns int values, but it does
>>> that precisely so that it can accommodate an extra value (EOF)
>>> that corresponds to no character. The range of the type is not
>>> the same as the range of the values.
>>>
>>> Let me add that there is nothing logically wrong with thinking
>>> of "the band" as being all character values plus EOF, or as
>>> being all int values even though most of the negative ones are
>>> never returned. I just think that doesn't correspond to most
>>> developers' mental model for what getchar() is used for.
>>
>> Thinking of getchar() as a function that returns a character is what
>> leads a lot of (mostly beginning) programmers to incorrectly assign its
>> return value to a char object. (I'm sure you don't make that mistake
>> yourself.)
>
> Does this mean you agree with me that most developers, or at
> least many developers, think of getchar() as returning a
> character?
I don't know what "most", or even "many", developers think.
getchar() returns *either* a character (represented as an int value)
*or* the non-character value EOF. Some inexperienced C programmers are
unaware of that (and need to learn it before they'll be able to use
getchar() correctly).
>> It seems to be that getchar()'s behavior matches the idea of in-band
>> signalling almost perfectly.
>
> (You meant "me" rather than "be" in that sentence, yes?)
Yes.
> All I'm saying is that whether EOF is in-band or out-of-band
> depends on ones conception of what the "signal frequency band"
> is. I think of the frequency band in this case as being just
> non-negative integers within the range of unsigned char. You
> think of it as larger range (ie, at least including EOF). I
> don't think either view is right or wrong, or necessarily better
> or worse. My point is only that there are different views, and
> which term applies depends on which view one has. Is that
> something you can agree with?
The original meanings of "in-band" and "out-of-band" signalling come
from analog communications, a topic with which I'm not particularly
familiar. Perhaps if I were the idea that EOF is an "out-of-band
signal" would make more sense to me.
Stepping back from those terms for a moment, calling getchar()
repeatedly yields a series of int values. Some of those values are
character values (obtained as unsigned char values and converted
to int); others are the value of EOF. Both are returned as part
of the same sequence of values.
An alternative would have been to have a function like:
int next_character(char *c);
which returns 0 if it was able to read a character (and then stores
that character in *c) *or* returns -1 if it was not able to read
a character. The two pieces of information, namely the character
that was read and the indicator of whether a character was read or
not, are handled separately, not combined into a single value as
getchar() does.
I tend to think of the getchar() approach as "in-band" and the
next_character approach as "out-of-band". Perhaps that's a misuse
of the terms as they were originally used. If that's the case, I'd
probably prefer to avoid those terms in the context of programming,
and find some other way to express this distinction.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-11 10:06 -0700
Re: Reading beyond the end of file Geoff <geoff@invalid.invalid> - 2015-09-11 12:41 -0700
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 14:24 -0700
Re: Reading beyond the end of file Geoff <geoff@invalid.invalid> - 2015-09-26 21:49 -0700
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 13:57 -0700
Re: Reading beyond the end of file Geoff <geoff@invalid.invalid> - 2015-10-01 17:22 -0700
Re: Reading beyond the end of file raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:05 +0000
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 17:56 -0700
Re: Reading beyond the end of file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-09-11 13:55 -0600
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 14:14 -0700
Re: Reading beyond the end of file Siri Cruz <chine.bleu@yahoo.com> - 2015-09-26 14:43 -0700
Re: Reading beyond the end of file Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-09-26 17:57 -0400
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 14:01 -0700
Re: Reading beyond the end of file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-09-26 22:18 -0600
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 12:58 -0700
Re: Reading beyond the end of file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-01 15:08 -0600
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 18:03 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 04:02 +0000
Re: Reading beyond the end of file raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:11 +0000
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-02 09:31 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-03 16:07 -0400
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 19:06 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-09-11 14:36 -0700
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 14:05 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-09-26 18:53 -0700
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 13:49 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-01 20:23 -0400
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-02 06:14 +0000
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 19:03 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-04 22:55 -0400
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 04:27 +0000
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-04 22:21 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 09:53 +0000
Re: Reading beyond the end of file James Kuyper <jameskuyper@verizon.net> - 2015-10-05 13:15 -0400
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-05 10:25 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:30 +0000
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:27 +0000
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-05 10:17 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-05 11:59 -0700
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-05 13:44 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:58 +0000
Ones' complement subtraction supercat@casperkitty.com - 2015-10-05 15:28 -0700
Re: Ones' complement subtraction glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 02:14 +0000
Re: Ones' complement subtraction supercat@casperkitty.com - 2015-10-06 08:48 -0700
Re: Ones' complement subtraction glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 20:55 +0000
Re: Ones' complement subtraction supercat@casperkitty.com - 2015-10-06 14:41 -0700
Re: Ones' complement subtraction glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-07 00:14 +0000
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-05 15:24 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:39 +0000
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-05 15:31 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 03:04 +0000
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-06 08:55 -0700
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-06 11:44 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-05 23:16 -0400
Re: Reading beyond the end of file James Kuyper <jameskuyper@verizon.net> - 2015-10-06 10:29 -0400
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-06 08:56 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-06 23:13 -0400
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-06 22:01 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-07 08:43 -0700
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-07 10:02 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-07 13:08 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-07 22:03 -0400
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:47 -0700
csiph-web