Date: Fri, 15 Jan 2021 12:57:14 -0800 From: Mark Millard <marklmi@yahoo.com> To: Walter von Entferndt <walter.von.entferndt@posteo.net> Cc: freebsd-hackers@freebsd.org Subject: Re: Implicit assumptions (was: Re: Some fun with -O2) Message-ID: <4E90FC92-D255-4082-9F89-2BEE4D4C4E92@yahoo.com> In-Reply-To: <8830694.EFs4ROYVHJ@t450s.local.lan> References: <mailman.29.1610625600.45116.freebsd-hackers@freebsd.org> <2310709.D6tDg3Ca2R@t450s.local.lan> <FA82F286-8818-45B8-81C0-CE8A85BBB366@yahoo.com> <8830694.EFs4ROYVHJ@t450s.local.lan>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2021-Jan-15, at 11:22, Walter von Entferndt = <walter.von.entferndt@posteo.net> wrote: > At Freitag, 15. Januar 2021, 19:35:40 CET Mark Millard wrote: >> Have you read a (fairly modern) C standard or its officially >> published rationle? You might want to. >>=20 > Honestly, no. The price to download the official standard PDF from = https:// > www.iso.org/standard/74528.html is ~200 CHF. If you can send me a = link to=20 > download a copy, I'd be thankful. The rationale vintage that I have a copy of is available at: http://www.open-std.org/jtc1/sc22/wg14/www/C99RationaleV5.10.pdf The rationale is normally a better starting point than the standard for guiding understanding of the standard --but is not normative. What makes the rationale a matter starting point for interpreting the standard is that, while the standard should have the more overall properties documented in the rationale, one has to infer various properties from more detailed rules that were designed to have the properties (and may be better at covering limiting conditions than the more overall rationale material). But the rationale can not be used to answer all questions. As for drafts of vintages of the standard: http://www.open-std.org/jtc1/sc22/wg14/www/projects#9899 has links (the first 4 N???? links) to final drafts (or very-early next-standard drafts) of the standards for C2x, C17, C11, and C99. My understanding is that C17 mostly dealt with clarification requests, other than the ATOMIC_VAR_INIT one leading to depreciating ATOMIC_VAR_INIT instead. As I understand, FreeBSD basically targets C99 (possibly without things made optional or depreciated in C11 or later: future compatibility biased). > Any other good reference manual either in=20 > PDF or HTML (tarball or thelike) would also be fine. I showed my = source=20 > (https://code-reference.com/c/) which I quickly looked up on the net. >=20 >> =46rom the officially published C99 rationale (page labeled 11, >> Terms and definitions): >>=20 >> QUOTE >> ) All objects in C must be representable as a contiguous sequence of = bytes, >> each of which is at least 8 bits wide. >>=20 >> ) A char whether signed or unsigned, occupies exactly one byte. >>=20 > That means it does not make any difference to use either NBBY or = CHAR_BIT? =20 > Maybe CHAR_BIT is preferable, because it is C standard (guaranteed to = exist on=20 > all platforms), whereas NBBY is not since it's in include/sys? I'd say that using C's CHAR_BIT means less variation in the code from = system to system and less knowledge of system specifics required. So in code = not intended to be system specific, CHAR_BIT would be preferred. That does = not cover code intended to be system specific. > Beside that, can you affirm the fix I suggested is correct & portable? Before I could make any grand overall claim about the code, I'll need to take time to think about all of it, instead of just reporting things that I happen to quickly notice while scanning the exchange. I may get to this, but I'm not sure when. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4E90FC92-D255-4082-9F89-2BEE4D4C4E92>