Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Thomas Koenig <tkoenig@netcologne.de>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 3 Sep 2024 05:55:14 -0000 (UTC)
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <vb68c2$3833i$1@dont-email.me>
References: <2024Aug30.161204@mips.complang.tuwien.ac.at>
 <memo.20240830164247.19028y@jgd.cix.co.uk> <vasruo$id3b$1@dont-email.me>
 <2024Aug30.195831@mips.complang.tuwien.ac.at> <vat5ap$jthk$2@dont-email.me>
 <vaunhb$vckc$1@dont-email.me> <vautmu$vr5r$1@dont-email.me>
 <2024Aug31.170347@mips.complang.tuwien.ac.at>
 <vavpnh$13tj0$2@dont-email.me> <vb2hir$1ju7q$1@dont-email.me>
 <8lcadjhnlcj5se1hrmo232viiccjk5alu4@4ax.com> <vb3k0m$1rth7$1@dont-email.me>
 <17d615c6a9e70e9fabe1721c55cfa176@www.novabbs.org>
 <86v7zep35n.fsf@linuxsc.com> <20240902180903.000035ee@yahoo.com>
 <86r0a2otte.fsf@linuxsc.com> <vb50cm$2uttr$1@dont-email.me>
 <86ed61pfus.fsf@linuxsc.com>
Injection-Date: Tue, 03 Sep 2024 07:55:15 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="a3cc9ce902bf5a312fd31b951bbca1f1";
	logging-data="3411058"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1++dFDizzdZ6fcRqPObt0m9btQshppSnUo="
User-Agent: slrn/1.0.3 (Linux)
Cancel-Lock: sha1:mpSa8RXrd/GJevWm4wv9NR6AMJQ=
Bytes: 3483

Tim Rentsch <tr.17687@z991.linuxsc.com> schrieb:

> My suggestion is not to implement a language extension, but to
> implement a compiler conforming to C as it is now,

Sure, that was also what I was suggesting - define things that
are currently undefined behavior.

> with
> additional guarantees for what happens in cases that are
> undefined behavior.

Guarantees or specifications - no difference there.

> Moreover the additional guarantees are
> always in effect unless explicitly and specifically requested
> otherwise (most likely by means of a #pragma or _Pragma).
> Documentation needs to be written for the #pragmas, but no other
> documentation is required (it might be nice to describe the
> additional guarantees but that is not required by the C
> standard).

It' the other way around - you need to describe first what the
actual behavior in absence of any pragmas is, and this needs to be a
firm specification, so the programmer doesn't need to read your mind
(or the source code to the compiler) to find out what you meant.
"But it is clear that..." would not be a specification; what is
clear to you may absolutely not be clear to anybody else.

This is also the only chance you'll have of getting this implemented
in one of the current compilers (and let's face it, if you want
high-quality code, you would need that; both LLVM and GCC
have taken an enormous amount of effort up to now, and duplicating
that is probably not going to happen).

> The point is to change the behavior of the compiler but
> still conform to the existing ISO C standard.

I understood that - defining things that are currently undefined.
But without a specification, that falls down.

So, let's try something that causes some grief - what should
be the default behavior (in the absence of pragmas) for integer
overflow?  More specifically, can the compiler set the condition
to false in

  int a;

....

  if (a > a + 1) {
  }

and how would you specify this in an unabigous manner?