Hacker News new | past | comments | ask | show | jobs | submit login

3k overhead where you’re trying to reduce from malloc is definitely a lot. One of my products have 8K total, not going to waste 3 of that replacing malloc.

I’m fairly happy that mirsa C forbids malloc. I can’t use it even if I wanted to, so I need to be more careful about how memory is used. Annoying at first, makes a lot of sense later on though.




It is quite possible (and it can be reasonable) to deviate from that rule. For example you could write a wrapper for malloc that only allows dynamic allocation in the initialization phase of your program. This can be useful to allocate memory for opaque-pointer-style types.


There are other ways to get chunks of memory separate from the stack - static uninitialized byte arrays.


Yeah, but it's nicer to define that kind of stuff in your linker script IMO, where sizes of large memory regions can be thought of holistically.


The parent post was talking about using malloc once at the start of the program, are you talking about defining that with your linker script?

Also if the goal is to get one chunk of memory with a single call, why use malloc at all? Why not use the direct memory mapping command?


I don't think he's talking about using malloc "once", he's talking about only using it during init. In practice you end calling it a bunch in that model, the last design I shipped like that ended up making a few hundred malloc (well new operator because this was C++) calls at init.

Under that system malloc/new was just a pointer bump, and an assert if there wasn't enough room. Free wasn't linked, and delete asserted. That heap region (or mine had several heaps that lived in different memory with different characteristics that could be specified with a new overload) is way easier to define in your linker.


Of course, but then we are back to memory pools.


What is the difference between allocating memory right when the program starts with malloc and using the same size in static unitialized byte arrays?

There are differences of course, but that memory can be used in the same way, and so memory pools are orthogonal to how the memory is aquired.


If you use modules with opaque pointers, the types are incomplete and therefore their size is not known outside of the module. You can either make the type visible (against the idea of opaque pointers), modify the module to allocate a fixed set of instances (somewhat against the open/closed principle), or you let the module use malloc to allocate memory for new instances.


Why would someone be doing this while trying to fit within the boundaries of the MISRA standard? Also what do you mean by module?


The rule you are referring to is a "required" (not a "mandatory") rule. You can deviate from it and still be MISRA-C compliant. People write deviations for all kinds of reasons. Here are some rationales for deviations: https://lars-lab.jpl.nasa.gov/JPL_Coding_Standard_C.pdf (Rule 5 on page 10 on malloc) https://www.keil.com/pack/doc/CMSIS/Core/html/coreMISRA_Exce...

The unit of reuse that defines the type, example: http://c-faq.com/struct/sd1.html


So your solution, in a thread about using a fixed amount of memory, is to do nothing different and let anything use the heap at any time because it might be possible in some cases to get it past MISRA standards? I'm not really sure of what you are trying to say, it seems you keep skewing further from the original discussion.


> I’m fairly happy that mirsa C forbids mallo

We wrote the system I mentioned above (128K of RAM, 256K of flash) without it, I agree, you can do everything you need without malloc when you're careful.

Unfortunately we had a third party dependency that required a malloc implementation to be able to run, so we had to implement a simple one.


>Unfortunately we had a third party dependency that required a malloc implementation to be able to run, so we had to implement a simple one.

We ran into the same thing. Some open source compression code I wanted to use had malloc, dumped it for something else that didn't. Luckily we found a protobuffers instance that didn't use malloc, that saved some time on a different project.

First thing I do now when looking at example or source we might want to use is a quick scan for malloc.


Unfortunately for us, this was a certified/approved EMV payment kernel, and about the only one we could get for our architecture, so we had to live with it.

Sometimes you don't get to choose or do it yourself, more's the pity!




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: