Path: csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From: Keith Thompson <kst-u@mib.org>
Newsgroups: comp.lang.c
Subject: Re: C wish list
Date: Thu, 21 Mar 2019 12:55:40 -0700
Organization: None to speak of
Lines: 54
Message-ID: <ln7ecsgfyb.fsf@kst-u.example.com>
References: <de7f6c95-d2a8-4f26-9416-f72305578c3b@googlegroups.com> <q6tnla$k2v$1@dont-email.me> <b2676902-cb4c-46a7-aa0e-52f8c2974e28@googlegroups.com> <q6ud1u$thm$1@dont-email.me> <9747a924-fa28-4737-99f4-4a59cfa95e27@googlegroups.com> <q708uj$l55$1@dont-email.me> <ff19f3bb-cb50-4e49-9c1d-4e8062bc2928@googlegroups.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Injection-Info: reader02.eternal-september.org; posting-host="9515313518a1e23526d751bd086ff0bd"; logging-data="25093"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+NrHiMmNd/7eaN50osZcCs"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)
Cancel-Lock: sha1:TkBFHRAX/ZBJOVRqALu8i7Ls/S8= sha1:5brAnTaQOOJ/gKl1t0aC8T98iC0=
Xref: csiph.com comp.lang.c:142200

Howard Chu <highlandsun@gmail.com> writes:
[...]
> The language may be defined in terms of an abstract machine, but its result
> must run on real machines; this is why anyone bothers to use it. Otherwise
> you could just run Java or any of a multitude of other VM-based languages.
>
> It would be sufficient to amend the spec to say: the effect of
> undefined behaviors in the abstract machine are left to the underlying
> real machine to manifest.
>
> I.e., the underlying machine may generate a trap, may ignore the
> instructions, or whatever. But it's not the compiler's prerogative to
> *delete* the code and prevent the underlying machine from even
> executing the relevant code at all. That's just utter nonsense. The
> compiler's job is to translate source code into executable code for
> the underlying machine. Not to judge whether the code makes sense,
> either in abstract or in an actual machine.

I'd like to see a rigorous specification of that, in terms of C
source code and the *observable behavior* of C programs.  It's not
the C standard's place to talk about generated machine code.
There might not even be any generated code for an interpretive
implementation.

Optimizing C compilers do not detect undefined behavior and then
decide to generate silly code.  They *assume* that the input source
code has defined behavior, and then generate machine code based
on that assumption.  By the time an optimizer is deleting code
(more accurately, refraining from generating machine code for some
source code), the compiler likely doesn't even know that the input
C code had undefined behavior.

For this:

    #include <stdio.h>
    int main(void) {
        puts("Hello");
        return 0;
        puts("WTF?");
    }

would you require a compiler to generate code for the second puts()
call?

(It certainly would be nice if it were easier to determine whether
a given C source program has undefined behavior.  In some languages
other than C, it *is* generally easier.  But I don't know of any
language that completely avoids undefined behavior without expensive
run-time checking.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Will write code for food.
void Void(void) { Void(); } /* The recursive call of the void */