Path: ...!news.mixmin.net!proxad.net!feeder1-2.proxad.net!usenet-fr.net!news.gegeweb.eu!gegeweb.org!nntp.terraraq.uk!.POSTED.tunnel.sfere.anjou.terraraq.org.uk!not-for-mail
From: Richard Kettlewell <invalid@invalid.invalid>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sat, 23 Mar 2024 09:20:43 +0000
Organization: terraraq NNTP server
Message-ID: <wwva5mpwbh0.fsf@LkoBDZeT.terraraq.uk>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
	<20240320114218.151@kylheku.com>
	<20240321211306.779b21d126e122556c34a346@gmail.moc>
	<20240321131621.321@kylheku.com> <utk1k9$2uojo$1@dont-email.me>
	<20240322083037.20@kylheku.com> <utkgd2$32aj7$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
Injection-Info: innmantic.terraraq.uk; posting-host="tunnel.sfere.anjou.terraraq.org.uk:172.17.207.6";
	logging-data="22858"; mail-complaints-to="usenet@innmantic.terraraq.uk"
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux)
Cancel-Lock: sha1:P/OnGPUI0bm4/aCKEzTz4bCH3tk=
X-Face: h[Hh-7npe<<b4/eW[]sat,I3O`t8A`(ej.H!F4\8|;ih)`7{@:A~/j1}gTt4e7-n*F?.Rl^
     F<\{jehn7.KrO{!7=:(@J~]<.[{>v9!1<qZY,{EJxg6?Er4Y7Ng2\Ft>Z&W?r\c.!4DXH5PWpga"ha
     +r0NzP?vnz:e/knOY)PI-
X-Boydie: NO
Bytes: 3394
Lines: 43

David Brown <david.brown@hesbynett.no> 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.

- Phase 7 says the tokens are “semantically analyzed and translated as a
  translation unit”.

- Phase 8 does not use either verb, “analyzed” or “translated”.

- At least two steps (in the abstract, as-if model) are explicitly
  happening in the “as a translation unit” level but not in any wider
  context.

- The result of those two steps (“translator output”) is than
  “collected”.

- Unless you somehow understand that “collected” implicitly includes
  further analysis and translation, it’s does not seem unnatural to
  conclude that many of the whole-program optimizations done by LTO
  implementations would be outside the spec.

This would be very easy to address, by replacing “collected” with a word
or phrase that makes clear that further analysis and translation can
happen outside the “as a translation unit” context.

Obviously this would violate the principle from the rationale that
existing code (that uses TU boundaries to get memset to “work”) is
important and existing implementations (LTO) are not, but C
standardization has never actually behaved as if that is true anyway.

-- 
https://www.greenend.org.uk/rjk/