Closed bachp closed 9 years ago
I definitely agree, I personally haven't had to face this yet but I'll be getting there soon.
My rough plan was just to initialize a static lob-buffer to work from and enforce some max constants, if you have a more specific/restrictive environment then I'd love to accommodate that too, suggestions welcome :)
I was thinking alongside something like your js0n JSON parser. So work with a static allocated buffer and form there just return pointers to the underlying raw string.
I'm not sure if this is to simplistic as an approach and how this would work in the real world.
I need to do an audit of all lob_* calls for memory management in general soon, so I might end up adding something like this even sooner depending on what I learn in that process.
Some embedded libraries do support malloc. It's in avr-libc and in things like newlib. I don't think it's unreasonable to have a malloc implementation.
Now, there's the advantage of determinism w/o malloc. But before you go and rip them out I would recommend thinking about whether you are anti-malloc for the right reasons.
Yep, my goal isn't to rip out malloc, but to identify what parts of the code depend on mutable vs. immutable packets. I'm more concerned about being able to have very managed buffers for embedded, to know where to let it flex and how far, and it's all a bit murky right now w/ lob_t being used a lot.
all my experience so far is that anywhere embedded that telehash fits into has a malloc that is smarter than we would try to be...
For embedded micro-controllers it would be better to have a lob parser that doesn't need malloc etc.