I had segmentation faults from earlier versions of bombable in certain scenarios - for example in the first warthog invasion, I could never fly to the Golden Gate Bridge without generating a segmentation fault first. That went away by not using bombable.
I also happen to know that Nasal is able to trigger segmentation faults (I got a spectacular one by attempting to set the size of a vector to a negative number). My assumption is that this relates to internals like where in memory pointers actually (mis-)point - and the memory allocation may well be different between different GIT versions.
Yes, that's true - and it is actually fairly easy to trigger segfaults using Nasal. There is a whole number of ways. One pretty easy and "reliable" way would be to simply use the "break" expression outside loops. That should segfault reliably. On the other hand, such things are mostly related to the scripting interpreter itself, which is maybe not yet sufficiently "hardened".
To be honest, in scripting space there should really be no way for crashing the host application in the long run. No matter how poorly the script was coded, instead exceptions should be raised and caught, showing helpful error messages in the console (i.e. "break used outside loop"). This is especially true because Nasal scripts will usually be written by people who are not primarily developers.
So I really feel that this is more an issue of the underlying interpreter, than the end user scripts themselves.
No doubt, there are plenty of scripts that contain bugs or at least problematic code, the Nasal interpreter should better be hardened to provide useful diagnostic messages, instead of requiring careful code reviews.
Unfortunately, Nasal does not seem to be actively developed or maintained at the moment?
So even if I were to look into providing some patches, they would probably not be reviewed right away...
Given that, I think it's worth checking if bombable has still potentially dangerous code in.
Of course that'd be worthwhile, but on the other hand it is unrealistic to do this for all code.
It will really be easier to just accept that it's a work in progress and on going development.
Committing it to HEAD doesn't necessarily imply that it would be running by default.
That would be one easy way for dealing with this: add it to the base package, while disabling it by default - and maybe provide an option to enable it using the debug/development menu, that way everybody would know right away that this is an extension that is currently work in progress.
This could work pretty much like your local weather package, which is also runtime configurable to a certain degree.
So the bullet proof way would be to only load the script on demand, at runtime - by setting a listener property "load-bomable=true".
That would make it very easy for people to keep bombable in their base package, without also necessarily executing it.
The other important thing would be to really harden the Nasal interpreter itself...