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.