On Sat, May 04, 2024 at 08:54:15PM +0100, Gavin Smith wrote: > In my opinion it is an issue as it should not be possible to cause a > segfault purely with Perl code. If there is a segfault this points towards > a bug in XS/C code. If the user provides customization code that is purely > in Perl it would be very surprising for this to cause a segfault. The > customization API should be more robust than this.
It is not really a lack of robustness if it is done on purpose. Also it should not be so surprising as it would be some quite specific code that triggers a segfault. That being said, I agree that user-defined code being only Perl, even if in unusual situations, having a segfault would be unexpected. > Without knowing much about the customization API I don't know the best > way to protect against this kind of situation but some possibilities are > to check for null pointers when accessing cutomization variable values That's the easiest, the only issue is that it complexifies a little and slows the code. I'll do that. > in C, or to disable setting customization variables after this step: > "some customization variables are reset before the conversion to strings > if they are undef". If user code attempts to do this the program could > exit with an error. I prefer avoiding more complexity on that part. -- Pat
