Bug in Lyx 1.3.4 ?

[Stephan Witt]

Am 10.02.2020 um 22:01 schrieb Enrico Forestieri <forenr at lyx.org>:
> 
> On Mon, Feb 10, 2020 at 01:00:11PM +0100, Stephan Witt wrote:
> 
>> Am 07.02.2020 um 08:32 schrieb Enrico Forestieri <forenr at lyx.org>:
>>> 
>>> On Thu, Feb 06, 2020 at 10:36:30PM +0100, Stephan Witt wrote:
>>>> But some cases I’d like to point out:
>>>> 
>>>> InsetMathSpace::doDispatch() calls createInsetMath_fromDialogStr()
>>>> createInsetMath_fromDialogStr calls mathed_parse_cell()
>>>> mathed_parse_cell() calls Parser() with NULL buffer
>>>> 
>>>> Similar is the call to createInsetMath_fromDialogStr in
>>>> InsetMathRef::doDispatch() and InsetMathRef::changeTarget().
>>>> 
>>>> These look dangerous too, IMO. What do you think?
>>>> Do you know how to trigger this pieces of code?
>>> 
>>> It is hard to tell how dangerous they are. As said, in most cases the
>>> validity of the buffer member is checked before being used. So, having
>>> a null there is not troublesome for most code paths. However, it can
>>> bite in certain cases. In the case at hand, the buffer has always been
>>> null but, not being used in certain code paths, it has never been a
>>> problem.
>> 
>> I see a problem in Parser::parse1(). 
>> (The line numbers are in master as of today b8546139c8)
>> 
>> The code block below line 1983 uses the buffer member. 
>> At line 1986 and 1990 there is a NULL pointer check but at line 2086
>> the check is missing. This has to be corrected IMO.
> 
> Done at 536d476d.
> 
>> BTW, the value assigned to num_tokens in line 2092 is not used
>> because it’s defined local at line 2055 and used only in else block
>> at line 2105.
> 
> Those assignments were added at 1a6c5999 and I agree that they are
> superfluous. Removed at 926c846a.

Thank you for your review and the corrections.

Stephan