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

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

On 08/01/2025 09:46, David Brown wrote:

On 07/01/2025 20:32, Julio Di Egidio wrote:

<snipped>

In particular, I am using C90, and compiling with
`gcc ... -ansi -pedantic -Wall -Wextra` (as I have
the requirement to ideally support any device).

 

People who say they want their code to run on anything are invariably wildly exaggerating.

 :)  I do have embedded, and FPGAs, and even transpiling to e.g. Wasm, etc. in mind, my overall idea for now simply being: as long as the device comes with a C compiler that is not too broken.  (I am also planning to distribute source files only: it also makes my life and coding so much easier, at the cost of not being able to "micro-optimize": where I am rather hoping that optimization can still come down the line if needed as an added pre or post processing step.)
 

Do you have experience with embedded programming (if so, what kind of devices)?

So, you might very well be right that "C90" isn't the best possible choice not even for my requirement, anyway I am at a pre-alpha stage, I am sure I will be tightening it up.
 

People who say they want to write strictly standards-conforming code, especially C90, so that it will run everywhere, misunderstand the relationship between the C standards and real-world tools.

 So, now that I have qualified it with "any device coming with a C compiler (that is not too broken)", would you think coding it in "ANSI C" makes some sense?
 

No.
There are basically two classes of small embedded devices - those that are usually programmed with gcc (and sometimes clang, and occasionally vastly expensive commercial tools), and those that are programmed using non-standard, limited and often expensive sort-of-C compilers.  For people using gcc, clang, Green Hills, Code Warrior, or other quality tools on a 16-bit or 32-bit microcontroller, C99 is not a problem.  C23 is not a problem for the most popular toolchain for the most popular microcontroller core.
For people using 8051, COP8, 68HC05, PIC16 or other long outdated brain-dead microcontrollers, you don't get standard C support at all. You program these in a device-specific variant of C full of extensions and extra restrictions - and the support is as close to the subset of C99 that I described as it is to standard C90.
Those kinds of microcontrollers are now pretty much only used in legacy hardware or where companies have too much code investment that cannot reasonably be ported to something modern.  (There are also a small number of niche use-cases.)  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.

I would say that the most portable language standard to use would be a subset of C99.  Avoid complex numbers, VLAs, and wide/multibyte characters, and it will be compilable on all but the most obscure compilers.  The use of <stdint.h> types make it far easier to write clear portable code while keeping good efficiency, and many C99 features let you write clearer, safer, and more efficient code.  C90 was probably a good choice for highly portable code 15-20 years ago, but not now. (Your use of "malloc" eliminates far more potential devices for the code than choosing C99 ever could.)

 Assuming I don't in fact care if and how well a compiler does its job (in fact my policy for now is: as long as it compiles with GCC with those flags), what is wrong with "malloc"?
 

If that's your starting assumption, then can we also assume that you don't expect anyone to use your code - certainly not on embedded systems?  People often place too much emphasis on code efficiency, but in small embedded systems, efficient code means smaller, cheaper and lower power microcontrollers which is almost always relevant.
The problem with malloc, however, is nothing to do with code efficiency.   Dynamic memory is generally banned, or at least highly restricted, in serious embedded programming as it is a huge reliability risk.  Most code on PC's can tolerate leaks - programs run for a bit, then stop and any leaked memory is recovered by the OS.  Embedded programs usually never stop.  PC programs can usually assume unlimited memory - embedded systems have very limited memory.  PC OS's have memory managers to re-arrange memory and see few issues with fragmentation - embedded systems are easily killed by heap fragmentation.  PC programs expect to have wildly varying timings - embedded systems are often real-time and do not do well with the non-deterministic timing you usually see with malloc/free implementations.
Sometimes dynamic memory usage is unavoidable, but good code for embedded systems uses alternative solutions where possible, and usually uses specialised pools rather than a generic heap with malloc.

When you have a function with a parameter of type "const T * p", this tells people reading it that the function will only read data via "p",

 Never mind, it's a private (static) method, so I am not "lying" to anybody: rather const and cast and almost everything in C is altogether something else...
 

You are lying to yourself - and that is not a good start.
Don't use const everywhere - use it where it is /helpful/.  Don't use casts unless you have very good reason for it - get the types and qualifiers correct from the start.  The article you referenced is rubbish.