Re: Fixes segfault in beam quanting. (issue4339047)

[address@hidden]

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