Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #70255 > unrolled thread
| Started by | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| First post | 2015-09-11 10:06 -0700 |
| Last post | 2015-10-05 01:47 -0700 |
| Articles | 3 on this page of 63 — 11 participants |
Back to article view | Back to comp.lang.c
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-11 10:06 -0700
Re: Reading beyond the end of file Geoff <geoff@invalid.invalid> - 2015-09-11 12:41 -0700
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 14:24 -0700
Re: Reading beyond the end of file Geoff <geoff@invalid.invalid> - 2015-09-26 21:49 -0700
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 13:57 -0700
Re: Reading beyond the end of file Geoff <geoff@invalid.invalid> - 2015-10-01 17:22 -0700
Re: Reading beyond the end of file raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:05 +0000
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 17:56 -0700
Re: Reading beyond the end of file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-09-11 13:55 -0600
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 14:14 -0700
Re: Reading beyond the end of file Siri Cruz <chine.bleu@yahoo.com> - 2015-09-26 14:43 -0700
Re: Reading beyond the end of file Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-09-26 17:57 -0400
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 14:01 -0700
Re: Reading beyond the end of file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-09-26 22:18 -0600
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 12:58 -0700
Re: Reading beyond the end of file Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-10-01 15:08 -0600
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 18:03 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 04:02 +0000
Re: Reading beyond the end of file raltbos@xs4all.nl (Richard Bos) - 2015-10-02 13:11 +0000
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-02 09:31 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-03 16:07 -0400
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 19:06 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-09-11 14:36 -0700
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-09-26 14:05 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-09-26 18:53 -0700
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-01 13:49 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-01 20:23 -0400
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-02 06:14 +0000
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-04 19:03 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-04 22:55 -0400
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 04:27 +0000
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-04 22:21 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 09:53 +0000
Re: Reading beyond the end of file James Kuyper <jameskuyper@verizon.net> - 2015-10-05 13:15 -0400
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-05 10:25 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:30 +0000
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:27 +0000
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-05 10:17 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-05 11:59 -0700
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-05 13:44 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:58 +0000
Ones' complement subtraction supercat@casperkitty.com - 2015-10-05 15:28 -0700
Re: Ones' complement subtraction glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 02:14 +0000
Re: Ones' complement subtraction supercat@casperkitty.com - 2015-10-06 08:48 -0700
Re: Ones' complement subtraction glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 20:55 +0000
Re: Ones' complement subtraction supercat@casperkitty.com - 2015-10-06 14:41 -0700
Re: Ones' complement subtraction glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-07 00:14 +0000
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-05 15:24 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-05 21:39 +0000
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-05 15:31 -0700
Re: Reading beyond the end of file glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-10-06 03:04 +0000
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-06 08:55 -0700
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-06 11:44 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-05 23:16 -0400
Re: Reading beyond the end of file James Kuyper <jameskuyper@verizon.net> - 2015-10-06 10:29 -0400
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-06 08:56 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-06 23:13 -0400
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-06 22:01 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-07 08:43 -0700
Re: Reading beyond the end of file supercat@casperkitty.com - 2015-10-07 10:02 -0700
Re: Reading beyond the end of file Keith Thompson <kst-u@mib.org> - 2015-10-07 13:08 -0700
Re: Reading beyond the end of file Richard Damon <Richard@Damon-Family.org> - 2015-10-07 22:03 -0400
Re: Reading beyond the end of file Tim Rentsch <txr@alumni.caltech.edu> - 2015-10-05 01:47 -0700
Page 4 of 4 — ← Prev page 1 2 3 [4]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-10-07 13:08 -0700 |
| Message-ID | <lna8rujvav.fsf@kst-u.example.com> |
| In reply to | #72138 |
Keith Thompson <kst-u@mib.org> writes:
[...]
> What is a full hosted implementation, or was it a freestanding
> implementation that just happened to provide <stdio.h>?
Typo/braino: that was supposed to be "Was it ...", not "What is ...".
--
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 | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2015-10-07 22:03 -0400 |
| Message-ID | <8akRx.62146$gG1.39471@fx19.iad> |
| In reply to | #72138 |
On 10/7/15 11:43 AM, Keith Thompson wrote: > Richard Damon <Richard@Damon-Family.org> writes: >> On 10/6/15 11:56 AM, Keith Thompson wrote: >>> Richard Damon <Richard@Damon-Family.org> writes: >>>> On 10/5/15 5:53 AM, glen herrmannsfeldt wrote: >>> [...] >>>>> And what about the sizeof(char)==sizeof(int) case? >>>> >>>> I HAVE used such a system, and their documentation warned that just >>>> because getchar() returned EOF, wasn't proof that end of file was >>>> reached, you needed to check feof() to be sure. If you knew that your >>>> file was 'text', you didn't need to do this, as ASCII characters were >>>> all values 0 to 127, only binary files could have a -1 character in >>>> them. (I believe this is even standard conforming). >>> >>> What system was it? (And did the documentation warn you to call both >>> feof() and ferror()?) >> >> It was for a TI DSP chip many years ago. The processor basically had no >> support for manipulation things smaller than 16 bits (its word size), >> memory was word addressed. My guess is that they decided that it wasn't >> worth implementing all the warts to fake out having an 8 bit char, and >> figured users weren't going to be using a lot of text, so they just >> stored things 1 '8 bit char' per 16 bit word. > > Interesting. I've heard about C implementations for DSPs having > CHAR_BIT > 8, but I've assumed that they would be freestanding > implementations that therefore would not be required to provide > <stdio.h>. Apparently that was a bad assumption. > > What is a full hosted implementation, or was it a freestanding > implementation that just happened to provide <stdio.h>? > It was classified freestanding, but had some minimal file support (flash card).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2015-10-05 01:47 -0700 |
| Message-ID | <kfnzizx3dms.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #71922 |
Richard Damon <Richard@Damon-Family.org> writes: > 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. Consider an implementation which has CHAR_BIT == 16 and also sizeof (int) == 1. On such an implementation EOF must mecessarily be the same as some character value (ie, as returned by getchar()). Obviously this is a big pain, although it can be used workably by doing an extra function call or two whenever an EOF value is seen. AFAIK the Standard admits such implementations. ISTM this example shows the utility of the perspective I have been taking. Obviously this example may not be very compelling because it comes up only rarely, if at all. But I think it's easy to find similar examples that are more common, eg, wanting to indicate an error return in a size_t value. In some cases this forces a decision as to whether to exclude some otherwise legitimate value, or to adopt some other approach that may entail unreliable encodings. A key benefit of using the terms as I have been is that it distinguishes reliable encodings and unreliable ones.
[toc] | [prev] | [standalone]
Page 4 of 4 — ← Prev page 1 2 3 [4]
Back to top | Article view | comp.lang.c
csiph-web