Path: ...!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: Fri, 13 Sep 2024 14:44:11 +0300
Organization: A noiseless patient Spider
Lines: 84
Message-ID: <20240913144411.00005866@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>
	<20240912142948.00002757@yahoo.com>
	<865xqzg63u.fsf@linuxsc.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Injection-Date: Fri, 13 Sep 2024 13:44:19 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="46d778e366440aa5cd4ab92ae9134f42";
	logging-data="867823"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+AbSEDqoygDgfLLjtbxCEcEeKUakE3vfc="
Cancel-Lock: sha1:WcXekrMMviHmw3US5fM8XC/R3r0=
X-Newsreader: Claws Mail 4.1.1 (GTK 3.24.34; x86_64-w64-mingw32)
Bytes: 4266

On Fri, 13 Sep 2024 04:12:21 -0700
Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:

> Michael S <already5chosen@yahoo.com> writes:
> 
> > 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?  
> 
> Because it's not needed, and would make things worse rather
> than better.  The result would be a bigger language but not
> a better language.
>

I beg to differ.
Yes, the standard would be bigger. And yes, few unimportant benchmarks
would run a little slower. But a job of compiler writers would be
simpler and less exciting (good thing!). The most importantly,
programming in resulting language would feel more predictable.

> > 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.  
> 
> Eliminating undefined behavior is not what's being asked for.
> These two questions are not the same.
> 
> > 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.  
> 
> Do you mean union rather than struct?  And do you mean bar.x[7]
> rather than bar.x[8]?  Surely no one would expect that storing
> into bar.x[8] should be well-defined behavior.
> 
> If the code were this
> 
>     union {
>       char x[8];
>       int  y;
>     } bar;
>     bar.y = 0;  bar.x[7] = 42;
> 
> and assuming sizeof(int) == 4, what is it that you think should
> be defined by the C standard but is not?  And the same question
> for a struct if that is what you meant.


No, I mean struct and I mean 8.
And I mean that a typical implementation-defined behavior would be
bar.y==42 on LE machines and bar.y==42*2**24 on BE machines. 
As it actually happens in reality with all production compilers.