Bug in Lyx 1.3.4 ?

[Stephan Witt]

Am 06.02.2020 um 19:10 schrieb Enrico Forestieri <forenr at lyx.org>:
> 
> On Thu, Feb 06, 2020 at 06:37:43PM +0100, Stephan Witt wrote:
>> Am 06.02.2020 um 15:58 schrieb Enrico Forestieri <forenr at lyx.org>:
>>> 
>>> On Thu, Feb 06, 2020 at 01:52:15PM +0100, Pavel Sanda wrote:
>>>> On Thu, Feb 06, 2020 at 08:15:45AM +0100, Stephan Witt wrote:
>>>>> Am 06.02.2020 um 01:02 schrieb Richard Kimberly Heck <rikiheck at lyx.org>:
>>>>>> 
>>>>>> I assume this is an old bug? Or is it a new one?
>>>>> 
>>>>> I can reproduce something similar with 2.4.0 too. But I cannot reproduce with 2.2.4.
>>>> 
>>>> I can confirm it with Qt5 now.
>>>> Bisect leads to:
>>>> 
>>>> commit a2d181905a95b3bb983dac60f3d9603413a01f34
>>>> Author: Enrico Forestieri <forenr at lyx.org>
>>>> Date:   Tue Jun 25 22:23:51 2019 +0200
>>>> 
>>>>   Fix bug #11586
>>>> 
>>>>   Do not replace a latex command with the corresponding symbol
>>>>   in the unicodesymbols file unless it can be encoded in the
>>>>   document encoding.
>>> 
>>> That commit simply exposes the bug, which is the fact that the buffer
>>> member is not initialized. I think the patch by Stephan is correct.
>> 
>> That leads me to the question if there are more occurrences of this problem.
>> 
>> E.g. with 2.3.x in InsetMathMacro::attachArguments() the line
>> 
>> d->expanded_ = MathData(); 
>> 
>> could be better
>> 
>> d->expanded_ = MathData(d->definition_.buffer());
>> 
>> But in fact I don’t know if it is that simple pattern.
> 
> Uninitialized buffer members have been a plague in mathed in the past.
> You will see a lot of code like "buf && buf->something" to account for that.
> Sometimes not having a properly initialized buffer member can be
> irrelevant and sometimes not.
> 
> Nowadays I think it was spent some effort for properly initializing
> (and also updating when copy/pasting) the buffer pointer, so it makes
> sense to discover those (now presumably) corner cases and act on them,
> rather than adding the check for a null member. 
> 
> However, I would act only when we are sure it is an issue, rather than
> indiscriminately trying to initialize everything. In the particular
> case you report it may be that this initialization is performed later
> (note that I did not check, so I cannot be sure).
> 
> I would follow the old "if it ain't broke, don't fix it" approach.

I see, thanks for the answer.

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?

Stephan