Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: David Brown <david.brown@hesbynett.no>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sun, 24 Mar 2024 14:42:00 +0100
Organization: A noiseless patient Spider
Lines: 47
Message-ID: <utpaj9$cvh3$1@dont-email.me>
References: <bug-20240320191736@ram.dialup.fu-berlin.de>
 <20240320114218.151@kylheku.com>
 <20240321211306.779b21d126e122556c34a346@gmail.moc>
 <utkea9$31sr2$1@dont-email.me> <utktul$35ng8$1@dont-email.me>
 <875xxdzvxj.fsf@nosuchdomain.example.com> <20240322170425.543@kylheku.com>
 <utmvq5$3o50v$1@dont-email.me> <utnca0$3r5uk$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 24 Mar 2024 13:42:01 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="af297f15341d352325f54a52911dae41";
	logging-data="425507"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1/VkY4NFqpLpg5DrMxW3B1aSWmG4xL8WHs="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:lZhxihJSKQjrshofzkmGj6tYTQM=
Content-Language: en-GB
In-Reply-To: <utnca0$3r5uk$1@dont-email.me>
Bytes: 3521

On 23/03/2024 20:58, bart wrote:
> On 23/03/2024 16:25, David Brown wrote:
>> On 23/03/2024 01:09, Kaz Kylheku wrote:
>>> On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> 
>>>> I'm not aware that any such language exists, at least in the mainstream
>>>> (and I've looked at a *lot* of programming languages).  I conclude that
>>>> there just isn't enough demand for that kind of thing.
>>
>> I think lack of demand combines with it actually being an extremely 
>> difficult task.
>>
>> Consider something as simple as "x++;" in C.  How could that be 
>> implemented?  Perhaps the cpu has an "increment" instruction.  Perhaps 
>> it has an "add immediate" instruction.  Perhaps it needs to load 1 
>> into a register, then use an "add" instruction.  Perhaps "x" is in 
>> memory. Some cpus can execute an increment directly on the memory 
>> address as an atomic instruction.  Some can do so, but only using 
>> specific (and more expensive) instructions.  Some can't do it at all 
>> without locking mechanisms and synchronisation loops.
>>
>> So what does this user of this mythical LLL expect when he/she writes 
>> "x++;" ?
> 
> This is not the issue the comes up in the OP (or the issue that was 
> assumed as I don't think the OP has clarified).
> 

That is trivially true.  I was picking a simple example and showing how 
difficult it is to try to define a language where "the compiler does 
exactly what I tell it to do".  If it is that difficult to define the 
programmer's precise expectation of the behaviour of "x++;" at the 
lowest level, how could we hope to do it with anything like the OP's case?

It sounds easy to make lists of expected behaviour, like Kaz did and 
like you no doubt have (at least in your head, if not written down) for 
your own low-level language.  Such lists are totally subjective, and 
thus inappropriate for general languages usable by a range of people for 
a range of tasks.

> There it is not about micro-managing the implementation of x++, but the 
> compiler deciding it isn't needed at all.
> 

First you have to decide /exactly/ what you mean by "x++;", before you 
can decide if it is valid to remove it or not.