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: How to fix: [-Wformat-nonliteral] Date: Fri, 14 Apr 2017 13:22:44 -0700 Organization: None to speak of Lines: 52 Message-ID: References: <87mvbsv0tq.fsf@bsb.me.uk> <87h920ukud.fsf@bsb.me.uk> <4f2b7ab6-2fa0-4fc9-aea2-7912adf068b5@googlegroups.com> <2937e657-8cbe-40ad-a526-978b29bd9247@googlegroups.com> <2b453753-ad00-4ae3-8143-4a55597cd3d9@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="87b6161aa899ca9c7c893fe10ff12fc6"; logging-data="16488"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+6WvV6haDP8+kGAeqitAed" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:c0CSrFo5yiB7pDYVSfLRYWC6/nY= sha1:N9yoxnVEx3dWyCop92KKeVO4HMs= Xref: csiph.com comp.lang.c:108151 supercat@casperkitty.com writes: > On Friday, April 14, 2017 at 5:40:41 AM UTC-5, David Brown wrote: >> That would certainly have its advantages. However, it is very common to >> use doubles in code without really thinking about it: >> >> float x, y, z; >> z = 2.0 * x + y; >> >> The 2.0 is a double - to keep everything in floats, it would need to be >> 2.0f. Making doubles the same as floats keeps the source code simple. > > If the rules for "long double" had said that they are passed the same as > "double" except when either a prototype exists that specifies "long double" > or the argument expression *is* an explicit cast to long double, then all > constants could have supplied long double values at the compiler's leisure, > perhaps with a language rule that would indicate that given expressions > like: > > float f = someFloat * 0.1; > double d = someDouble * 0.1; > > a compiler would be allowed to perform the multiplication using whichever > type was most convenient and a constant suitable for that type (if there > were such a rule, there should be a suffix to explicitly indicate double > literals, in case one wanted to force the use of extra precision). So you propose that given long double x; these calls: func(x) func((long double)x) should have different semantics. I hate that idea. I'm not sure what you're trying to achieve, but I suggest finding a different way to do it. [...] The idea, I think, is to provide a *non-conforming* C implementation for a target that supports 32-bit floating-point but nothing wider (assuming software floating-point is impractical or not worthwhile). Given the central role played by type double, I'm thinking a good approach would be to make float and double both 32 bits while keeping all the other language rules in place. Type long double could either be dropped or made 32 bits. I suggest dropping it, since code that uses long double probably depends on extra precision and/or range. -- 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"