On Apr 3, 2011, at 2:17 PM, Werner LEMBERG wrote: > >>> I do. Any user program *must not* produce a segfault IMHO if fed >>> with user data, regardless of its origin. >> >> It it possible to make guile crash? > > Maybe. However, with `crash' I mean that lilypond aborts with a > segfault or something similar. It's quite easy to write an endless > loop or to exhaust the memory, but in the former case lilypond's guile > interpreter just hangs, and you should be able to abort with ^C, and > in the latter case lilypond should abort with a proper (Guile) error > message, and maybe we can add some measures to prevent unplausible > memory allocations. > >> Is there any way to write a guile program that gets a null pointer >> and then tries to use it? > > AFAIK, this is not possible in Guile since it is an interpreted > language. > > > Werner
I'll chime in here and say that I am still for applying my patch to beam quanting as a general fix. I agree that refining how stems meet up w/ noteheads is a better solution, but I think the bigger problem lies in the fact that beam quanting will result in a segfault any time it finds no good solutions, which arises here but could also arise in other unforeseeable ways. The best way to handle this, then, is a programming error followed by returning the best possible value which, in this case, is unquanted_y. New patch set at http://codereview.appspot.com/4339047 Cheers, MS _______________________________________________ lilypond-devel mailing list [email protected] http://lists.gnu.org/mailman/listinfo/lilypond-devel
