Path: ...!2.eu.feeder.erje.net!feeder.erje.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: David Brown Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Sun, 15 Sep 2024 18:09:56 +0200 Organization: A noiseless patient Spider Lines: 72 Message-ID: References: <2024Aug30.161204@mips.complang.tuwien.ac.at> <86r09ulqyp.fsf@linuxsc.com> <2024Sep8.173639@mips.complang.tuwien.ac.at> <2024Sep10.101932@mips.complang.tuwien.ac.at> <2024Sep11.123824@mips.complang.tuwien.ac.at> <867cbhgozo.fsf@linuxsc.com> <20240912142948.00002757@yahoo.com> <20240915001153.000029bf@yahoo.com> <20240915154038.0000016e@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Date: Sun, 15 Sep 2024 18:09:57 +0200 (CEST) Injection-Info: dont-email.me; posting-host="0f814bd11c9fbe5b78942ec153f06f57"; logging-data="2364930"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/4/dc6vUbr+V9byvG8JsL34cN+GVDRVOk=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:RWeZksT20pFc3bTL25rylqdSvQ4= Content-Language: en-GB In-Reply-To: <20240915154038.0000016e@yahoo.com> Bytes: 4275 On 15/09/2024 14:40, Michael S wrote: > On Sun, 15 Sep 2024 12:19:02 -0000 (UTC) > Waldek Hebisch wrote: > >> Michael S wrote: >>> On Thu, 12 Sep 2024 16:34:31 +0200 >>> David Brown wrote: >>> >>>> On 12/09/2024 13:29, Michael S wrote: >>>>> On Thu, 12 Sep 2024 03:12:11 -0700 >>>>> Tim Rentsch wrote: >>>>> >>>>>> BGB 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. It is. > I.e. compiler should provide complete documentation of its padding > algorithms. They do. Or, they should. Often they are lazy and say "defined by the platform ABI". Really, it is only the alignments that are needed. C defines the minimum padding between members in a struct - you get the padding needed to ensure that members are correctly aligned. I don't think the C standards disallow additional padding, but it would be an extraordinarily strange implementation if there were anything more than this minimum padding. But I certainly wouldn't mind if the standards dictated this minimum padding, and then there would be nothing left to the implementation other than alignments. > 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. >