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 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: 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> 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 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'. 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