Forum TI-Planet.org

Exceptions are disabled when I compile giac for calculators, it would eat too much code space. The best way I can imagine to make "shutdown" cleaner is to alloc a large memory block at startup and have malloc/free work inside this bloc, then just before the exit() call one can free the large memory block. But it's really not my domain, it's more the job of ndless devs to do that and that would be useful for every ndless app. I think it's the solution that zardam is using for the Numworks external apps heap (I don't remember how exactly, something related to brk or mmap).

It's not good practice to use manual memory management in modern C++ anyway - new/malloc ans delete/free shouldn't be used. Take a look at RAII and smart pointers instead for instance.

I don't understand why you posted that. Nobody will rewrite large working pieces of code just because there is a new feature for memory management in a language. Moreover, in the end, the new language feature must allocate memory on the heap, and we are back to the same problem, how does it interact with exit()? I really believe that it should be the job of ndless to handle malloc/free in a way compatible with exit() and transparent for ndless app developers.

I'm not saying that is has to be done for khicas, I know it would be too large of a refactor. It's rather more of a general advice for new developers making programs from scratch.
Also I don't think there's an issue at exit. The destructors will de-allocate the memory?

No, because they will not be called by exit, unlike what happens when you leave the application with return in the main function.

On most modern OSs, processes have their own private address spaces, which allocation of memory ends up adding page mappings to.
This is what malloc/free are implemented on top of.

The Nspire OS does not support separate address spaces, everything is shared. While there are separate memory pools, they are fixed in size on startup, so we can't just add one for each program as there's no unused space in RAM. It would be possible to allocate a block of memory from the main pool and create a new pool out of that, but if programs use less or need more of that, it breaks. So that's not a solution either.

Most programs do proper memory ownership tracking, so this hasn't really been an issue yet.

No, because they will not be called by exit, unlike what happens when you leave the application with return in the main function.

Destructors of global objects are called by exit, but not others: https://en.cppreference.com/w/cpp/utility/program/exit
For complete cleanup, just throw a custom exception and catch it in main.

Vogtinator a écrit:For complete cleanup, just throw a custom exception and catch it in main.

But that means enable exceptions, and that would increase the size of khicas significantly, right?

But that means enable exceptions, and that would increase the size of khicas significantly, right?

That highly depends on the code, just try it out and see for yourself. I guess that the added unwind tables might be ~1-2% of the current executable's code size.

Is there really any size issue on the Nspire though? Might be able to just enable exceptions with no impact anyway

It's a 20% increase of the tns file: 4101544 -> 4890227. Not clear it's worth the increase size.
An alternative could be keep track of the auto-shutdown in the most comon situations where auto-shutdown may happen, that is a getkey call inside the shell or editor or sheet.