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: Wed, 12 Apr 2017 18:13:54 -0700 Organization: None to speak of Lines: 92 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: mx02.eternal-september.org; posting-host="13360d95e95b581afe8d2d731341601b"; logging-data="15047"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/9mYQCvmnHcog8nZ5+Z/aX" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:6VATcHuTItS+ffvVSDGioYiTZVA= sha1:Purp/XG/Lm3c3hUXBcIhe81O1UQ= Xref: csiph.com comp.lang.c:108093 David Brown writes: > On 11/04/17 17:37, supercat@casperkitty.com wrote: >> On Tuesday, April 11, 2017 at 4:33:26 AM UTC-5, David Brown wrote: >>> On 11/04/17 00:43, supercat wrote: >>>> On Monday, April 10, 2017 at 5:18:39 PM UTC-5, David Brown wrote: >>>> I don't think the Standard allows compilers to regard as Undefined Behavior >>>> the use of any entry-function signature other than those explicitly described. >>>> If an implementation that didn't describe any behavior for "void main()" >>>> would be allowed to treat it as UB, I see no reason that it shouldn't be >>>> allowed to describe a useful behavior that differs from "int main()". >>>> >>> >>> I can't figure out what you are trying to say here. We are not talking >>> about undefined behaviour here - we are talking about a non-conforming >>> implementation of the compiler. >> >> If some compiler X doesn't document any particular behavior for "void main()" >> but such code happens to behave like "int main()" but without variable >> initialization, such behavior would be conforming since use of "void main()" >> would be UB, making all possible actions conforming. >> >> If some compiler Y were identical to X except that it *documented* that >> "void main()" would work as it does in compiler X, then "void main()" would >> not be UB on compiler Y, but I see no reason that compiler Y shouldn't be >> conforming. > > You are still making no sense. The implementation's way of handling > main() cannot be undefined behaviour - it is defined by the > implementation. It might not conform to the C standards, but it can > never be undefined behaviour. The phrase "undefined behavior" is defined in C11 3.4.3 as: behavior, upon use of a nonportable or erroneous program construct or of erroneous data, for which this International Standard imposes no requirements In general, if a construct has undefined behavior and an implementation chooses to define it, it still has "undefined behavior" by that definition. But the behavior of the program `void main(void){}` is not (unconditionally) undefined. By 5.1.2.2.1, the main function may be defined "... or in some other implementation-defined manner". If the current implementation documents its support for `void main(void(){/*...*/}`, then that's a permissible definition, and the behavior is defined (but the termination status is unspecified). If not, then the program violates a "shall" outside a constraint, and its behavior is undefined. Note that for an implementation that documents that it supports `void main(void)`, all the requirements in the standard (aside from the termination status) are in full force. Omitting zero-initialization of static objects would still make the implementation non-conforming. I suppose a implementation could (a) *not* document `void main(void)` as "some other implementation-defined manner" under 5.1.2.2.1, but (b) document `void main(void)` as an extension under 4p6, and then do anything it likes. But that would be perverse. An implementation can certainly support an extension that doesn't zero-initialize static objects, as long as that extension doesn't break any strictly conforming program. For example, a compiler-specific #pragma would be OK. Triggering the behavior based on the return type of main would IMHO be silly. (Note that `main` is relevant only for hosted implementations.) [...] > I agree that for some targets, it can be better to make some breakage to > C standards conformity. But that should be kept to the absolute > minimum, be well documented, not break working code silently, and > preferably require a command-line switch to activate it or give warnings > about the odd behaviour. It is reasonable, for example, for a C > implementation on a small 8-bit micro to make "double" limited to 32 > bits. It is /not/ reasonable to change the meaning of a keyword like > "const" to mean something subtly different, or to skip the zeroing of > uninitialised data. Wouldn't it be better to support 32-bit "float" and reject "double"? It's non-conforming either way, but it would cleanly reject code that uses "double" and quite reasonably expects it to be wider than 32 bits. [...] -- 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"