Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #67655 > unrolled thread
| Started by | janus <emekamicro@gmail.com> |
|---|---|
| First post | 2015-08-17 16:24 -0700 |
| Last post | 2015-08-18 13:24 -0700 |
| Articles | 20 on this page of 75 — 14 participants |
Back to article view | Back to comp.lang.c
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 1 of 4 [1] 2 3 4 Next page →
| From | janus <emekamicro@gmail.com> |
|---|---|
| Date | 2015-08-17 16:24 -0700 |
| Subject | Reading beyond the end of file |
| Message-ID | <b62ba036-de31-4f37-aaad-3d1372d40d3f@googlegroups.com> |
Hello All,
I am not getting the expected result from the below code whenever I change '\0' to EOF. I noticed that the below will read pass the end of file. What is it that I am doing wrong? Could someone help me out?
static tokens* tokenize(char* source)
{
int ch;
tokens *ntoken;
char* ctemp;
//printf("%s\n",source);
while((ch = *source++) != '\0')
{
while(isspace(ch))
{
ch = *source;
source++;
}
if(ch == '\0')
{
printf("Dont break my heart\n ");
break;
}
switch(ch)
{
case '+':
{
ntoken = tokenmem();
ntoken->type = obplus;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "+", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '-':
{
ntoken = tokenmem();
ntoken->type = obminus;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "-", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '#':
{
ntoken = tokenmem();
ntoken->type = obneg;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "#", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '&':
{
ntoken = tokenmem();
ntoken->type = oband;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "&", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '=':
{
ntoken = tokenmem();
ntoken->type = eql;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "=", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '*':
{
ntoken = tokenmem();
ntoken->type = obtimes;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "*", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '<':
{
ntoken = tokenmem();
if(*source == '=')
{
ntoken->type = obleq;
ctemp = (char *)malloc(sizeof(char)*3);
strncpy(ctemp, "<=", 2);
ctemp[2] = '\0';
ntoken->txt = ctemp;
source++;
}
else
{
ntoken->type = oblss;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "<", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
}
addtokentolist(ntoken);
break;
}
case '>':
{
ntoken = tokenmem();
if(*source == '=')
{
ntoken->type = obgeq;
ctemp = (char *)malloc(sizeof(char)*3);
strncpy(ctemp, ">=", 2);
ctemp[2] = '\0';
ntoken->txt = ctemp;
source++;
}
else
{
ntoken->type = obgtr;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, ">", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
}
addtokentolist(ntoken);
break;
}
case ':':
{
ntoken = tokenmem();
ntoken->type = obcolon;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, ":", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case ';':
{
ntoken = tokenmem();
ntoken->type = obsemicolon;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, ";", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '.':
{
ntoken = tokenmem();
ntoken->type = period;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, ".", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
//return hlist;
break;
}
case ']':
{
ntoken = tokenmem();
ntoken->type = rbrak;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "]", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '[':
{
ntoken = tokenmem();
ntoken->type = lbrak;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "[", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '(':
{
if (*source == '*')
{
source++;
while (*source == ')')
{
source++;
}
}
else
{
ntoken = tokenmem();
ntoken->type = lparen;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "(", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
}
break;
}
case ')':
{
ntoken = tokenmem();
ntoken->type = rparen;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, ")", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
addtokentolist(ntoken);
break;
}
case '~':
{
ntoken = tokenmem();
ntoken->type = obnot;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, "~", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
break;
}
case ',':
{
ntoken = tokenmem();
ntoken->type = obcomma;
ctemp = (char *)malloc(sizeof(char)*2);
strncpy(ctemp, ",", 1);
ctemp[1] = '\0';
ntoken->txt = ctemp;
break;
}
default:
{
if(isdigit(ch))
{
int tnum = 0;
tnum = tnum * 10 + ch - '0';
//source++ ;
ch = *source;
while(isdigit(ch))
{
tnum = tnum * 10 + ch - '0';
source++;
ch = *source;
}
ntoken = tokenmem();
ntoken->type = obnum;
ntoken->inttoken = tnum;
addtokentolist(ntoken);
}
else if (isalpha(ch))
{
char* ntemp = source - 1;
int cstr = 1;
//source++;
int cstate = 0;
int i ;
//source++;
ch = *source;
while(isalnum(ch))
{
source++;
ch = *source;
cstr++;
}
if(cstr > IdLen)
{
cstr = IdLen;
}
ctemp = (char *)malloc(sizeof(char)*(cstr + 1));
strncpy(ctemp, ntemp, cstr);
ctemp[cstr] = '\0';
printf("%s string length (chars) ::%d\n", ctemp, cstr);
ntoken = tokenmem();
for(i = 0; i < kwlen; i++ )
{
if(strcmp(keytab[i].kw, ctemp) == 0)
{
ntoken->type = keytab[i].ksym;
ntoken->txt = ctemp;
cstate = 1;
break;
}
}
if(!cstate)
{
ntoken->type = ident;
ntoken->txt = ctemp;
}
addtokentolist(ntoken);
}
break;
}
}
}
//char* vv = source - 300;
//printf("\nMy last card %s\n", vv);
return hlist;
}
Regards, \Janus
[toc] | [next] | [standalone]
| From | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-18 00:53 +0100 |
| Message-ID | <mqts2p$js0$1@dont-email.me> |
| In reply to | #67655 |
On 18/08/2015 00:24, janus wrote:
> Hello All,
>
> I am not getting the expected result from the below code whenever I change '\0' to EOF. I noticed that the below will read pass the end of file. What is it that I am doing wrong? Could someone help me out?
What's the input format? Is it a string terminated with \0, or with EOF?
Note that EOF, normally set to -1, might not be properly representable
when the 'char' type is unsigned (it will be 255). It might work, but I
think 0 is a better terminator if it's going to be a char value.
> static tokens* tokenize(char* source)
> {
> int ch;
> tokens *ntoken;
> char* ctemp;
> //printf("%s\n",source);
> while((ch = *source++) != '\0')
It probably doesn't matter, as ch is checked, but you allow source to
point past the 0/EOF character. I wouldn't advance source past the
terminator, just in case some code then tries to use *source.
Perhaps temporarily use a function to obtain the next character from
source (a bit fiddly, it needs to take a char** parameter so that it can
update the source pointer within the function), then it is easier to
stop it going past the EOF point.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 18:44 -0700 |
| Message-ID | <lnk2st4bg0.fsf@kst-u.example.com> |
| In reply to | #67659 |
Bartc <bc@freeuk.com> writes:
> On 18/08/2015 00:24, janus wrote:
>> I am not getting the expected result from the below code whenever I
>> change '\0' to EOF. I noticed that the below will read pass the end
>> of file. What is it that I am doing wrong? Could someone help me out?
>
> What's the input format? Is it a string terminated with \0, or with EOF?
>
> Note that EOF, normally set to -1, might not be properly representable
> when the 'char' type is unsigned (it will be 255). It might work, but I
> think 0 is a better terminator if it's going to be a char value.
EOF is the value returned by getchar() and related functions when they
encounter an end-of-file condition.
(Strictly speaking, it's a macro that expands to a constant expression
whose value is as I described.)
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. getchar(), for example, returns an input
character interpreted as an unsigned char (and therefore >= 0) *or* the
value EOF (guaranteed to be negative). If the input happens to have a
value of -1 when interpreted as a signed char, getchar() will return 255
(assuming CHAR_BIT==8).
[...]
C strings are by definition terminated by a `'\0'` character.
--
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]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-06 14:41 -0700 |
| Message-ID | <kfnbndfql81.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #67667 |
Keith Thompson <kst-u@mib.org> writes: > Bartc <bc@freeuk.com> writes: >> On 18/08/2015 00:24, janus wrote: >>> I am not getting the expected result from the below code whenever I >>> change '\0' to EOF. I noticed that the below will read pass the end >>> of file. What is it that I am doing wrong? Could someone help me out? >> >> What's the input format? Is it a string terminated with \0, or with EOF? >> >> Note that EOF, normally set to -1, might not be properly representable >> when the 'char' type is unsigned (it will be 255). It might work, but I >> think 0 is a better terminator if it's going to be a char value. > > EOF is the value returned by getchar() and related functions when they > encounter an end-of-file condition. > > (Strictly speaking, it's a macro that expands to a constant expression > whose value is as I described.) > > 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.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-09-06 17:09 -0700 |
| Message-ID | <lnsi6rt7id.fsf@kst-u.example.com> |
| In reply to | #69682 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Bartc <bc@freeuk.com> writes:
>>> On 18/08/2015 00:24, janus wrote:
>>>> I am not getting the expected result from the below code whenever I
>>>> change '\0' to EOF. I noticed that the below will read pass the end
>>>> of file. What is it that I am doing wrong? Could someone help me out?
>>>
>>> What's the input format? Is it a string terminated with \0, or with EOF?
>>>
>>> Note that EOF, normally set to -1, might not be properly representable
>>> when the 'char' type is unsigned (it will be 255). It might work, but I
>>> think 0 is a better terminator if it's going to be a char value.
>>
>> EOF is the value returned by getchar() and related functions when they
>> encounter an end-of-file condition.
>>
>> (Strictly speaking, it's a macro that expands to a constant expression
>> whose value is as I described.)
>>
>> 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.
--
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]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-11 10:06 -0700 |
| Message-ID | <kfnmvwskhqm.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #69700 |
Keith Thompson <kst-u@mib.org> writes: > Tim Rentsch <txr@alumni.caltech.edu> writes: >> Keith Thompson <kst-u@mib.org> writes: >>> Bartc <bc@freeuk.com> writes: >>>> On 18/08/2015 00:24, janus wrote: >>>>> I am not getting the expected result from the below code whenever I >>>>> change '\0' to EOF. I noticed that the below will read pass the end >>>>> of file. What is it that I am doing wrong? Could someone help me out? >>>> >>>> What's the input format? Is it a string terminated with \0, or with EOF? >>>> >>>> Note that EOF, normally set to -1, might not be properly representable >>>> when the 'char' type is unsigned (it will be 255). It might work, but I >>>> think 0 is a better terminator if it's going to be a char value. >>> >>> EOF is the value returned by getchar() and related functions when they >>> encounter an end-of-file condition. >>> >>> (Strictly speaking, it's a macro that expands to a constant expression >>> whose value is as I described.) >>> >>> 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.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-09-11 12:41 -0700 |
| Message-ID | <kl96vahppqjmfsctfa6r529k5brvqdr0hn@4ax.com> |
| In reply to | #70255 |
On Fri, 11 Sep 2015 10:06:57 -0700, Tim Rentsch <txr@alumni.caltech.edu> wrote: >Keith Thompson <kst-u@mib.org> writes: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: >>> Keith Thompson <kst-u@mib.org> writes: >>>> Bartc <bc@freeuk.com> writes: >>>>> On 18/08/2015 00:24, janus wrote: >>>>>> I am not getting the expected result from the below code whenever I >>>>>> change '\0' to EOF. I noticed that the below will read pass the end >>>>>> of file. What is it that I am doing wrong? Could someone help me out? >>>>> >>>>> What's the input format? Is it a string terminated with \0, or with EOF? >>>>> >>>>> Note that EOF, normally set to -1, might not be properly representable >>>>> when the 'char' type is unsigned (it will be 255). It might work, but I >>>>> think 0 is a better terminator if it's going to be a char value. >>>> >>>> EOF is the value returned by getchar() and related functions when they >>>> encounter an end-of-file condition. >>>> >>>> (Strictly speaking, it's a macro that expands to a constant expression >>>> whose value is as I described.) >>>> >>>> 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. In signal theory there is a term called "the information channel". A stream in C can be considered to be such a channel. The channel conveys symbols (the information) and some symbols are reserved for special signaling purposes. EOF, NUL, XON, XOF, are examples of in-band signals under the concept of in-band signaling. An out-of-band signal in this model can be extra hardware, another channel of information to control the primary channel, or in C, an error return from a function that uses another variable to convey the state of the channel separate from the variable containing the information channel symbols. getchar() is an in-band signaling channel that also signals out-of-band via functions like feof or ferror. It is also an example of a very poorly designed function that shows it's legacy of being a TTY handling function.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-26 14:24 -0700 |
| Message-ID | <kfnmvw8g9hl.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #70272 |
Geoff <geoff@invalid.invalid> writes: > On Fri, 11 Sep 2015 10:06:57 -0700, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > >> Keith Thompson <kst-u@mib.org> writes: >> >>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>> Keith Thompson <kst-u@mib.org> writes: >>>>> Bartc <bc@freeuk.com> writes: >>>>>> On 18/08/2015 00:24, janus wrote: >>>>>>> I am not getting the expected result from the below code whenever I >>>>>>> change '\0' to EOF. I noticed that the below will read pass the end >>>>>>> of file. What is it that I am doing wrong? Could someone help me out? >>>>>> >>>>>> What's the input format? Is it a string terminated with \0, or with EOF? >>>>>> >>>>>> Note that EOF, normally set to -1, might not be properly representable >>>>>> when the 'char' type is unsigned (it will be 255). It might work, but I >>>>>> think 0 is a better terminator if it's going to be a char value. >>>>> >>>>> EOF is the value returned by getchar() and related functions when they >>>>> encounter an end-of-file condition. >>>>> >>>>> (Strictly speaking, it's a macro that expands to a constant expression >>>>> whose value is as I described.) >>>>> >>>>> 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. > > In signal theory there is a term called "the information channel". > A stream in C can be considered to be such a channel. [snip > elaboration] It can be. But one could instead consider the channel to occupy the "frequency band" that is just the set of values corresponding to unsigned char values, all of which are non-negative. Under that view the value EOF, which is negative, is outside the normal "frequency band" and thus would constitute an out-of-band signal.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-09-26 21:49 -0700 |
| Message-ID | <thse0bpbg775b875odbaqmulobpj6k5q4n@4ax.com> |
| In reply to | #71228 |
On Sat, 26 Sep 2015 14:24:06 -0700, Tim Rentsch <txr@alumni.caltech.edu> wrote: >Geoff <geoff@invalid.invalid> writes: > >> On Fri, 11 Sep 2015 10:06:57 -0700, Tim Rentsch >> <txr@alumni.caltech.edu> wrote: >> >>> Keith Thompson <kst-u@mib.org> writes: >>> >>>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>>> Keith Thompson <kst-u@mib.org> writes: >>>>>> Bartc <bc@freeuk.com> writes: >>>>>>> On 18/08/2015 00:24, janus wrote: >>>>>>>> I am not getting the expected result from the below code whenever I >>>>>>>> change '\0' to EOF. I noticed that the below will read pass the end >>>>>>>> of file. What is it that I am doing wrong? Could someone help me out? >>>>>>> >>>>>>> What's the input format? Is it a string terminated with \0, or with EOF? >>>>>>> >>>>>>> Note that EOF, normally set to -1, might not be properly representable >>>>>>> when the 'char' type is unsigned (it will be 255). It might work, but I >>>>>>> think 0 is a better terminator if it's going to be a char value. >>>>>> >>>>>> EOF is the value returned by getchar() and related functions when they >>>>>> encounter an end-of-file condition. >>>>>> >>>>>> (Strictly speaking, it's a macro that expands to a constant expression >>>>>> whose value is as I described.) >>>>>> >>>>>> 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. >> >> In signal theory there is a term called "the information channel". >> A stream in C can be considered to be such a channel. [snip >> elaboration] > >It can be. But one could instead consider the channel to occupy the >"frequency band" that is just the set of values corresponding to >unsigned char values, all of which are non-negative. Under that >view the value EOF, which is negative, is outside the normal >"frequency band" and thus would constitute an out-of-band >signal. Your definition is flawed and doesn't correspond to the acceptable usage in the communications discipline. The channel is that through which the symbols flow. The channel doesn't distinguish between symbols, it only conveys them. The return value from the getchar function is "the channel" and any symbols transmitted through it are in-band with respect to that channel. The band of the channel is the range of values of type int. Even though you might coerce the definition of a band to constrain it to some small segment of int, the channel itself doesn't constrain the symbols themselves and EOF is a valid channel symbol and delivered in-band.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-01 13:57 -0700 |
| Message-ID | <kfnfv1u9uij.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71255 |
Geoff <geoff@invalid.invalid> writes: > On Sat, 26 Sep 2015 14:24:06 -0700, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > >> Geoff <geoff@invalid.invalid> writes: >> >>> On Fri, 11 Sep 2015 10:06:57 -0700, Tim Rentsch >>> <txr@alumni.caltech.edu> wrote: >>> >>>> Keith Thompson <kst-u@mib.org> writes: >>>> >>>>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>>>> Keith Thompson <kst-u@mib.org> writes: >>>>>>> Bartc <bc@freeuk.com> writes: >>>>>>>> On 18/08/2015 00:24, janus wrote: >>>>>>>>> I am not getting the expected result from the below code whenever I >>>>>>>>> change '\0' to EOF. I noticed that the below will read pass the end >>>>>>>>> of file. What is it that I am doing wrong? Could someone help me out? >>>>>>>> >>>>>>>> What's the input format? Is it a string terminated with \0, or with EOF? >>>>>>>> >>>>>>>> Note that EOF, normally set to -1, might not be properly representable >>>>>>>> when the 'char' type is unsigned (it will be 255). It might work, but I >>>>>>>> think 0 is a better terminator if it's going to be a char value. >>>>>>> >>>>>>> EOF is the value returned by getchar() and related functions when they >>>>>>> encounter an end-of-file condition. >>>>>>> >>>>>>> (Strictly speaking, it's a macro that expands to a constant expression >>>>>>> whose value is as I described.) >>>>>>> >>>>>>> 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. >>> >>> In signal theory there is a term called "the information channel". >>> A stream in C can be considered to be such a channel. [snip >>> elaboration] >> >> It can be. But one could instead consider the channel to occupy the >> "frequency band" that is just the set of values corresponding to >> unsigned char values, all of which are non-negative. Under that >> view the value EOF, which is negative, is outside the normal >> "frequency band" and thus would constitute an out-of-band >> signal. > > Your definition is flawed and doesn't correspond to the acceptable > usage in the communications discipline. [snip elaboration] My view is consistent with the original usage, and is an understandable and acceptable use of the term to people who understand the term and who also understand programming. If you think otherwise, I respectfully suggest that your own understanding is not as thorough as it could be.
[toc] | [prev] | [next] | [standalone]
| From | Geoff <geoff@invalid.invalid> |
|---|---|
| Date | 2015-10-01 17:22 -0700 |
| Message-ID | <jdjr0b986h3fqgd921dhpkt3b2a4hmenom@4ax.com> |
| In reply to | #71569 |
On Thu, 01 Oct 2015 13:57:40 -0700, Tim Rentsch <txr@alumni.caltech.edu> wrote: >Geoff <geoff@invalid.invalid> writes: > >> On Sat, 26 Sep 2015 14:24:06 -0700, Tim Rentsch >> <txr@alumni.caltech.edu> wrote: >> >>> Geoff <geoff@invalid.invalid> writes: >>> >>>> On Fri, 11 Sep 2015 10:06:57 -0700, Tim Rentsch >>>> <txr@alumni.caltech.edu> wrote: >>>> >>>>> Keith Thompson <kst-u@mib.org> writes: >>>>> >>>>>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>>>>> Keith Thompson <kst-u@mib.org> writes: >>>>>>>> Bartc <bc@freeuk.com> writes: >>>>>>>>> On 18/08/2015 00:24, janus wrote: >>>>>>>>>> I am not getting the expected result from the below code whenever I >>>>>>>>>> change '\0' to EOF. I noticed that the below will read pass the end >>>>>>>>>> of file. What is it that I am doing wrong? Could someone help me out? >>>>>>>>> >>>>>>>>> What's the input format? Is it a string terminated with \0, or with EOF? >>>>>>>>> >>>>>>>>> Note that EOF, normally set to -1, might not be properly representable >>>>>>>>> when the 'char' type is unsigned (it will be 255). It might work, but I >>>>>>>>> think 0 is a better terminator if it's going to be a char value. >>>>>>>> >>>>>>>> EOF is the value returned by getchar() and related functions when they >>>>>>>> encounter an end-of-file condition. >>>>>>>> >>>>>>>> (Strictly speaking, it's a macro that expands to a constant expression >>>>>>>> whose value is as I described.) >>>>>>>> >>>>>>>> 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. >>>> >>>> In signal theory there is a term called "the information channel". >>>> A stream in C can be considered to be such a channel. [snip >>>> elaboration] >>> >>> It can be. But one could instead consider the channel to occupy the >>> "frequency band" that is just the set of values corresponding to >>> unsigned char values, all of which are non-negative. Under that >>> view the value EOF, which is negative, is outside the normal >>> "frequency band" and thus would constitute an out-of-band >>> signal. >> >> Your definition is flawed and doesn't correspond to the acceptable >> usage in the communications discipline. [snip elaboration] > >My view is consistent with the original usage, [snip ad hominem] That's your opinion but it is quite wrong and I can see it is pointless to discuss it further.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-10-02 13:05 +0000 |
| Message-ID | <560e80ee.14831468@news.xs4all.nl> |
| In reply to | #71581 |
Geoff <geoff@invalid.invalid> wrote: > [snip ad hominem] ...but nothing else. Furrfu. Richard
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-04 17:56 -0700 |
| Message-ID | <kfnwpv25e1c.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71581 |
Geoff <geoff@invalid.invalid> writes: > On Thu, 01 Oct 2015 13:57:40 -0700, Tim Rentsch > <txr@alumni.caltech.edu> wrote: > >> Geoff <geoff@invalid.invalid> writes: >> >>> On Sat, 26 Sep 2015 14:24:06 -0700, Tim Rentsch >>> <txr@alumni.caltech.edu> wrote: >>> >>>> Geoff <geoff@invalid.invalid> writes: >>>> >>>>> On Fri, 11 Sep 2015 10:06:57 -0700, Tim Rentsch >>>>> <txr@alumni.caltech.edu> wrote: >>>>> >>>>>> Keith Thompson <kst-u@mib.org> writes: >>>>>> >>>>>>> Tim Rentsch <txr@alumni.caltech.edu> writes: >>>>>>>> Keith Thompson <kst-u@mib.org> writes: >>>>>>>>> Bartc <bc@freeuk.com> writes: >>>>>>>>>> On 18/08/2015 00:24, janus wrote: >>>>>>>>>>> I am not getting the expected result from the below code whenever I >>>>>>>>>>> change '\0' to EOF. I noticed that the below will read pass the end >>>>>>>>>>> of file. What is it that I am doing wrong? Could someone help me out? >>>>>>>>>> >>>>>>>>>> What's the input format? Is it a string terminated with \0, or with EOF? >>>>>>>>>> >>>>>>>>>> Note that EOF, normally set to -1, might not be properly representable >>>>>>>>>> when the 'char' type is unsigned (it will be 255). It might work, but I >>>>>>>>>> think 0 is a better terminator if it's going to be a char value. >>>>>>>>> >>>>>>>>> EOF is the value returned by getchar() and related functions when they >>>>>>>>> encounter an end-of-file condition. >>>>>>>>> >>>>>>>>> (Strictly speaking, it's a macro that expands to a constant expression >>>>>>>>> whose value is as I described.) >>>>>>>>> >>>>>>>>> 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. >>>>> >>>>> In signal theory there is a term called "the information channel". >>>>> A stream in C can be considered to be such a channel. [snip >>>>> elaboration] >>>> >>>> It can be. But one could instead consider the channel to occupy the >>>> "frequency band" that is just the set of values corresponding to >>>> unsigned char values, all of which are non-negative. Under that >>>> view the value EOF, which is negative, is outside the normal >>>> "frequency band" and thus would constitute an out-of-band >>>> signal. >>> >>> Your definition is flawed and doesn't correspond to the acceptable >>> usage in the communications discipline. [snip elaboration] >> >> My view is consistent with the original usage, > > [snip ad hominem] > > That's your opinion but it is quite wrong and I can see it is > pointless to discuss it further. I phrased my disagreement as politely as I could. I'm sorry if you found that offensive.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-09-11 13:55 -0600 |
| Message-ID | <1btwr0ras3.fsf@pfeifferfamily.net> |
| In reply to | #70255 |
Tim Rentsch <txr@alumni.caltech.edu> writes: > > 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. As I understand the term from networking, an out-of-band indication would be some alternate mechanism you would use to detect EOF, other than a call to getchar(). Looking at wikipedia's disambiguation page, all the uses they give match this understanding. https://en.wikipedia.org/wiki/Out-of-band
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-09-26 14:14 -0700 |
| Message-ID | <kfnr3lkg9ww.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #70274 |
Joe Pfeiffer <pfeiffer@cs.nmsu.edu> writes:
> Tim Rentsch <txr@alumni.caltech.edu> writes:
>
>> 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.
>
> As I understand the term from networking, an out-of-band indication
> would be some alternate mechanism you would use to detect EOF, other
> than a call to getchar(). Looking at wikipedia's disambiguation page,
> all the uses they give match this understanding.
>
> 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.
[toc] | [prev] | [next] | [standalone]
| From | Siri Cruz <chine.bleu@yahoo.com> |
|---|---|
| Date | 2015-09-26 14:43 -0700 |
| Message-ID | <chine.bleu-96F232.14435126092015@88-209-239-213.giganet.hu> |
| In reply to | #71227 |
> > As I understand the term from networking, an out-of-band indication > > would be some alternate mechanism you would use to detect EOF, other > > than a call to getchar(). Looking at wikipedia's disambiguation page, > > all the uses they give match this understanding. > > > > 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. In band refers to the sequential transmission of octets/byte/chars/glumphs. The sender generates a stream of glumphs and expects the operating systems, network, everything else to queue the glumphs and present them in the same order they were generated. Out of band means the sender wants to bypass all queued glumphs and send some special glumphs as quickly as possible. For example if after accidentally transmitting a megabyte of garbage, the sender can do a BREAK or other out of band signal to say 'whoops, my bad, ignore a bunch of garbage coming your way.' Depending on the protocol an in band synchronisation glumph can be added to the queue, and the receiver discards all glumphs up to and including the synchronisation. The receiver chucks the garbage as quickly as possible and then sender and receiver are once more in sync. And EOF would be an in band signal. It signifies the end of the input stream proceeding it. In article <mqts2p$js0$1@dont-email.me>, Bartc <bc@freeuk.com> wrote: > Note that EOF, normally set to -1, might not be properly representable > when the 'char' type is unsigned (it will be 255). It might work, but I > think 0 is a better terminator if it's going to be a char value. EOF is not required to make sense as a char value. It is meaningful as an int and is distinct from every character returned as an int by getchar. You cannot convert the return from getchar to a char and then compare to EOF: you have to compare int to int exactly as returned by getchar. Also some devices do allow reading past an EOF, such as tape drives. A tape can have multiple files separated by end of file records. Depending on the OS, it might return an EOF on an end file and then continue to the next file on the tape, only getting stuck on EOF at the end of the reel. -- :-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted. 'I desire mercy, not sacrifice.' When is a Kenyan not a Kenyan? When he's a Canadian. That's People's Commissioner Siri Cruz now. Punch!
[toc] | [prev] | [next] | [standalone]
| From | Lew Pitcher <lew.pitcher@digitalfreehold.ca> |
|---|---|
| Date | 2015-09-26 17:57 -0400 |
| Message-ID | <bxENx.34167$t03.2300@fx23.iad> |
| In reply to | #71229 |
On Saturday September 26 2015 17:43, in comp.lang.c, "Siri Cruz" <chine.bleu@yahoo.com> wrote: [snip] > Also some devices do allow reading past an EOF, such as tape drives. A tape > can have multiple files separated by end of file records. Depending on the > OS, it might return an EOF on an end file and then continue to the next file > on the tape, only getting stuck on EOF at the end of the reel. It might be more correct to say that some operating environments permit reading past EOF (whether against a tape drive, or some other data stream), rather than say that some /devices/ permit reading past EOF. It is entirely possible, under some operating environments, to read past EOF on a direct-access (disk, to you) file, wait a bit for the writer of the file to catch up, and then continue reading data from the file (past the point previously "marked" with the EOF). -- Lew Pitcher "In Skills, We Trust" PGP public key available upon request
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-01 14:01 -0700 |
| Message-ID | <kfnbnci9ucq.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71229 |
Siri Cruz <chine.bleu@yahoo.com> writes: >>> As I understand the term from networking, an out-of-band indication >>> would be some alternate mechanism you would use to detect EOF, other >>> than a call to getchar(). Looking at wikipedia's disambiguation page, >>> all the uses they give match this understanding. >>> >>> 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. > > In band refers to the sequential transmission of octets/byte/chars/ > glumphs. The sender generates a stream of glumphs and expects the > operating systems, network, everything else to queue the glumphs and > present them in the same order they were generated. > > Out of band means the sender wants to bypass all queued glumphs > and send some special glumphs as quickly as possible. [snip > elaboration] I agree that is _a_ meaning. But not the only one, as I have explained in more detail in another response.
[toc] | [prev] | [next] | [standalone]
| From | Joe Pfeiffer <pfeiffer@cs.nmsu.edu> |
|---|---|
| Date | 2015-09-26 22:18 -0600 |
| Message-ID | <1b37y0wl4f.fsf@pfeifferfamily.net> |
| In reply to | #71227 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-01 12:58 -0700 |
| Message-ID | <kfnoagi9x96.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71252 |
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.
[toc] | [prev] | [next] | [standalone]
Page 1 of 4 [1] 2 3 4 Next page →
Back to top | Article view | comp.lang.c
csiph-web