Avoid some crashes for bad "control-points" property

Avoid some crashes for bad "control-points" property

[thomasmorley651, 2019-04-25 21:29:18]

As always, I can't review C++.

So let me ask, how will LilyPond react seeing 5 or more control-points after
your patch?

[dak, 2019-04-25 23:27:29]

thomasmorley65@gmail.com writes:

> As always, I can't review C++.
>
> So let me ask, how will LilyPond react seeing 5 or more control-points
> after your patch?
>
> https://codereview.appspot.com/576610043/

It just ignores additional control points and replaces missing ones with
(0 . 0).

-- 
David Kastrup

[benko.pal, 2019-04-26 18:10:21]

LGTM

[hanwenn, 2019-04-26 18:24:49]

add a regression test?

[dak, 2019-04-26 18:49:03]

hanwenn@gmail.com writes:

> add a regression test?
>
> https://codereview.appspot.com/576610043/

I am not sure what the point of it would be.  This kind of bug may be
present elsewhere (and the regression test would not cover that) and it
is not likely to get reintroduced here since this code does not really
interact with other code.  And if you try running the test on older
versions for comparison, it will just crash.  The visual output is
meaningless since the condition it protects against does not have
meaning.

-- 
David Kastrup

[hanwenn, 2019-04-28 18:07:48]

On 2019/04/26 18:49:03, dak wrote:
> mailto:hanwenn@gmail.com writes:
> 
> > add a regression test?
> >
> > https://codereview.appspot.com/576610043/
> 
> I am not sure what the point of it would be.  This kind of bug may be
> present elsewhere (and the regression test would not cover that) and it
> is not likely to get reintroduced here since this code does not really
> interact with other code.  And if you try running the test on older
> versions for comparison, it will just crash.  The visual output is
> meaningless since the condition it protects against does not have
> meaning.

After many years of developing software, I'm skeptic of any bugfix without test,
but yes, maybe it's overkill in this case? In any case, I think there is a case
in slur-configuration.cc too

[dak, 2019-04-28 18:32:03]

hanwenn@gmail.com writes:

> On 2019/04/26 18:49:03, dak wrote:
>> mailto:hanwenn@gmail.com writes:
>
>> > add a regression test?
>> >
>> > https://codereview.appspot.com/576610043/
>
>> I am not sure what the point of it would be.  This kind of bug may be
>> present elsewhere (and the regression test would not cover that) and
> it
>> is not likely to get reintroduced here since this code does not really
>> interact with other code.  And if you try running the test on older
>> versions for comparison, it will just crash.  The visual output is
>> meaningless since the condition it protects against does not have
>> meaning.
>
> After many years of developing software, I'm skeptic of any bugfix
> without test, but yes, maybe it's overkill in this case? In any case, I
> think there is a case in slur-configuration.cc too

You are right, and I'll have to fix that.  Seems my grep-fu is
lacklustre.  But a regression test would not have found it.  This kind
of bug seems more amenable to review.  Regression tests would protect
against badly resolved merge conflicts reintroducing old code, of
course, but our workflow does not really make them probable: there are
just too few people working on too few things.

I mean, feel free to propose a regtest.

> https://codereview.appspot.com/576610043/

-- 
David Kastrup

[dak, 2019-04-28 19:14:53]

Fix slur configuration too (thanks, Han-Wen)

[thomasmorley651, 2019-04-30 21:23:20]

On 2019/04/28 19:14:53, dak wrote:
> Fix slur configuration too (thanks, Han-Wen)

I've downloaded you're patch. After playing around with it: all seems to work
nicely, no glitch found.
Thus, from testing:
LGTM