Re: A Famous Security Bug

On 23/03/2024 16:51, David Brown wrote:

On 23/03/2024 12:26, bart wrote:

On 23/03/2024 07:26, James Kuyper 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?

>
That's up to you. The point is, C is NOT that language.

>
I'm asking which /mainstream/ HLL is lower level than C. So specifically ruling out assembly.
>
If there is no such choice, then this is the problem: it has to be C or nothing.

 How much of a problem is it, really?
 My field is probably the place where low level programming is most ubiquitous.  There are plenty of people who use assembly - for good reasons or for bad (or for reasons that some people think are good, other people think are bad).  C is the most common choice.
 Other languages used for small systems embedded programming include C++, Ada, Forth, BASIC, Pascal, Lua, and Micropython.  Forth is the only one that could be argued as lower-level or more "directly translated" than C.

Well, Forth is certainly cruder than C (it's barely a language IMO). But I don't remember seeing anything in it resembling a type system that corresponds to the 'i8-i64 u8-u64 f32-f64' types typical in current hardware. (Imagine trying to create a precisely laid out struct.)
It is just too weird. I think I'd rather take my chances with C.
 > BASIC, ..., Lua, and Micropython.
Hmm, I think my own scripting language is better at low level than any of these. It supports those low-level types for a start. And I can do stuff like this:
    println peek(0x40'0000, u16):"m"
    fun peek(addr, t=byte) = makeref(addr, t)^
This displays 'MZ', the signature of the (low-)loaded EXE image on Windows
Possibly it is even better than C; is this little program valid (no UB) C, even when it is known that the program is low-loaded:
    #include <stdio.h>
    typedef unsigned char byte;
    int main(void) {
        printf("%c%c\n", *(byte*)0x400000, *(byte*)0x400001);
    }
This works on DMC, tcc, mcc, lccwin, but not gcc because that loads programs at high addresses. The problem being that the address involved, while belonging to the program, is outside of any C data objects.