Path: ...!news.nobody.at!news.swapon.de!news.in-chemnitz.de!3.eu.feeder.erje.net!feeder.erje.net!newsfeed.bofh.team!paganini.bofh.team!not-for-mail
From: Waldek Hebisch <antispam@fricas.org>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Sun, 15 Sep 2024 12:19:02 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vc6jbk$5v9f$1@paganini.bofh.team>
References: <vaqgtl$3526$1@dont-email.me>   <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> <vbuu5n$9tue$1@dont-email.me> <20240915001153.000029bf@yahoo.com>
Injection-Date: Sun, 15 Sep 2024 12:19:02 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="195887"; posting-host="WwiNTD3IIceGeoS5hCc4+A.user.paganini.bofh.team"; mail-complaints-to="usenet@bofh.team"; posting-account="9dIQLXBM7WM9KzA+yjdR4A";
User-Agent: tin/2.6.2-20221225 ("Pittyvaich") (Linux/6.1.0-9-amd64 (x86_64))
X-Notice: Filtered by postfilter v. 0.9.3
Bytes: 3616
Lines: 59

Michael S <already5chosen@yahoo.com> wrote:
> On Thu, 12 Sep 2024 16:34:31 +0200
> David Brown <david.brown@hesbynett.no> wrote:
> 
>> On 12/09/2024 13:29, Michael S wrote:
>> > On Thu, 12 Sep 2024 03:12:11 -0700
>> > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote:
>> >   
>> >> BGB <cr88192@gmail.com> writes:
>> 
>> I fully agree that C is not, and should not be seen as, a "high-level 
>> assembly language".  But it is a language that is very useful to 
>> "hardware-type folks", and there are a few things that could make it 
>> easier to write more portable code if they were standardised.  As it
>> is, we just have to accept that some things are not portable.
>> 
>> > 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.
>> >   
>> 
>> And how should that be defined?
> 
> 
> bar.x[8] = 42 should be defined to be the same as
>   char tmp = 42
>   memcpy(&bar.y, &tmp, sizeof(tmp));

That has two drawbacks: minor one that you need to know that
there are no padding between 'x' and 'y'.  Major drawback
is that it would forbid bounds checking for array accesses.
In code like above it is easy to spot out of bound access at
compile time.  Even with variable index compiler knows size
of 'x' so can insert bounds checking code (and AFAIK if you
insist leading compilers will do this).

More generally, assuming cooperating compiler modern C has enough
features to eliminate out of bounds array indexing.  More precisely,
I mean compiler which inserts bounds check where they are needed
and warns or rejects constructs that can not be checked.  I claim
that it is possible to write nontrivial programs in "checked C".
With change as above very important language construct would be
uncheckable.

BTW: If you need such behaviour you can get what you want by
using unions, so there is no need to break language for folks
that do not need this.

-- 
                              Waldek Hebisch