Re: A Famous Security Bug

On 25/03/2024 00:39, Michael S wrote:

On Sun, 24 Mar 2024 23:07:44 +0000
bart <bc@freeuk.com> wrote:
 

On 24/03/2024 20:49, Keith Thompson wrote:

bart <bc@freeuk.com> writes:
[...]

But what people want are the conveniences and familiarity of a HLL,
without the bloody-mindedness of an optimising C compiler.

[...]
>
Exactly which people want that?
>
The evidence suggests that, while some people undoubtedly want that
(and it's a perfectly legitimate desire), there isn't enough demand
to induce anyone to actually produce such a thing and for it to
catch on. Developers have had decades to define and implement the
kind of language you're talking about.  Why haven't they?
  

Perhaps many settle for using C but using a lesser C compiler or one
with optimisation turned off.
>

 What is "lesser C compiler"?
Something like IAR ? Yes, people use it.

I am not sure how IAR's tools would count as a "lesser C compiler". They make very solid C tools for specific embedded targets.  And they have lots of the optimisations that some people get worked up about - including, IIRC, whole-program optimisations.

Something like TI? People use it when they have no other choice.

TI's C tools are a bit more varied in quality over their range of targets.  They have a particular bizarre non-conformity that they do not zero-initialise variables that have no explicit initialisation - a fact that is documented as a small note in the middle of the manual (for the two TI compiler manuals I have read).

20 years ago there were Diab Data, Kiel and few others. I didn't hear
about them lately.

I tried out Diab Data for the 68k some 25 years ago.  It was /way/ better than anything else around, but outside our budget at the time. People sometimes complain that type-based alias analysis, or optimisations based on the UB of signed integer overflow are somehow "new" optimisations by "evil" gcc developers designed to "win benchmarks" even though they "break" user code.  Diab Data was doing this kind of optimisation long before gcc.
I've never been a fan of Keil.  Perhaps it's because their main target was the 8051, an architecture that was outdated when it was introduced in 1980 and that survived decades longer than it should have.  But their compiler is only a "lesser C compiler" in the sense that the target is really bad for efficient C, so they have to have a lot of extra keywords and extensions to let people get decent results.  Thus you program in "Keil 8051 C", not standard C.  But the compiler does a /lot/ of optimisation, including very advanced whole-program optimisation.

Microchip, I'd guess, still has its own compilers for many of their
families, but that's because they have to. "Bigger" compilers dont want
to support this chips.

I think some of Microchip's old tools are the ones that I used that really could be called "lesser C compilers".  One I remember had support for structs, and support for arrays, but not for arrays of structs or structs containing arrays.

On the opposite edge of scale, IBM has compilers for their mainframes
and for POWER/AIX. The former are used widely. The later are quickly
losing to "bigger' compilers running on the same platform.
As to tcc, mcc, lccwin etc... those only used by hobbyists. Never by
pro. The only "lesser" PC-hosted PC-targeting C compilers that are used
by significant amount of pro developers are Intel and
Borland/Embarcadero, the later strictly for historical reasons.
Embarcadero switched their dev suits to "bigger" compiler quite a few
years ago, but some people like their old stuff. Well, may be, National
Instruments compiler still used? I really don't know.