Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Kaz Kylheku <433-929-6894@kylheku.com> Newsgroups: comp.lang.c Subject: Re: A Famous Security Bug Date: Sat, 23 Mar 2024 16:56:09 -0000 (UTC) Organization: A noiseless patient Spider Lines: 64 Message-ID: <20240323094244.435@kylheku.com> References: <20240320114218.151@kylheku.com> <20240321211306.779b21d126e122556c34a346@gmail.moc> <20240321131621.321@kylheku.com> <20240322083037.20@kylheku.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Injection-Info: dont-email.me; posting-host="bc8ead67574eda43cc8acb80cc4a36a2"; logging-data="3951151"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18/fBayGwq0RgwUECyXmlNlNAQFWSMKj6w=" User-Agent: slrn/pre1.0.4-9 (Linux) Cancel-Lock: sha1:6d5JsyeoQ3sQJRSgyAUNP10XWFM= Bytes: 4271 On 2024-03-23, David Brown wrote: > On 23/03/2024 10:20, Richard Kettlewell wrote: >> David Brown writes: >>> I have tried to explain the reality of what the C standards say in a >>> couple of posts (including one that I had not posted before you wrote >>> this one). I have tried to make things as clear as possible, and >>> hopefully you will see the point. >>> >>> If not, then you must accept that you interpret the C standards in a >>> different manner from the main compile vendors, as well as some "big >>> names" in this group. That is, of course, not proof in itself - but >>> you must realise that for practical purposes you need to be aware of >>> how others interpret the standard, both for your own coding and for >>> the advice or recommendations you give to others. >> >> Agreed that the ship has sailed on whether LTO is a valid optimization. >> But it’s understandable why someone might reach a different conclusion. > > I /do/ understand why Kaz thinks the way he does. I am just trying to > show that his interpretation is wrong, so that he can better understand > what is going on, and how to get the behaviour he wants. I'm just looking at what very plain, simple sentences are saying and taking it as-is. > I would be entirely happy to see clearer wording in the standards here, > or at least some footnotes saying what is allowed or not allowed. The wording isn't unclear in any way, though. What is needed is equally clear new wording which acknowledges the LTO model of program construction that is currently not described. That could be done without changing any of the existing wording. A new translation phase could be wedged between 7 and 8 stating that translation units may be optionally partitioned into subsets, and those subsets subject to further semantic analysis and translation, resulting in merged translation units. The standard currently presents a reference model that is squarely based on traditional technology. If you read the Rationale for C89, mostly they were concerned with how different models of linkage treat multiply defined identifers, and worked out a common specification that allows programs to be portable among those different linkage models. Ideas like LTO were not on the radar. > It would be unreasonable to expect them to guarantee the behaviour of > code under new standards when the code did not have guaranteed behaviour > under the old standards. Using TU boundaries to "get memset to work" > has never been guaranteed. memset is part of the language. It doesn't have to be a function in another translation unit that is reached via external linkage. The inclusion of can bring in an inline or at least static definition. Compilers have treated memset as if it were a built-in primitive. That is justified. It is not part of my topic about LTO. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca