Path: csiph.com!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c Subject: Re: Portable 16 bit binary integer write Date: Mon, 19 Sep 2016 15:58:53 -0700 Organization: None to speak of Lines: 83 Message-ID: References: <50a1e8f4-4fb3-4491-97d0-54768bf28685@googlegroups.com> <0b757bbb-0494-44cb-bd5a-26f117aaa404@googlegroups.com> <2cf666d7-0755-4c70-adad-07dbafc2b2e7@googlegroups.com> <09cb4413-16a6-4b63-89d0-9dafe56562f6@googlegroups.com> <68e53f3a-5fcc-44fc-90c4-bcf8dc3db680@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="13415"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19JPChlahJRdF9tgNnzoYey" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:jZNqyPA8jNzBerVAYpx+F/a7Fco= sha1:O2GPPdcNaYbu+zJJaX1WJLBUnCg= Xref: csiph.com comp.lang.c:93830 BartC writes: > On 19/09/2016 18:51, Keith Thompson wrote: >> BartC writes: > >>> Short short? >> >> No, I'm not suggesting that, and it's not at all necessary. >> >> Extended integer types typically have names with the form of reserved >> identifiers. An implementation with 8-bit char and 64-bit int might >> have, say, 32-bit short and a 16-bit type named, for example, "__int16". >> could then have: >> >> typedef signed char int8_t; >> typedef __int16 int16_t; >> typedef short int32_t; >> typedef int int64_t; >> >> (and so on for uintN_t, [u]int_leastN_t, et al). >> >> If you were starting with C90 (which didn't have extended integer >> types or ) and you wanted to permit 64-bit int while >> still providing 8-bit, 16-bit, and 32-bit integer types, you might >> reasonably consider adding "short short". But with the features >> added in C99, that was no longer necessary. > > The C99 features aren't quite the same thing. Sometimes you don't want > to specify hard integer widths. You just want an 'int', whatever width > that happens to be, and also have a wider int and a narrower one. (For > example, what type do you need to represent the least or most > significant half of an int?) C has no direct way to specify a type half as wide as int, and it never has. K&R1, published in 1978, says that the implementation for the Honeywell 6000 use 36 bits for short, int, and long. The intent is that short and long should provide different lengths of integers where; practical; int will normally reflect the most "natural" size for a particular machine. As you can see, each compiler is free to interpret short and long as appropriate for its own hardware. About all you should count on is that short is no longer than long. That last sentence understates things a bit; you could also safely assume that short is no longer than int, and that int is no longer than long. > The C99 intN_t types also introduce some problems: what printf format do > you use for int32_t for example, and which for int64_t? "%" PRId32 for int32_t, "%" PRId64 for int64_t. The macros are defined in . #include #include int main(void) { int32_t x = INT32_MAX; int64_t y = INT64_MAX; printf("x = %" PRId32 ", y = %" PRId64 "\n", x, y); } Or if that's too ugly for you, you can safely convert an int32_t value to long and use "%ld", or an int64_t value to long long and use "%lld". #include #include int main(void) { int32_t x = INT32_MAX; int64_t y = INT64_MAX; printf("x = %ld, y = %lld\n", (long)x, (long long)y); } > With the non-specific types, you know that %d, %ld and %lld correspond > to int, long int, and long long int respectively (even if there are only > two different widths rather than tree. Or just one). Yes. -- 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"