Path: ...!news.misty.com!2.eu.feeder.erje.net!3.eu.feeder.erje.net!feeder.erje.net!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: Thu, 12 Sep 2024 14:29:48 +0300
Organization: A noiseless patient Spider
Lines: 42
Message-ID: <20240912142948.00002757@yahoo.com>
References: <vaqgtl$3526$1@dont-email.me>
	<memo.20240830090549.19028u@jgd.cix.co.uk>
	<2024Aug30.161204@mips.complang.tuwien.ac.at>
	<86r09ulqyp.fsf@linuxsc.com>
	<2024Sep8.173639@mips.complang.tuwien.ac.at>
	<p1cvdjpqjg65e6e3rtt4ua6hgm79cdfm2n@4ax.com>
	<2024Sep10.101932@mips.complang.tuwien.ac.at>
	<ygn8qvztf16.fsf@y.z>
	<2024Sep11.123824@mips.complang.tuwien.ac.at>
	<vbsoro$3ol1a$1@dont-email.me>
	<867cbhgozo.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Sep 2024 13:29:25 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="795ae34dc5508363080905c3d099c810";
	logging-data="248937"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EO4edsklU1c/saNVIxEid7Fw9/qoZ//M="
Cancel-Lock: sha1:tAq2Wb/9xl7SBz5szqBdVi73ceo=
X-Newsreader: Claws Mail 3.19.1 (GTK+ 2.24.33; x86_64-w64-mingw32)
Bytes: 2663

On Thu, 12 Sep 2024 03:12:11 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> BGB <cr88192@gmail.com> writes:
> 
> [...]
> 
> > Would be nice, say, if there were semi-standard compiler macros for
> > various things:
> >   Endianess (macros exist, typically compiler specific);
> >     And, apparently GCC and Clang can't agree on which strategy to
> > use. Whether or not the target/compiler allows misaligned memory
> > access; If set, one may use misaligned access.
> >   Whether or not memory uses a single address space;
> >     If set, all pointer comparisons are allowed.
> >
> > [elaborations on the above]  
> 
> I suppose it's natural for hardware-type folks to want features
> like this to be part of standard C.  In a sense what is being
> asked is to make C a high-level assembly language.  But that's
> not what C is.  Nor should it be.

Why not?
I don't see practical need for all those UBs apart from buffer
overflow. More so, I don't see the need for UB in certain limited
classes of buffer overflows.

struct {
 char x[8]
 int  y;
} bar;
bar.y = 0; bar.x[8] = 42;

IMHO, here behavior should be fully defined by implementation. And
in practice it is. Just not in theory.