Path: csiph.com!eternal-september.org!feeder.eternal-september.org!mx02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: counting bytes Date: Sun, 06 Sep 2015 17:46:59 -0700 Organization: None to speak of Lines: 60 Message-ID: References: <87eglns3jc.fsf@kst-u.example.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="27164"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/TnTT6CeEXin3b+8b8Wjqg" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:El4TwrxJ2bodPTMXPnspUH+mrss= sha1:ZF27cYlDdefhAiIwWjHbxSjhTqc= Xref: csiph.com comp.lang.c:69709 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> Richard Damon writes: >> >> [...] >> >>>> UINT8_MAX has only one allowed value, 255, any other value (other than >>>> not defined) is non-conforming. (The fixed sized maxes are a bit >>>> strange only having a single possible value). >>> >>> I won't disagree, but even so the Standard says the value is >>> implementation-defined. Look it up if you don't believe me - >>> it's listed in both 7.20.3 and J.3.13. >> >> N1570 7.20.3 doesn't mention UINT8_MAX. > > Sorry, I had the wrong section. It's 7.20.2. > >> It's mentioned implicitly in 7.20.2.1, which says that UINTN_MAX >> is exactly 2^N-1, not that it's implementation-defined. > > Please see 7.20.2 p2, which does. Its implementation-defined value shall be equal to or greater in magnitude (absolute value) than the corresponding value given below, with the same sign, except where stated to be exactly the given value. I think that's just a bit of sloppy wording. 3.19.1 defines an "implementation-defined value" as an "unspecified value where each implementation documents how the choice is made", and an "unspecified value" as a "valid value of the relevant type where this International Standard imposes no requirements on which value is chosen in any instance". So the value of INT_LEAST8_MAX, for example, is said to be "implementation-defined", but that contradicts the definition of the term, since the standard does impose *some* requirements on which value can be chosen (it can't be 42, for example). IMHO the fix for that would be to tweak the definition of "implementation-defined value", so it can apply to values for which the standard imposes *some* requirements without requiring one specific value. The most literal reading of 7.20.2p2 is that the value of UINT8_MAX is implementation-defined. A more sensible reading, IMHO, is that values that are stated to have exact values are *not* implementation-defined. That requires a slightly strained parsing of the sentence. I would not consider an implementation to be non-conforming because it doesn't document the value of UINT8_MAX. -- Keith Thompson (The_Other_Keith) kst-u@mib.org 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"