Path: csiph.com!optima2.xanadu-bbs.net!xanadu-bbs.net!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: Fri, 24 Jul 2015 11:14:29 -0700 Organization: None to speak of Lines: 74 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="10386"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX192aeR2sZ7Is9ls/mQOCCuC" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:HH31X04IEfu4AzvoNdl1BDXuBEk= sha1:h5bqiTcsbareVP5PKnovEX9a2rM= Xref: csiph.com comp.lang.c:66298 Tim Rentsch writes: > Keith Thompson writes: >> Tim Rentsch writes: >>> Keith Thompson writes: >>>> Tim Rentsch writes: >> >> [...] >> >>>>> It is possible to have a conforming implementation with >>>>> CHAR_BIT > 8 but still having a type that occupies only eight >>>>> bits. AFAIK there is no reason such an implementation >>>>> could not use that type to provide the [u]int8_t types. >>>> >>>> I'm skeptical. >>> >>> The combination of undefined behavior resulting from trap >>> representatons and the Standard allowing an extremely wide >>> range of extensions is enormously powerful. In some sense >>> it's an academic question since such an implementation will >>> in all likelihood never be produced. But I think it's >>> interesting to consider the possibility. >> >> Sure -- but I still don't think it's a possibility. >> >> Extensions can take advantage of undefined behavior, but your proposed >> extension (using padding bits and trap representations in size_t to >> represent fractional values) introduces undefined behavior where it >> doesn't currently exist. I believe it is therefore non-conforming. >> >> I believe that this program: >> >> #include >> #include >> >> int main(void) { >> #ifdef UINT8_MAX >> if (sizeof (uint8_t) < (size_t)1) { >> puts("I am confused"); >> } >> else { >> puts("ok"); >> } >> #else >> puts("ok"); >> #endif >> return 0; >> } >> >> is strictly conforming (subject to the usual caveats about the puts call >> failing) and must print "ok". > > Sure, but that doesn't mean there can't an extension that provides > these types, as long as they are provided only to (some subset of) > programs that are not strictly conforming. If you enable the extension only in the presence of a #pragma, for example, then sure, it would be valid. A conforming implementation could have a "#pragma LANGUAGE FORTRAN" that turns it into a Fortran compiler. Types smaller than CHAR_BIT bits are permitted as an extension only in the sense that just about *anything* is permitted as an extension. Using such a type to define uint8_t on a system where CHAR_BIT > 8 would not, I think, be conforming. In addition, I think it would be a bad idea; it would break some assumptions that C programmers can reasonably depend on, such as that any object's representation can be treated as an array of unsigned char -- or that sizeof yields an integer. -- 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"