Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.arch
Subject: Re: Computer architects leaving Intel...
Date: Thu, 12 Sep 2024 16:34:31 +0200
Organization: A noiseless patient Spider
Lines: 54
Message-ID: <vbuu5n$9tue$1@dont-email.me>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Injection-Date: Thu, 12 Sep 2024 16:34:31 +0200 (CEST)
Injection-Info: dont-email.me; posting-host="8a3e6b38eefbb260d1d1fba6fb2b2745";
	logging-data="325582"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19EHwdAiW+ODCyAevtNmb9lhOvxN+tyGq4="
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.11.0
Cancel-Lock: sha1:nsHfqrysGlbZeoctpjOCbnz7GoU=
Content-Language: en-GB
In-Reply-To: <20240912142948.00002757@yahoo.com>
Bytes: 3496

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:
>>
>> [...]
>>
>>> 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.
> 

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?  And what is its "practical" definition? 
  My preference would be a hard compile-time error, but specifying that 
in the standards would force compilers to do more analysis and checking 
than the standards can reasonably enforce.

clang can warn on this - I am disappointed to see that gcc does not.