Path: csiph.com!news.mixmin.net!eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Tim Rentsch Newsgroups: comp.lang.c Subject: Re: Dymamic arrays: memory management and naming Date: Tue, 03 Oct 2023 03:29:42 -0700 Organization: A noiseless patient Spider Lines: 67 Message-ID: <86sf6sc82x.fsf@linuxsc.com> References: <20230909132336.99cdb303ad685bc1e40f92df@gmail.moc> <86ediwmk8b.fsf@linuxsc.com> <20230919011018.d9ed14da6e842291d47b69d7@gmail.moc> <86jzsmkqyu.fsf@linuxsc.com> <20230924003915.51bb21339ab1c551eba59162@gmail.moc> <20230924081911.947@kylheku.com> <20230925155845.139@kylheku.com> <86sf71itgt.fsf@linuxsc.com> <87msx9u09c.fsf@nosuchdomain.example.com> <86o7hpiggw.fsf@linuxsc.com> <87fs31tgnj.fsf@nosuchdomain.example.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: dont-email.me; posting-host="a7f15c7033ff7991d1a910385a293cab"; logging-data="3690250"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX196NEYc9Fh41JhtqBT2noXwzsmCh26R66E=" User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.4 (gnu/linux) Cancel-Lock: sha1:yCXWCKRFe5ls2CR6pbek0N9n7yY= sha1:NSwGsiHokxF0dhPdpJTVXELvoy8= Xref: csiph.com comp.lang.c:177181 Keith Thompson writes: > Tim Rentsch writes: > >> Keith Thompson writes: >> >>> Tim Rentsch writes: >>> >>>> Kaz Kylheku <864-117-4973@kylheku.com> writes: >>>> >>>>> On 2023-09-24, Kaz Kylheku <864-117-4973@kylheku.com> wrote: >>>>> >>>>>> h only makes sense if you're passing a signed argument and want >>>>>> it printed as unsigned. Say we have 16 bit short and 32 bit int. >>>>>> Then "%u"/(short) -1 will print as 429496725, whereas >>>>>> "%hu"/(short) -1 will obtain the desired 65535. >>>>> >>>>> There is something I had neglected to mention: the use of h for >>>>> portability >>>>> >>>>> If we have "%u" paired with an unsigned short, argument we have a >>>>> mismatch on a large number of platforms, where unsigned short >>>>> promotes to int. The %u specifier wants unsigned int. >>>> >>>> A %u conversion specification is always okay for an unsigned >>>> short argument, regardless of whether the argument promotes to >>>> int or to unsigned int. Reading an integer-typed variadic >>>> argument with the corresponding type of the other signedness >>>> is allowed when the argument value is representable in both >>>> types, which it always will be in this case even if unsigned >>>> short promotes to int. >>> >>> Agreed, but unfortunately the standard doesn't quite say that in >>> normative text -- until C23, as I discovered while writing this. >>> [...] >> >> My position is that this rule was intended since at least C99 >> (and perhaps earlier) but was not expressed at unambiguously as >> one might like. > > It was not expressed in normative text, ambiguously or otherwise. > >> Also I believe there is support for this view if one consults >> various historical documents done by the ISO C committee. > > You wouldn't have specific citations, would you? > > In any case, the language is defined by the standard, not by > historical documents with wording that never made it into the > standard. No implementer or programmer should have to consult > "historical documents" to determine what the standard requires. > >> Also I think it is rather pointless to debate whether the C >> standard does or does not "say that in normative text" when >> the normative text that is there lends itself to different >> interpretations. We all agree on what words are used; what >> the words mean in this case is more a subjective reaction >> than an objective fact. And is pretty much beside the point >> since what was intended and what was understood is the same >> for most of the people who are familiar with the C standard. > > You consider it pointless. I don't. I find both the intent behind > the standard and what the standard says interesting. In this case, > they were two different things, and I consider that to be a flaw > in the standard. I'm glad the flaw is being corrected in C23. I repeat my previous statements.