Warning: mysqli::__construct(): (HY000/1203): User howardkn already has more than 'max_user_connections' active connections in D:\Inetpub\vhosts\howardknight.net\al.howardknight.net\includes\artfuncs.php on line 21
Failed to connect to MySQL: (1203) User howardkn already has more than 'max_user_connections' active connectionsPath: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: bart
Newsgroups: comp.lang.c
Subject: Re: A Famous Security Bug
Date: Sun, 24 Mar 2024 18:58:24 +0000
Organization: A noiseless patient Spider
Lines: 98
Message-ID:
References:
<20240320114218.151@kylheku.com>
<20240321211306.779b21d126e122556c34a346@gmail.moc>
<20240324185353.00002395@yahoo.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 24 Mar 2024 18:58:23 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="08d1ddc3ecb1dc9877ac945c1bf2bccd";
logging-data="567489"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX18Q+OABYSkqwIot7laSdlvV"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:tZsHFTDJJVqO7qI7P+kcTIqw9gs=
In-Reply-To: <20240324185353.00002395@yahoo.com>
Content-Language: en-GB
Bytes: 4769
On 24/03/2024 15:53, Michael S wrote:
> On Sat, 23 Mar 2024 21:21:58 +0000
> bart wrote:
>
>> 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 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
>> 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.
>>
>>
>
> #include
> #include
>
> int main(void)
> {
> char* p0 = (char*)((size_t)main & -(size_t)0x10000);
> printf("%c%c\n", p0[0], p0[1]);
> return 0;
> }
>
>
> That would work for small programs. Not necessarily for bigger
> programs.
>
I'm not sure how that works. Are EXE images always loaded at multiple of
64KB? I suppose on larger programs it could search backwards 64KB at a
time (although it could also hit on a rogue 'MZ' in program data).
My point however was whether C considered that p0[0] access UB because
it doesn't point into any C data object.
If so, it would make access to memory-mapped devices or frame-buffers,
or implementing things like garbage collectors, problematical.