Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #70255 > unrolled thread

Re: Reading beyond the end of file

Back to article view | Back to comp.lang.c

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  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

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

#71726

On 10/2/15 12:31 PM, supercat@casperkitty.com wrote:
> On Friday, October 2, 2015 at 8:11:51 AM UTC-5, Richard Bos wrote:
>> Tim Rentsch wrote:
>> But that's not how that page considers a "defined frequency band" in the
>> case of computer data, nor does nearly everybody else. The "band", in
>> this case, is the used data channel, which is the int getchar() returns;
>> out-of-band is something which is _not_ that data channel, but another
>> channel entirely.
>
> The return value of getchar() multiplexes two pieces of information into
> one.  The value -1 is typically not within the band of data being read from
> the file, but is within the band of "int" values being returned by getchar().
> If code drops all negative values received by getchar() and returns only
> positive values, that code would separate out information that was in-band
> for getchar() so it would again be out-of-band.
>

Do you consider asin() returning NaN as an Out of Band Signal? The -1 
that getchar() returns is exactly the equivalent.

The 'Band' is a channel of communication. The return value of a function 
is a channel, other channels that a function might use to return 
information are pointers passed in, or global variables, or possibly 
even using longjmp().

getchar() DOES have an out-of-band method of indicating end of file, in 
that the file, stdin, a global, has state changed that can be tested 
with other functions and errno is set.

[toc] | [prev] | [next] | [standalone]

#71918

raltbos@xs4all.nl (Richard Bos) writes:

> Tim Rentsch <txr@alumni.caltech.edu> wrote:
>
>> Right at the start that page says:
>>
>>     /Out-of-band/ refers to activity outside of a defined
>>     telecommunications frequency band, ...
>>
>> If one considers the metaphorical "defined frequency band" to
>> be non-negative integer values corresponding to unsigned char
>> values, then EOF is outside of that range.
>
> But that's not how that page considers a "defined frequency band" in the
> case of computer data, nor does nearly everybody else.  The "band", in
> this case, is the used data channel, which is the int getchar() returns;
> out-of-band is something which is _not_ that data channel, but another
> channel entirely.
> For instance, if getchar() took a char pointer and wrote the read
> character through that, and also returned an int value indicating
> success or failure, _that_ would be out-of-band.  It's not _in_ the
> character written, it's _out_ of it.
>
> (Or, succinctly, _in-band_ error codes are read in the same _place_ as
> genuine data; _out-of-band_ error codes are read somewhere else.)

My response to Richard Damon addresses this point at
some length.  I ask that you refer to my comments in
that posting.

[toc] | [prev] | [next] | [standalone]

#70281

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

It seems to be that getchar()'s behavior matches the idea of in-band
signalling almost perfectly.

-- 
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"

[toc] | [prev] | [next] | [standalone]

#71225

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?

> 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?)

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?

[toc] | [prev] | [next] | [standalone]

#71250

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"

[toc] | [prev] | [next] | [standalone]

#71567

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:
>>>>> 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.)
>>
>> [snip for brevity]
>>
>>> It seems to [me] that getchar()'s behavior matches the idea of in-band
>>> signalling almost perfectly.
>>
>> 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.

I think a good analogy is comparing acoustic modems and DSL modems
on voice phone lines.  Acoustic modems operate in the same frequency
range as voice communication;  DSL modems operate in a different
frequency range.  That makes acoustic modem chirps and squeals be
in-band signals, and DSL modem modulations be out-of-band signals.
The distinction is important because in-band signals can be confused
with normal voice signals, whereas out-of-band signals do not have
this potential confusion.  That's why a phone line can have DSL
service and allow voice calls over the same line even when the DSL
modem is operating, but using an acoustic modem monopolizes the
line.

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

What is interesting (and was to me surprising) is that your
distinction here is made on the basis of what mechanism is used.
For me which mechanism is used doesn't matter - as long as EOF
can't be mistaken for a transmitted character value (and with
character values being the "normal" signal returned by getchar())
then I would call EOF an out-of-band value (or signal).

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

Given what I have learned from this conversation, certainly I
will try to be more careful in the future about how I use the
terms (and what other people mean when they use them).  But I
hope you won't abandon using them altogether, because the concept
is one that comes up often and is useful to identify.

[toc] | [prev] | [next] | [standalone]

#71582

On 10/1/15 4:49 PM, Tim Rentsch wrote:
>
> What is interesting (and was to me surprising) is that your
> distinction here is made on the basis of what mechanism is used.
> For me which mechanism is used doesn't matter - as long as EOF
> can't be mistaken for a transmitted character value (and with
> character values being the "normal" signal returned by getchar())
> then I would call EOF an out-of-band value (or signal).

By that analogy, the NUL at the end of a string is an 'out of band' signal?

As far as what is the 'normal' return of getchar(), that is clearly an 
int, as that is how it is defined, and thus the return value is the 'band'.

By definition, the EOF signal needs to be something that can't be 
mistaken for a transmitted character value, or it isn't reliable, in 
band or out. Many communication protocols send data in octets, and use 
special encoding to mark 'protocol' items in-band (which may require 
tweaking normal data that might look like these items.) An out of band 
method would be to use something outside of the data packets to transfer 
the control information.

[toc] | [prev] | [next] | [standalone]

#71586

Richard Damon <Richard@damon-family.org> wrote:
> On 10/1/15 4:49 PM, Tim Rentsch wrote:

>> What is interesting (and was to me surprising) is that your
>> distinction here is made on the basis of what mechanism is used.
>> For me which mechanism is used doesn't matter - as long as EOF
>> can't be mistaken for a transmitted character value (and with
>> character values being the "normal" signal returned by getchar())
>> then I would call EOF an out-of-band value (or signal).
 
> By that analogy, the NUL at the end of a string is an 'out of band' signal?

In the usual case it is in-band, as '\0' could be written to a char
array, and if it isn't the string end character, it is valid.

If char is unsigned, then the usual EOF value of -1 is not in-band.

If, for some reason, X'00' wasn't legal, for example you can't
write one onto an even parity NRZI tape, a system could use it
as an out-of-band signal at the end of a buffer.
 
> As far as what is the 'normal' return of getchar(), that is 
> clearly an int, as that is how it is defined, and thus the 
> return value is the 'band'.

If char is signed then -1 is an in-band (actual character) value.
 
> By definition, the EOF signal needs to be something that can't be 
> mistaken for a transmitted character value, or it isn't reliable, in 
> band or out. Many communication protocols send data in octets, and use 
> special encoding to mark 'protocol' items in-band (which may require 
> tweaking normal data that might look like these items.) An out of band 
> method would be to use something outside of the data packets to transfer 
> the control information.

For bit-stuffed serial links, I would consider it out of band.A

Using escape characters, and escaping the escape character when
it really appears, is an interesting case.

-- glen

[toc] | [prev] | [next] | [standalone]

#71917

Richard Damon <Richard@Damon-Family.org> writes:

> On 10/1/15 4:49 PM, Tim Rentsch wrote:
>
>> What is interesting (and was to me surprising) is that your
>> distinction here is made on the basis of what mechanism is used.
>> For me which mechanism is used doesn't matter - as long as EOF
>> can't be mistaken for a transmitted character value (and with
>> character values being the "normal" signal returned by getchar())
>> then I would call EOF an out-of-band value (or signal).
>
> By that analogy, the NUL at the end of a string is an 'out of
> band' signal?
>
> As far as what is the 'normal' return of getchar(), that is
> clearly an int, as that is how it is defined, and thus the return
> value is the band'.
>
> By definition, the EOF signal needs to be something that can't be
> mistaken for a transmitted character value, or it isn't reliable,
> in band or out.  Many communication protocols send data in octets,
> and use special encoding to mark 'protocol' items in-band (which
> may require tweaking normal data that might look like these
> items.)  An out of band method would be to use something outside
> of the data packets to transfer the control information.

I've been surprised by the vehemance, for lack of a better word,
in the responses to my comments.  I don't see why people feel
they have to be so emphatic.  Let me see if I can get the
conversation into a cooler climate.

First, I have done network programming, and know about channels
and out-of-band messages and out-of-band signalling in that
context.  I agree that what other people have described is normal
usage in that context.  I don't think there is anything wrong
with using the terms in that sense, whether one is talking about
communication channels or something else.

At the same time, there are other usages in different contexts,
and there is equally nothing wrong with using the terms in
those senses.  Yes, the two meanings are different;  these
terms do not have a single technical definition.  Some groups
of people may expect one particular sense or another, depending
on their background, but that doesn't mean one sense is right
and another is wrong, only that their expectations may not match
how the terms are being used.

In your explanation, you liken the 'int' type to a communication
channel.  I understand that metaphor, and there is nothing wrong
with it.  However other metaphors are possible.  In the analogy
I gave (but not included above) in the post being responded to,
the int type is more like the wire, or medium, of a phone line
carrying both kinds of signals.  There is a single medium,
whether a wire or radio transmission or an int type, that
carries two different kinds of signals.  In this metaphor the
ranges of integer values correspond to frequency ranges of
radio transmissions or of electrical signals on a telephone
wire.  Seen from that perspective what constitutes an in-band
signal is different than what it is under the channel metaphor.

What's really surprising to me is the insistence that the channel
metaphor is the only metaphor possible (or maybe the only
sensible one, or some variation along those lines).  It's hard to
understand what these kinds of comments are meant to communicate.
That many or most programmers would understand the terms
differently than how I used them?  I'm okay with that statement.
That how I'm using the terms is stupid?  Well that may be true
but I see no point in arguing the matter.  That there is only
one way that anyone but me uses or understands these terms?
There I have to say that seems factually incorrect, even based
just on comments in the newsgroup.  So I guess my question is,
what is it that people are trying to communicate?

My goal here is only to convey what I mean so people understand
what I'm saying.  There seems to be no point in arguing about
which usage is the right one, as the terms are used in different
ways and have no intrinsic single meaning.

I sincerely hope the comments above will help the discussion.

[toc] | [prev] | [next] | [standalone]

#71922

On 10/4/15 10:03 PM, Tim Rentsch wrote:
> Richard Damon <Richard@Damon-Family.org> writes:
>
>> On 10/1/15 4:49 PM, Tim Rentsch wrote:
>>
>>> What is interesting (and was to me surprising) is that your
>>> distinction here is made on the basis of what mechanism is used.
>>> For me which mechanism is used doesn't matter - as long as EOF
>>> can't be mistaken for a transmitted character value (and with
>>> character values being the "normal" signal returned by getchar())
>>> then I would call EOF an out-of-band value (or signal).
>>
>> By that analogy, the NUL at the end of a string is an 'out of
>> band' signal?
>>
>> As far as what is the 'normal' return of getchar(), that is
>> clearly an int, as that is how it is defined, and thus the return
>> value is the band'.
>>
>> By definition, the EOF signal needs to be something that can't be
>> mistaken for a transmitted character value, or it isn't reliable,
>> in band or out.  Many communication protocols send data in octets,
>> and use special encoding to mark 'protocol' items in-band (which
>> may require tweaking normal data that might look like these
>> items.)  An out of band method would be to use something outside
>> of the data packets to transfer the control information.
>
> I've been surprised by the vehemance, for lack of a better word,
> in the responses to my comments.  I don't see why people feel
> they have to be so emphatic.  Let me see if I can get the
> conversation into a cooler climate.
>
> First, I have done network programming, and know about channels
> and out-of-band messages and out-of-band signalling in that
> context.  I agree that what other people have described is normal
> usage in that context.  I don't think there is anything wrong
> with using the terms in that sense, whether one is talking about
> communication channels or something else.
>
> At the same time, there are other usages in different contexts,
> and there is equally nothing wrong with using the terms in
> those senses.  Yes, the two meanings are different;  these
> terms do not have a single technical definition.  Some groups
> of people may expect one particular sense or another, depending
> on their background, but that doesn't mean one sense is right
> and another is wrong, only that their expectations may not match
> how the terms are being used.
>
> In your explanation, you liken the 'int' type to a communication
> channel.  I understand that metaphor, and there is nothing wrong
> with it.  However other metaphors are possible.  In the analogy
> I gave (but not included above) in the post being responded to,
> the int type is more like the wire, or medium, of a phone line
> carrying both kinds of signals.  There is a single medium,
> whether a wire or radio transmission or an int type, that
> carries two different kinds of signals.  In this metaphor the
> ranges of integer values correspond to frequency ranges of
> radio transmissions or of electrical signals on a telephone
> wire.  Seen from that perspective what constitutes an in-band
> signal is different than what it is under the channel metaphor.
>
> What's really surprising to me is the insistence that the channel
> metaphor is the only metaphor possible (or maybe the only
> sensible one, or some variation along those lines).  It's hard to
> understand what these kinds of comments are meant to communicate.
> That many or most programmers would understand the terms
> differently than how I used them?  I'm okay with that statement.
> That how I'm using the terms is stupid?  Well that may be true
> but I see no point in arguing the matter.  That there is only
> one way that anyone but me uses or understands these terms?
> There I have to say that seems factually incorrect, even based
> just on comments in the newsgroup.  So I guess my question is,
> what is it that people are trying to communicate?
>
> My goal here is only to convey what I mean so people understand
> what I'm saying.  There seems to be no point in arguing about
> which usage is the right one, as the terms are used in different
> ways and have no intrinsic single meaning.
>
> I sincerely hope the comments above will help the discussion.
>

My concern with your terminology is that it seems very unuseful. What is 
the purpose of having a term 'out of band' if it doesn't have a useful 
alternative of 'in band'. If the -1 return is out-of-band, then ANY 
special return value by a function for error return is also out-of-band, 
and I can't see what would be considered an 'in-band' error return.

Language, especially technical labeling, is important to communicate. 
Intentionally misusing it is a good way to make yourself misunderstood.

[toc] | [prev] | [next] | [standalone]

#71931

Richard Damon <Richard@damon-family.org> wrote:
> On 10/4/15 10:03 PM, Tim Rentsch wrote:

(snip)
>> First, I have done network programming, and know about channels
>> and out-of-band messages and out-of-band signalling in that
>> context.  I agree that what other people have described is normal
>> usage in that context.  I don't think there is anything wrong
>> with using the terms in that sense, whether one is talking about
>> communication channels or something else.

(snip)

> My concern with your terminology is that it seems very unuseful. What is 
> the purpose of having a term 'out of band' if it doesn't have a useful 
> alternative of 'in band'. If the -1 return is out-of-band, then ANY 
> special return value by a function for error return is also out-of-band, 
> and I can't see what would be considered an 'in-band' error return.

No. It depends on the allowable return values that aren't the
error return signal.

In the case of getchar() with char as unsigned, no valid char
value is -1.  (I am not sure what systems with sizeof(int) equal
to sizeof(char) do.)

If valid char values are 0 to 255, -1 is out of band.

If char values are, for example, -128 to 127 then -1 is in band.

For an int min or max function, on systems were all possible values
of int are legal, there are no out of band return values. 

Unix file descriptors are small non-negative integers. Negative
values and very large positive integers would be out of band.
(I assume that no system allows more than INT_MAX files to
be open at once.)

There is a small problem that what is out of band at one time
might be in band later. Note, for example, that happens for 
getchar() when the character set expands far enough.
 
> Language, especially technical labeling, is important to communicate. 
> Intentionally misusing it is a good way to make yourself misunderstood.

-- glen

[toc] | [prev] | [next] | [standalone]

#71939

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
[...]
> In the case of getchar() with char as unsigned, no valid char
> value is -1.  (I am not sure what systems with sizeof(int) equal
> to sizeof(char) do.)
>
> If valid char values are 0 to 255, -1 is out of band.
>
> If char values are, for example, -128 to 127 then -1 is in band.

getchar() doesn't operate on plain char values.  It returns the next
input character *as an unsigned char* converted an int.

[...]

-- 
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"

[toc] | [prev] | [next] | [standalone]

#71956

Keith Thompson <kst-u@mib.org> wrote:

(snip, I wrote)

>> In the case of getchar() with char as unsigned, no valid char
>> value is -1.  (I am not sure what systems with sizeof(int) equal
>> to sizeof(char) do.)

>> If valid char values are 0 to 255, -1 is out of band.

>> If char values are, for example, -128 to 127 then -1 is in band.
 
> getchar() doesn't operate on plain char values.  It returns the next
> input character *as an unsigned char* converted an int.

OK, so unsigned even on systems with signed char.

And what about the sizeof(char)==sizeof(int) case?

-- glen

[toc] | [prev] | [next] | [standalone]

#71989

On 10/05/2015 05:53 AM, glen herrmannsfeldt wrote:
> Keith Thompson <kst-u@mib.org> wrote:
> 
> (snip, I wrote)
> 
>>> In the case of getchar() with char as unsigned, no valid char
>>> value is -1.  (I am not sure what systems with sizeof(int) equal
>>> to sizeof(char) do.)
> 
>>> If valid char values are 0 to 255, -1 is out of band.
> 
>>> If char values are, for example, -128 to 127 then -1 is in band.
>  
>> getchar() doesn't operate on plain char values.  It returns the next
>> input character *as an unsigned char* converted an int.
> 
> OK, so unsigned even on systems with signed char.
> 
> And what about the sizeof(char)==sizeof(int) case?

The relevant issue isn't the size, but the upper limits. If UCHAR_MAX >
INT_MAX (which requires CHAR_BIT >=16, and makes it likely that
sizeof(int)==1 unless int has at least one entire padding byte), it's
possible for unsigned char values to be too big to be represented as an int.
In that case, paying attention only to the conversion rules (6.3.1.3p3),
it might seem that all you can say is "the result is
implementation-defined or an implementation-defined signal is raised)".
However, 7.21.2p3 says "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." Since all C I/O has behavior that traces back
to the behavior defined for fgetc() and fputc(), and since the behavior
of fgetc() and fputc() is defined in terms of conversions between
unsigned char and int, then if UCHAR_MAX > INT_MAX, it's necessarily the
case that a signal cannot be raised, and that the implementation-defined
result of a conversion from unsigned char to int must invert the
standard-defined conversion from int to unsigned char. In particular, if
you use fputc() to write EOF to a binary stream, the result when fgetc()
successfully reads that byte must necessarily be EOF. Therefore, it is
necessary to use ferror() and feof() to detect an error condition or
end-of-file; checking whether fgetc() returns EOF is not sufficient.

UCHAR_MAX > INT_MAX is extremely unlikely, but as far as I can tell it
wouldn't render the implementation non-conforming. It would render it
impossible to ungetc() a byte that contains (unsigned char)EOF.

[toc] | [prev] | [next] | [standalone]

#71991

On Monday, October 5, 2015 at 12:16:04 PM UTC-5, James Kuyper wrote:
> UCHAR_MAX > INT_MAX is extremely unlikely, but as far as I can tell it
> wouldn't render the implementation non-conforming. It would render it
> impossible to ungetc() a byte that contains (unsigned char)EOF.

I wouldn't call it unlikely.  I'd consider it commonplace on systems where
the smallest addressable unit of memory is 16 bits or larger (a system with
a 16-bit data bus can process many kinds of data twice as fast as a system
with an 8-bit bus, and a system with a 16-bit bus which only allows for
memory to be read/written in 16-bit chunks can be much simpler than one
which has to allow byte access, so a lot of 16-bit DSPs have, at least
historically, had 16-bit "char").

I would not be surprised if part of the reason that "char" may be either
signed or unsigned stems from the requirements that all values of type
"char" must be representable as "int", and all members of the C character
set must be represented by positive character codes.

Thus, "char" cannot be unsigned on systems where "char" and "int" are the
same size, and "char" cannot be signed on systems where "char" is 8 bits
and the target character set is e.g. EBCDIC (which uses 0xF0 through 0xF9
for digits 0-9).

[toc] | [prev] | [next] | [standalone]

#72002

supercat@casperkitty.com wrote:

(snip)

> I would not be surprised if part of the reason that "char" may be either
> signed or unsigned stems from the requirements that all values of type
> "char" must be representable as "int", and all members of the C character
> set must be represented by positive character codes.
 
> Thus, "char" cannot be unsigned on systems where "char" and "int" are the
> same size, and "char" cannot be signed on systems where "char" is 8 bits
> and the target character set is e.g. EBCDIC (which uses 0xF0 through 0xF9
> for digits 0-9).

Not only the digits, but upper and lower case letters are all 
greater than 0x80. But it only takes one character to require unsigned.

-- glen

[toc] | [prev] | [next] | [standalone]

#72001

James Kuyper <jameskuyper@verizon.net> wrote:

(snip discussion on getchar() returning -1)
(then I wrote)
>> OK, so unsigned even on systems with signed char.
 
>> And what about the sizeof(char)==sizeof(int) case?
 
> The relevant issue isn't the size, but the upper limits. If UCHAR_MAX >
> INT_MAX (which requires CHAR_BIT >=16, and makes it likely that
> sizeof(int)==1 unless int has at least one entire padding byte), it's
> possible for unsigned char values to be too big to be represented as an int.
> In that case, paying attention only to the conversion rules (6.3.1.3p3),
> it might seem that all you can say is "the result is
> implementation-defined or an implementation-defined signal is raised)".
> However, 7.21.2p3 says "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." Since all C I/O has behavior that traces back
> to the behavior defined for fgetc() and fputc(), and since the behavior
> of fgetc() and fputc() is defined in terms of conversions between
> unsigned char and int, then if UCHAR_MAX > INT_MAX, it's necessarily the
> case that a signal cannot be raised, and that the implementation-defined
> result of a conversion from unsigned char to int must invert the
> standard-defined conversion from int to unsigned char. In particular, if
> you use fputc() to write EOF to a binary stream, the result when fgetc()
> successfully reads that byte must necessarily be EOF. Therefore, it is
> necessary to use ferror() and feof() to detect an error condition or
> end-of-file; checking whether fgetc() returns EOF is not sufficient.
 
> UCHAR_MAX > INT_MAX is extremely unlikely, but as far as I can tell it
> wouldn't render the implementation non-conforming. It would render it
> impossible to ungetc() a byte that contains (unsigned char)EOF.

I pretty much never use ungetc(). 

It is fun to use when designing compilers that need one character
look ahead, though. It might be that scanf() uses it internally,
even when I don't.

I have written programs that expect fgetc() after fscanf() to
return the character after a "%d" or "%f" read. 

I more often use fgets() for reading lines from files.

It seems that UTF-32 doesn't use the 0xffffffff code point, but
on systems using UTF-32, one might try to read files full of
non-text data. 

I note that getw() also has this problem.

-- glen

[toc] | [prev] | [next] | [standalone]

#71990

On Monday, October 5, 2015 at 4:54:02 AM UTC-5, glen herrmannsfeldt wrote:
> And what about the sizeof(char)==sizeof(int) case?

On a system where both are 16 bits, reading 0xABCD from the file will yield
a result of (int)0xABCD, which would almost certainly be negative (the
Standard would allow an implementation with 16-bit integers to use any
mapping it sees fit to convert unsigned values 0x8000 to 0xFFFF to integers,
provide that it documents the mapping it uses; I would not expect any
implementation where "char" is 16 bits to define a mapping where the 65536
possible values of "unsigned char" would not yield at least 65535 different
values of "int", but nothing in the Standard would require that).

On the other hand, I would call the "EOF" return "in-band" even on systems
where received data can't have the value -1, since the appearance of the
EOF value precludes the use of the return value for its normal purpose.

If in some other "read a byte" function, reading a byte when at least one
more byte was available after it would yield 0x00-0xFF, and reading a byte
when no more data existed would yield 0x100-0x1FF, I would consider that
end-of-file indication to be out-of-band, since the end-of-file indication
would be independent from the data to be received.  Likewise, if the
function used an "EOF" bit, but had some defined means of indicating what
byte of data should be supplied when nothing more was available from the
file (in which case that part of the return value would still be returning
"data" even though the data in question didn't come from the file).

[toc] | [prev] | [next] | [standalone]

#71997

glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip, I wrote)
>
>>> In the case of getchar() with char as unsigned, no valid char
>>> value is -1.  (I am not sure what systems with sizeof(int) equal
>>> to sizeof(char) do.)
>
>>> If valid char values are 0 to 255, -1 is out of band.
>
>>> If char values are, for example, -128 to 127 then -1 is in band.
>  
>> getchar() doesn't operate on plain char values.  It returns the next
>> input character *as an unsigned char* converted an int.
>
> OK, so unsigned even on systems with signed char.

That would be clearer as:

    OK, so unsigned even on systems where plain char is signed.

since "signed char" is a distinct type.  But yes.

> And what about the sizeof(char)==sizeof(int) case?

In that case, if getchar() returns EOF you can't tell whether it
indicates that there are no more characters to be read, or whether it
actually read a character with that value (0xFFFF if CHAR_BIT==16, for
example).  You can call feof() and ferror() after getchar() returns EOF
to distinguish those cases.

Another problem is that the input character is treated as an unsigned
char and converted to signed int.  If unsigned char fits in the range of
signed int, that's not a problem.  But if not, and if you read a
character with a value exceeding INT_MAX, then the conversion to int
yields an implementation-defined result or raises an
implementation-defined signal.  Probably the conversion will do the
typical 2's-complement wraparound, but if it doesn't, hilarity ensues.

In practice, I don't think there are any hosted implementations with
UCHAR_MAX > INT_MAX, and freestanding implementations aren't required to
provide getchar() and friends.


-- 
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"

[toc] | [prev] | [next] | [standalone]

#72000

On Monday, October 5, 2015 at 1:59:45 PM UTC-5, Keith Thompson wrote:
> Another problem is that the input character is treated as an unsigned
> char and converted to signed int.  If unsigned char fits in the range of
> signed int, that's not a problem.  But if not, and if you read a
> character with a value exceeding INT_MAX, then the conversion to int
> yields an implementation-defined result or raises an
> implementation-defined signal.  Probably the conversion will do the
> typical 2's-complement wraparound, but if it doesn't, hilarity ensues.

If  James Kuyper's citation of 7.21.2p3 is accurate, I would think that any
platform where UCHAR_MAX > INT_MAX would be required to use an "int" type
which supported a value which behaved as -INT_MAX-1.  I think it might be
possible for a ones'-complement or sign-magnitude implementation to meet
the requirement if the bit pattern for "negative zero" was never generated
by any calculations within the range of "int" but was produced by trying to
convert "INT_MAX+1U" to "int", and if converting that value to "unsigned"
yielded "INT_MAX+1U".

[toc] | [prev] | [next] | [standalone]

Page 2 of 4 — ← Prev page 1 [2] 3 4  Next page →

Back to top | Article view | comp.lang.c

csiph-web