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

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

Reading beyond the end of file

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

Contents

  Reading beyond the end of file janus <emekamicro@gmail.com> - 2015-08-17 16:24 -0700
    Re: Reading beyond the end of file Bartc <bc@freeuk.com> - 2015-08-18 00:53 +0100
      Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-08-17 18:44 -0700
        Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-06 14:41 -0700
          Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-09-06 17:09 -0700
            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
    Re: Reading beyond the end of file James Kuyper <jameskuyper@verizon.net> - 2015-08-17 20:10 -0400
      Re: Reading beyond the end of file janus <emekamicro@gmail.com> - 2015-08-18 00:54 -0700
        Re: Reading beyond the end of file janus <emekamicro@gmail.com> - 2015-08-18 01:43 -0700
        Re: Reading beyond the end of file James Kuyper <jameskuyper@verizon.net> - 2015-08-18 10:18 -0400
        Re: Reading beyond the end of file Barry Schwarz <schwarzb@dqel.com> - 2015-08-18 09:18 -0700
          Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-08-18 11:17 -0700
            Re: Reading beyond the end of file Barry Schwarz <schwarzb@dqel.com> - 2015-08-18 13:24 -0700

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

#71571

Tim Rentsch <txr@alumni.caltech.edu> writes:

> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>
>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>
>>>> https://en.wikipedia.org/wiki/Out-of-band
>>>
>>> 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.  There doesn't need
>>> to be an alternate mechanism;  the signal can just be in a
>>> different frequency range.
>>
>> That would be a *really* idiosyncratic view.
>
> Personally I don't think it is that odd.  However as long as
> you understand what I'm getting at and agree that what I'm
> saying is consistent with the quoted excerpt, I think we can
> leave it at that.

It's your interpretation of the quoted excerpt that is really
idiosyncratic.  It requires pushing the analogy of a frequency band in a
direction virtually nobody but you is going to accept, which means
you're going to be using "in band" and "out of band" to mean things
other than what pretty much anyone you're talking to will.

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

#71910

Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>
>>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>>
>>>> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
>>>>
>>>>> https://en.wikipedia.org/wiki/Out-of-band
>>>>
>>>> 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.  There doesn't need
>>>> to be an alternate mechanism;  the signal can just be in a
>>>> different frequency range.
>>>
>>> That would be a *really* idiosyncratic view.
>>
>> Personally I don't think it is that odd.  However as long as
>> you understand what I'm getting at and agree that what I'm
>> saying is consistent with the quoted excerpt, I think we can
>> leave it at that.
>
> It's your interpretation of the quoted excerpt that is
> really idiosyncratic.  It requires pushing the analogy
> of a frequency band in a direction virtually nobody but
> you is going to accept, which means you're going to be
> using "in band" and "out of band" to mean things other
> than what pretty much anyone you're talking to will.

That doesn't match my experience.  This term is one I
have used many times over the years, in the sense I
have described it, with lots of different people, and
I can't remember anyone misunderstanding it or being
surprised by it before the discussion here.  But maybe
I'm used to talking to people who have a broader
background in the other sciences than most developers.

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

#71928

Tim Rentsch <txr@alumni.caltech.edu> wrote:
> Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:

(snip on in-band)

>> It's your interpretation of the quoted excerpt that is
>> really idiosyncratic.  

(snip)

> That doesn't match my experience.  This term is one I
> have used many times over the years, in the sense I
> have described it, with lots of different people, and
> I can't remember anyone misunderstanding it or being
> surprised by it before the discussion here.  But maybe
> I'm used to talking to people who have a broader
> background in the other sciences than most developers.

For some years, the US (and maybe others) telephone system
used in-band signaling. That is, tones within the voice
bandwidth were used to control trunk line switching. 
Most likely it would have leaked anyway, but the signal
system was published in the Bell system journals.

Using in-band signaling made the system easier to design,
as the signals follow through any switching system.  Much
of the system used frequency division multiplexing, where
signals were modulated (mixed) to different frequencies,
and sent down a cable or microwave link, then demodulated
(mixed down) at the other end. 

But in-band signaling also allows for 
unauthorized users to use such signals and bypass many
security and accounting systems.  The story of blue boxes
has been told many times, so for anyone interested, there
are books out that tell the story.

But in general, security is a big problem with in-band
singaling. It is too easy for unauthorized signals to 
get into places where they aren't supposed to go.

So, for example, using '\n' to signal end of line is in-band,
assuming that one believes that they should be able to use
all the values of a char variable. 

-- glen

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

#71604

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

Richard

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

#71622

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.

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

#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]

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

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

csiph-web