Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C String terminator Date: Fri, 03 Apr 2020 13:24:39 -0700 Organization: None to speak of Lines: 55 Message-ID: <87ftdkqpvc.fsf@nosuchdomain.example.com> References: <861rrtj9hx.fsf@linuxsc.com> <87d0bc8xf6.fsf@nosuchdomain.example.com> <861rquhlqk.fsf@linuxsc.com> <87wo8m9nm4.fsf@nosuchdomain.example.com> <86imjyd2hl.fsf@linuxsc.com> <87blpqa6y6.fsf@nosuchdomain.example.com> <867dz589t3.fsf@linuxsc.com> <875zepvvu1.fsf@nosuchdomain.example.com> <86sghl6eop.fsf@linuxsc.com> <61f8fb26-45fb-46c4-8bf4-d85d8fb94a8d@googlegroups.com> <86a73tpb20.fsf@linuxsc.com> <2a770f28-0124-4b7e-8da3-24c05dd75636@googlegroups.com> <87wo6wqxs5.fsf@nosuchdomain.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="1d8737ba6267b0ea8183eb35e9935d13"; logging-data="26515"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18CEQt5JAmkS8ZDTDhvyGvn" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.3 (gnu/linux) Cancel-Lock: sha1:/cqKz+PkFxjvSGxY0KQItgmbuNE= sha1:T9KnfooyYYXQzk02xo+qvtVDvg8= Xref: csiph.com comp.lang.c:150996 Malcolm McLean writes: > On Friday, 3 April 2020 19:48:56 UTC+1, James Kuyper wrote: >> >> It's a serious mistake to interpret what the standard says about >> characters using any definition of "character" other than one the two+ >> (3.7p1, 3.7.1p1) provided in the standard (any context where it makes a >> difference which of the two applies, and is not clear from context, >> constitutes a defect in the standard - such a situation would not >> justify using your own preferred definition for the term). Similarly, >> the standard defines many terms that include the word "character" (such >> as "multibyte character" or "source character set" or "decimal-point >> character"), and it's a serious mistake to use any definitions for any >> of those terms other than the ones provided by the standard, when >> interpreting what the standard means. That's the reason the standard >> provides such definitions. > > The two definitions are: > character〈abstract〉member of a set of elements used for the > organization, control, or representation of data > > 3.7.11 character > single-byte character〈C〉bit representation that fits in a byte > > So the second definition is a synonm for "char or derived types". > The first is an attempt to provide the normal English definition in > a computer context, and they haven't made a very good job of it. > > For Keith's benefit, by "char or derived types" I mean char, > unsigned char, signed char, plus any aliases such as uint8_t. I > don't mean wchar_t, which is a "type derived from char", because you've > taken the concept of "char" and extended it, but in another context. Please stop using the term "derived types" in a manner that contradicts the clear definition in the standard -- especially when you're discussing definitions in the standard. > You have to read sympathetically, assuming that if there is a natural, > correct meaning which makes sense, this is also the meaning intended. > That's part of communication. Try to be better at it. Again, you *know* that by deliberately using technical terms with meanings other than those defined in the standard, you'll trigger these time-wasting arguments. Yes, I knew what you meant by "derived types" -- but why impose that extra effort on your readers rather than taking just a moment of your own time to write clearly and correctly? The standard already has the defined term "character types", which as far as I can tell matches what you're talking about. -- Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com Working, but not speaking, for Philips Healthcare void Void(void) { Void(); } /* The recursive call of the void */