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 12:41:26 -0700 Organization: None to speak of Lines: 90 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: reader02.eternal-september.org; posting-host="a6d658d4a2a10098aaf65c730678ffc4"; logging-data="26401"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX19n4jNhEN6QRrB+VVhqviLr" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:iCo8X4lSvdXxLYXPKauSuqWpgwU= sha1:MA1svGomzVM+QYSFk6MeZ3puduc= Xref: csiph.com comp.lang.c++:67855 "Alf P. Steinbach" writes: > On 21.08.2019 11:55, Keith Thompson wrote: >> "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. > > I'm sorry, that's a simple fallacy. No, that's what the documentation says. > That g++ doesn't do that now, has no bearing on what it /can/ do. How is that relevant? The language standard requires each implementation to document what a "diagnostic" is. The gcc/g++ documentation clearly documents what a "diagnostic" is, in a way that clearly excludes "non-blinking caps lock". A future version could change that, but I'd be willing to bet that it won't. By accepting identifiers with "$" without a diagnostic in what is intended to be a conforming mode, g++ is violating the requirements of the C++ standard. If you disagree, what exactly is your argument? > As far as the formal is concerned g++ can use the non-blinking caps lock > as a diagnostic. The "formal" what? Yes, the standard permits an implementation to use a non-blinking caps lock as a diagnostic -- if and only if its documentation defines "diagnostic" in a way that's consistent with that. No implementation does so or is likely to do so in the future. I thought your argument was based on "common sense". Here's an idea. I'll just assume that, at some point in the future, you might change your argument and agree with me. Problem solved. [...] > For example, I remember `$` being used in the system API in the HP3000. > That's long ago, 1980s, but presumably use of `$` in system API function > names was part of the reasons why compilers supported it. And continue > to support it. OpenVMS uses $ in identifiers (and C and C++ compilers for OpenVMS have to allow for that). Which is why, in my opinion, the standard *should* allow compilers to accept $ in identifiers. [...] -- Keith Thompson (The_Other_Keith) kst-u@mib.org Will write code for food. void Void(void) { Void(); } /* The recursive call of the void */