Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail From: Keith Thompson Newsgroups: comp.lang.c++ Subject: Re: An example: code to list exports of a Windows DLL. Date: Wed, 21 Aug 2019 02:55:57 -0700 Organization: None to speak of Lines: 57 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: reader02.eternal-september.org; posting-host="a6d658d4a2a10098aaf65c730678ffc4"; logging-data="15048"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+JmovnjF26JCTzgrPpEVOQ" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:EEubDpaq/OsclcXG2a26BmHXDT4= sha1:eKWxCzd/kGkHNumxVng+0bToizE= Xref: csiph.com comp.lang.c++:67841 "Alf P. Steinbach" writes: > On 21.08.2019 10:29, David Brown wrote: >> On 20/08/2019 23:59, Keith Thompson wrote: [...] >>> The effect is the same: a diagnostic is required. (If the >>> implementation chooses to produce an executable after printing the >>> required diagnostic, I suppose the behavior is undefined by omission.) > > There's no need to print anything. /Not/ blinking the caps lock > indicator for a millisecond is a valid diagnostic. The standard doesn't > specify what a "diagnostic" or a "diagnostic message" is, that it should > involve text at all, or that it should be context-independent... > > That may sound like a silly argument. Yes, it does. The standard requires a diagnostic message for certain errors, and defines a "diagnostic message" as "a message belonging to an implementation-defined subset of the implementation’s output messages". The phrase "implementation-defined" means the documentation has to document it. gcc's documentation, for example, says: * 'How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90, C99 and C11 5.1.1.3).' Diagnostics consist of all the output sent to stderr by GCC. That's for C, but the "C++ Implementation-Defined Behavior" says "Some choices are documented in the corresponding document for the C language." So no, for gcc/g++ not blinking the caps lock is not a diagnostic. > But it's exactly the same kind of argument as the quoted text that it > responds to: a literal formal interpretation of text that was meant to > be read with some common sense engaged. To the degree that that quoted > text is a valid argument, this caps lock non-blink argument is valid. > > Of course, both are silly. > > It doesn't make sense to assume that kind of absolute formal rigor in > the standard, and taking the standard's words literally proves that that > leads to totally absurd consequences. I prefer to assume that *the standard means what it says* whenever possible. In this particular case, I think that the wording of the current standard, though it's unambiguous, has an unintended consequence. -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */