Path: ...!weretis.net!feeder6.news.weretis.net!feeder8.news.weretis.net!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart <bc@freeuk.com>
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sun, 24 Mar 2024 19:56:02 +0000
Organization: A noiseless patient Spider
Lines: 148
Message-ID: <utq0gh$i9hm$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>
 <utm06k$3glqc$1@dont-email.me> <utme8b$3jtip$1@dont-email.me>
 <utn1a0$3ogob$1@dont-email.me> <utnh5m$3sdhk$1@dont-email.me>
 <utpenn$dtnq$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 19:56:01 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="08d1ddc3ecb1dc9877ac945c1bf2bccd";
	logging-data="599606"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX1+WGOUEL+hinbrC3qlBL13T"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:yMQcHzsDIwjAD4GbVIwZAzyI3oQ=
Content-Language: en-GB
In-Reply-To: <utpenn$dtnq$1@dont-email.me>
Bytes: 5942

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.