Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Robert Finch Newsgroups: comp.arch Subject: Re: Computer architects leaving Intel... Date: Sun, 15 Sep 2024 12:52:04 -0400 Organization: A noiseless patient Spider Lines: 75 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: 8bit Injection-Date: Sun, 15 Sep 2024 18:52:06 +0200 (CEST) Injection-Info: dont-email.me; posting-host="3222acdc67edaf9445b22785b52765d7"; logging-data="2391071"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1+J4+fOAqix6xGpG7EDDXczilehaSP0jqs=" User-Agent: Mozilla Thunderbird Cancel-Lock: sha1:zv6OxDBILQ4ndMbIIzosbwdPPpk= Content-Language: en-US In-Reply-To: Bytes: 4497 On 2024-09-15 12:09 p.m., David Brown wrote: > 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. >> > What about bit-fields in a struct? I believe they are usually packed. In case its for something like an I/O device.