Path: ...!npeer.as286.net!npeer-ng0.as286.net!3.eu.feeder.erje.net!feeder.erje.net!news.in-chemnitz.de!news.swapon.de!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: Michael S <already5chosen@yahoo.com>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Tue, 3 Sep 2024 10:44:21 +0300
Organization: A noiseless patient Spider
Lines: 59
Message-ID: <20240903104421.0000222a@yahoo.com>
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>
	<vb68c2$3833i$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Tue, 03 Sep 2024 09:43:38 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="6e614ad2247dbe6491c5f283904f9720";
	logging-data="3007847"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/wT36zKF9tL3WJ4ccpn7Jk9m8mzwPZYwk="
Cancel-Lock: sha1:GPbxJZfeSAbUqBKFQR5aExxV3cE=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 3976

On Tue, 3 Sep 2024 05:55:14 -0000 (UTC)
Thomas Koenig <tkoenig@netcologne.de> wrote:

> 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?