Re: What is wrong with malloc? (Was: So You Think You Can Const?)

On 08/01/2025 17:18, David Brown wrote:

On 08/01/2025 15:42, Julio Di Egidio wrote:

<snip>

  So you can be confident that almost anyone using your software in embedded systems will be using a 32-bit core - most likely an ARM Cortex-M, but possibly RISC-V.  And they will probably be using a toolchain that supports at least C17 (some people are still on older toolchains), whether it is gcc, clang, or commercial.   Certainly solid C99 support is guaranteed.  Everything else is niche, and no one will be using your software on niche systems.

Even my fridge should be able to run it...  I am writing a Prolog compiler, but more generally I'd be mostly writing algorithms-data structures things.
That said, one thing nobody has been explaining is why C99 is superior to C89/C90, except for some coding conveniences as far as I have read online: and I must say here that I do prefer the good old ways, including style-wise, in most cases...
But, more concretely, what I do not understand of your reply is, OK the plethora of architectures and compilers and languages, but I cannot even begin to cope with that, can I, and why should I when I can e.g. just have a "config" header (up to even a pre-preprocessor or whatever pre or post-transformations are needed) where I re-define "malloc" or even "int" as I like for a specific target?
The underlying idea being I won't care at all, I just pick a reasonable and reasonably standard variant of the C language as base, and I just distribute source code, the user must compile it.
-Julio