Path: ...!2.eu.feeder.erje.net!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 16:22:13 -0000 (UTC)
Organization: To protect and to server
Message-ID: <vc71jj$6kc3$1@paganini.bofh.team>
References: <vaqgtl$3526$1@dont-email.me>   <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> <vc6jbk$5v9f$1@paganini.bofh.team> <20240915154038.0000016e@yahoo.com>
Injection-Date: Sun, 15 Sep 2024 16:22:13 -0000 (UTC)
Injection-Info: paganini.bofh.team; logging-data="217475"; 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: 5383
Lines: 95

Michael S <already5chosen@yahoo.com> wrote:
> On Sun, 15 Sep 2024 12:19:02 -0000 (UTC)
> Waldek Hebisch <antispam@fricas.org> wrote:
> 
>> 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'.  
> 
> Padding is another thing that should be Implementation Defined.
> I.e. compiler should provide complete documentation of its padding
> algorithms.
> In addition, some padding-related things can be defined by Standard
> itself. Not in this particular case, but, for example, it could be
> defined that when field of one integer type is immediately followed by
> another field of integer type with the same or narrower width then
> there should be no padding in-between.
> 
>> 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.
> 
> In general, only by means of fat pointers. 
> Fat pointers break existing ABIs.
> Also if fat pointers is what I want then I already have them in few
> mainstream languages where they are integrated much better than they
> will ever be in "checked C".

No.  When array declaration (or allocation) is visible adding checks
is trivial, so the problem is passing size information to functions.
As long as arrays have fixed sizes one can declare size of function
argument using qualifier "static", like in

void foo(int a[static 20]);

For arrays of variable size there are variably modified types.
Standard botched this, essentially saying that size info in
the prototype should be ignored, but in non-conforming mode
compiler may require size info and check it for correctness.

The point is that "checked program" can be compiled by standard
C complier.  And as long as all accesses are in bound "checked
code" is ABI compatible with unchecked one.  Of course,
if you take random C program, then with probablity close to 1
it will be rejected by checking compiler.  But if you pass
variable sized arrays the called routine needs _some_ way to
find out how big the array is.  And using vmt-s is a reasonable
way to pass size info.  To make it more useful vmt-s should be
beefed up, in particular cover pointer inside structures.
But even as it is now one can write useful checkable programs
in C.

-- 
                              Waldek Hebisch