Re: Flibble’s Leap: Why Behavioral Divergence Implies a Type Distinction in the Halting Problem

On 12/05/2025 05:37, Keith Thompson wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:

On 12/05/2025 04:11, Keith Thompson wrote:

Richard Heathfield <rjh@cpax.org.uk> writes:
[...]

ALL C compilers are required to diagnose ALL syntax errors and ALL
constraint violations.

Yes, all conforming C compilers are required to do that.  (Well,
strictly speaking they're only required to issue at least one diagnostic
for any translation unit that violates a syntax rule or constraint.)

>
I was unintentionally ambiguous, for which I apologise.
>
The point I sought to make is that there is no syntax error (or
constraint violation) so trivial that a compiler is given licence not
to issue a diagnostic it if it has no other reason so to do.
>
That is, they are all capable of ticking the box that says 'must issue
at least one diagnostic'.
>

[...]
>

In my experience, Microsoft's C compiler - although not perfect - is
pretty good at following conformance rules. I'd be surprised to learn
from a competent source that it misses a syntax error.

I wouldn't, since few if any C compilers are conforming by default.

>
I was talking about conforming mode, which IIRC (it's been a while) is
invoked by -W4 (a warning level that I habitually used in the days
when I still used Microsoft software).
>

I've just tried 4 different C compilers (gcc, clang, and tcc
on Ubuntu, MS Visual Studio 2022 on Windows), and none of them
diagnosed a stray semicolon at file scope *by default*.  gcc and
clang can be persuaded to diagnose it.  tcc, as far as I can tell,
cannot; I don't believe it claims to be fully conforming in any mode.
I wasn't able to get MSVS to diagnose it, but there could easily
be an option that I'm missing.

>
Could you crank MSVS up to -W4 (or whatever the max is these days) and
try again? I hate to impose, but of course it's your own fault for
qualifying as a competent source. ;-)

 It's "/W4".

/, yes. I meant /, honest. [Crosses fingers behind back]

 The default appears to be "/W3".
 With "/W4", or even "/Wall", it still doesn't diagnose a stray semicolon
at file scope.  (I wouldn't expect a warning option to be the
incantation that makes the compiler conform to the standard.)
 The "/Za" option

...rings a very faint bell.

is supposed to disable language extensions,

/Za used to do a fair job. For example, it revealed BCPL comments in math.h, back in the day when BCPL comments were a syntax error. Irritating because I wanted a clean compile but didn't want to hack about in the implementation headers. (I can't remember how I solved that - a pragma, possibly.)

but it
complains that "'/Za' and '/std:c17' command-line options are
incompatible".

Ha!

The implementation supports both C and C++.  It seems to treat C as a
second-class citizen.

That was always the case, although the rumour is that they're taking C conformance more seriously these days. (I heard that quite recently. This year, I think.)

 (I think, but I'm not sure, that a stray
semicolon at file scope is legal in C++; it's called an
"empty-declaration".)

I wasted half an hour trying to chase down the same question.

 

If it doesn't diagnose at its maximum warning level, then okay, ~I
lose the syntax battle.

 I'd say that Microsoft's compiler loses the syntax battle.

Fair enough. But it does mean that Mr Olcott has a reasonable excuse for his code failing to observe a C syntax rule. He should still fix it, of course, but I'm not seeing any great interest from Mr Olcott in getting the code right.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within