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: Wed, 28 Sep 2016 12:37:26 -0700 Organization: None to speak of Lines: 50 Message-ID: References: <50a1e8f4-4fb3-4491-97d0-54768bf28685@googlegroups.com> <2cf666d7-0755-4c70-adad-07dbafc2b2e7@googlegroups.com> <09cb4413-16a6-4b63-89d0-9dafe56562f6@googlegroups.com> <68e53f3a-5fcc-44fc-90c4-bcf8dc3db680@googlegroups.com> <119bd09a-db65-4c7b-96d7-c8055c7db355@googlegroups.com> <213983a1-f45c-4b05-a07b-bcb8afa8627e@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="945944de09706c9b4e29b53c9d2efdc2"; logging-data="9333"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+ABXNB3jAuOow+God+WcAV" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:DAZqN/PID2H9L3Dozn4nkeKWJVg= sha1:cO2yPRrvsh7XIR6tSb1dpuJ3G14= Xref: csiph.com comp.lang.c:94215 Malcolm McLean writes: > On Wednesday, September 28, 2016 at 4:17:52 PM UTC+1, Tim Rentsch wrote: >> Malcolm McLean writes: >> > On Friday, September 23, 2016 at 5:30:21 AM UTC+1, Tim Rentsch wrote: >> >> That seems like an arrogant statement, considering the large >> >> number of people who don't agree with it. These days it is >> >> common for personal desktop systems, or even laptops for that >> >> matter, to support regular C arrays larger than can be indexed >> >> either with int or unsigned int. >> > >> > It breaks the language. >> >> You mean it breaks your concept of the language. It does not >> break mine, nor does it for many other people. >> > All functions that accept arrays as parameters and do not place a restriction > on array length are now broken by the introduction of size_t. Not badly. > But still broken. Well that's ok, because *no* functions accept arrays as parameters. Presumably you're referring to functions with a parameter of pointer type, where the pointer is expected to point to the initial element of an array (the pointer parameter declaration can use either array or pointer syntax) . The "introduction of size_t" occurred in the 1989 ANSI standard, if not earlier. And it hardly broke anything; rather, it made it possible to specify sizes portably. I don't know whether any pre-ANSI compilers supported objects bigger than INT_MAX bytes or elements. If some did, then the introduction of size_t made it possible to write more portable code for such systems. If not, then the introduction of size_t made it possible to support such objects, without making int artificially wider than it needs to be. The functions you're referring to were already broken. Adding size_t, (which, again, is hardly a new addition) made it possible to *fix* those functions. Yes, requiring int to be at least wide enough to hold the size of any object, or the length of any array, would have been another solution. That's not the decision that was made 27 years ago, and it's not going to change in any language calling itself "C". Perhaps it's time to get used to that. -- 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"