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: Mon, 10 Apr 2017 16:10:12 -0700 Organization: None to speak of Lines: 35 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="913956ba7f89f589d37e4638206b6a51"; logging-data="21822"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/2yH7ZxXwD3DzOlYQUpWLJ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:UtXMxGI4ySU3ICp4U52dV09mG6k= sha1:7yg6vQhW6VI1mP9owAEgbltQ9P0= Xref: csiph.com comp.lang.c:108023 supercat@casperkitty.com writes: [...] > 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. I can't think of any interpretation of that statement that is both reasonable and correct. Can you rephrase it, with careful consideration to what the phrase "undefined behavior" actually means (N1570 3.4.3)? If you're using the phrase "undefined behavior" in a sense other than that defined by the standard, please don't bother explaining. > 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()". If I understand that correctly, I agree. Using prototypes rather than old-style declarations for greater clarity, if an implementation doesn't define the behavior of `void main(void)`, then its behavior is undefined -- and always, the actual behavior might be something useful, whether it's documented/defined or not. An implementation is free to define the behavior of `void main(void)` in any way it likes (as long as it doesn't contradict the rest of the standard) (5.1.2.2.1p1), and that behavior needn't match the behavior of `int main(void)`. (Where "the behavior of `void main(void)`" is verbal shorthand for "the behavior of a program that defines `void main(void) { /* ... */ }`.) [...] -- 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"