Re: A Famous Security Bug

On 24/03/2024 14:52, David Brown wrote:

On 23/03/2024 22:21, bart wrote:

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.)

 Forth can be considered a typeless language - you deal with cells (or double cells, etc.), which have contents but not types.  And you can define structs with specific layouts quite easily.  (Note that I've never tried this myself - my Forth experience is /very/ limited, and you will get much more accurate information in comp.lang.forth or another place Forth experts hang out.)
 A key thing you miss, in comparison to C, is the type checking and the structured identifier syntax.
 In C, if you have :
      struct foo {
         int32_t x;
         int8_t y;
         uint16_t z;
     };
      struct foo obj;
      obj.x = obj.y + obj.z;
 then you access the fields as "obj.x", etc.  Your struct may or may not have padding, depending on the target and compiler (or compiler-specific extensions).  If "obj2" is an object of a different type, then "obj2.x" might be a different field or a compile-time error if that type has no field "x".
  In Forth, you write (again, I could be inaccurate here) :
      struct
     4 field >x
     1 field >y
     2 field >z
     constant /foo

<...>
Thanks. You've demonstrated perfectly why I would never use Forth. I'd rather write in assembly.
But what people want are the conveniences and familiarity of a HLL, without the bloody-mindedness of an optimising C compiler.

And note that although Forth is often byte-compiled very directly to give you exactly the actions you specify in the source code, it is also sometimes compiled to machine code - using optimisations.
 

>
It is just too weird. I think I'd rather take my chances with C.

 Forth does take some getting used to!
 

>
 > BASIC, ..., Lua, and Micropython.
>
Hmm, I think my own scripting language is better at low level than any of these.

 These all have one key advantage over your language - they are real languages, available for use by /other/ programmers for development of products.

My language exists. Anyone is welcome to reimplement elements of the design, since most script languages stink at low-level work or dealing with FFIs.
It is not necessary for me to provide a concrete implementation for others to use. But here's one expressed as C code for 64-bit Linux:
   https://github.com/sal55/langs/blob/master/qu.c
Build using:
   > gcc qu.c -oqu -lm -ldl -fno-builtin
or using:
   > tcc qu.c -o qu -lm -ldl -fdollars-in-identifiers
Run it like this:
   > ./qu -nosys hello
'hello.q' should contain something like like 'println "Hello, World"'.
The -nosys needed as it normally uses a WinAPI-based standard library.
It can't run the 'peek/MZ' example since EXE layouts on Linux are different, and, if using gcc, 0x400000 is an illegal address.
For something else, try creating test.q:
     type date = struct
         byte d,m
         u16 year
     end
    d := date(24,3,2024)
    println d, date.bytes
Run as './qu -nosys test'. I don't have docs however. BTW here is your Forth example:
     type foo1 = struct
         int32  x
         int8   y
         word16 z
     end
     type foo2 = struct $caligned
         int32  x
         int8   y
         word16 z
     end
     println foo1.bytes
     println foo2.bytes
There are two versions, one has no automatic padding, which is 7 bytes, and the other is 8 bytes in size.

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.
>

 I think you are being quite unreasonable in blaming gcc - or C - for generating code that cannot access that particular arbitrary address!

There were two separate points here. One is that a gcc-compiled version won't work because exe images are not loaded at 0x40'0000. The other was me speculating whether the access to 0x40'0000, even when valid memory for this process, was UB in C.