Re: A Famous Security Bug

On 23/03/2024 01:09, Kaz Kylheku wrote:

On 2024-03-22, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:

bart <bc@freeuk.com> writes:

On 22/03/2024 17:14, James Kuyper wrote:

[...]

If you want to tell a system not only what a program must do, but
also how it must do it, you need to use a lower-level language than
C.

>
Which one?

>
Good question.

I have no answer here either.

>

I don't think anyone seriously wants to switch to assembly for the
sort of tasks they want to use C for.

One of the stated motivations for creating C was to save people from writing code in assembly!

>
Agreed.  What some people seem to be looking for is a language that's
about as portable as C, but where every language construct is required
to result in generated code that performs the specified operation.
There's a lot of handwaving in that description.  "C without
optimization", maybe?
>
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++;" ?  If the language had been created in the days of 8086 on DOS, perhaps it would have been defined as an atomic operation - and now doing this atomically on an AArch64 device would be extremely inefficient.
The big trouble with saying that the compiler should "do what I say" is that people have very different ideas about what they mean when they write things.  You either have to have quite high-level and abstract definitions about meanings and give compilers a fair amount of freedom when implementing them (thus you get high-level languages defined by behaviours on abstract machines - like C and just about every other programming language), or you have to tie it tightly to the target processor (and you get assembly), or the language designer, the compiler implementers and the programmers all have to think exactly the same way (which really means one-person languages, like Bart's).

 I think you can more or less get something like that with the following
strategy:
 - all memory accesses through pointers are performed as written.
- local variables are aggressively optimized into registers.
- basic optimizations:
   - constant folding, dead code elimination.
   - basic control flow ones: jump threading and the like.
   - basic data flow optimizations.
   - peephole, good instruction selection.
 In that environment, the way the programmer writes the code is the rest
of the optimization. Want loop unrolling? Write it yourself.
 

You might like to try to formalise this.  You won't be the first to attempt it.  But you might be the first to succeed, because no one (AFAIK) has managed it so far.