Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!reader02.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: C++ features for C Date: Fri, 18 May 2018 10:36:04 -0700 Organization: None to speak of Lines: 61 Message-ID: References: <11edbfd7-461d-4579-8ac7-a9e84a6b7630@googlegroups.com> <726d9572-f3c9-4f44-846d-eb49d6750d64@googlegroups.com> <2vjLC.94102$JJ3.94015@fx23.iad> <437a888c-00fc-4c72-a009-8ee019f6b76c@googlegroups.com> <2e5df1b2-c837-4fc6-8055-61bfb22b9356@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: h2725194.stratoserver.net; posting-host="5fbdf324eb3e0637623434efe907fd89"; logging-data="11957"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Z9aXfSiLgdid92+vq5omt" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:olPA5BbzCiXOeZz8vS5HEsoVJHs= sha1:zz39qWyGvR7Xf1RLEbAza+37CCs= Xref: csiph.com comp.lang.c:130757 supercat@casperkitty.com writes: > On Thursday, May 17, 2018 at 6:28:30 PM UTC-5, Keith Thompson wrote: >> supercat@casperkitty.com writes: >> [....] >> > The only practical reason that %x, %lx, and %llx cannot portably be used >> > to output uint16_t, uint32_t, and uint64_t is that the Standard never >> > officially recognized that the vast majority of compilers that supported >> > those types could support such usage, and required that any compilers that >> > don't support such usage must indicate such non-support in some fashion. >> >> The reason %x, %lx, and %llx cannot portably be used to output uint16_t, >> uint32_t, and uint64_t is that uint16_t, uint32_t, and uint64_t are not >> unsigned int, unsigned long, and unsigned long long, respectively. > > True, but on nearly all platforms that include those types, the types > uint16_t, uint32_t, and uint64_t will be promoted to types Again, they are not promoted to *types*. Variadic arguments of types narrower than int are promoted to int or to unsigned int. Other types might be stored in a way that occupies more space than the type itself (say, a 32-bit value stored in a 64-bit register or occupying 64 bits on the stack). > with the same > representations as int, long, and long long, respectively. A requirement > that implementations supporting those types must behave that way would > probably impact fewer implementations than the requirement that the types > have no padding bits, which made the types unsupportable on 36-bit > platforms (absent that requirement, such platforms would have been able to > support code that uses type uint32_t by storing them as a 36-bit word with > four padding bits). The standard is careful to allow for a wide variety of target platforms, and to avoid specifying things it doesn't need to. You propose to fragment the standard, so that *most* implementations behave in a certain specified way but others do not, with a macro so you can tell which. This would make it more difficult to write 100% portable code, code that needs to be portable not just to current implementations but future ones as well. You want to nail down the characteristics of current systems and impose them on future implementations. All this because you'd rather write printf("x = %d\n", x); and have it work on 99% of current systems (and perhaps failing silently), than write printf("x = %ld\n", (long)x); and have it just work. You propose a complex solution for a trivial problem. No thanks. [...] -- 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"