NativeCAM is dangerous.

User hermann1976 in the thread forum.linuxcnc.org/nativecam/59280-nativ...-transfer-to-control described strange behavior of LinuxCNC after generating a program with NativeCAM.
Partly out of desire to help, and partly out of curiosity, I started digging into the topic...
Although I wasn't able to reproduce the error described, but I found something much more important...

Well, there are no miracles in IT.
It is not possible for the same program to work correctly sometimes and then interrupt its operation by reporting an error.
Damage to the computer had to be ruled out because the error was repeatable and could not be due to random causes.
Since the reported error concerned going beyond the machine's working space, the first suspect was the offset subsystem.
And in fact, my default coordinate system is G54, and after running ncam.ngc it switched to G57 to return to G54 after finishing or interrupting.
This is so important that the operator may not notice it at all.
Although I didn't find G57 in ncam.ngc, there is a line #<_off_rot_coord_system>=57 (I removed the spaces). In turn, in the subroutines called from ncam.ngc there are lines G#<_off_rot_coord_system>, so it is it.
I didn't look any further in the code, I just decided to check if it was possible to take the program outside the working space by entering absurd offsets.

And this is where I really got scared.

Well, ncam.ngc overwrites the offset table !
He simply treats global data as his own private data.
After finishing the operation, it does not restore the previous data (which would not work anyway if the program was interrupted), it just leaves its garbage.

If the operator now executes another program that is using G57 that has executed correctly hundreds or thousands of times, he or she will get an unpleasant surprise, because the machine will work in other place than expected.

This is simply dangerous and therefore unacceptable.