Questions regarding compiler warnings

Jean-Marc Lasgouttes lasgouttes at lyx.org
Wed Feb 12 21:30:42 UTC 2020


Le 12/02/2020 à 21:17, Stephan Witt a écrit :

> I don’t know what I’m talking about either. But,
> perhaps std::mem_fn is a possible replacement?
> 
> https://en.cppreference.com/w/cpp/utility/functional/mem_fn

I tried it, but it does not seems to work with std::not1.

JMarc

>>> 2. various memory leak warnings
>>> E.g. in GuiDocument::updateAvailableModules() - src/frontends/qt/GuiDocument.cpp, line 4474
>>> There is an allocation here:
>>> QStandardItem * catItem = new QStandardItem();
>>> and later an assignment here:
>>> catItem = fcats.first();
>>> See the attached nice picture…
>>> Should this be changed with the attached patch?
>>
>> The patch looks good to me.
> 
> Thanks, I’ll apply it then.
> 
>>> Similar problems are reported
>>> - in GuiLyXFiles::updateContents() with
>>> + QTreeWidgetItem * catItem - line 421
>>> + QTreeWidgetItem * subcatItem - line 447
>>> - in GuiToolbar::add() with
>>> + InsertTableWidget * iv - line 495 (here I’m not sure)
>>> 3. NULL pointer usage
>>> In GuiView::dispatchVC are different buffer pointer variables used.
>>> Sometimes there is an explicit check for NULL value.
>>> Sometimes there is an assertion with break or return for release builds.
>>> This looks inconsistent.
>>
>> This is inconsistent indeed.
>>
>>> 4. using uninitialized variable
>>> In GuiCompleter::asyncUpdatePopup the x and y position are declared w/o initial value.
>>> The virtual Inset::completionPosAndDim() method body is empty for common case.
>>> Only InsetText, InsetTabular, InsetMathMacro and InsetMathNest have an assignment.
>>> For all other insets (I didn't check if this is possible) the QRect results in garbage.
>>
>> Are these the insets that support completion? This is tested above, then. You can set position to 0 in order to please the compiler, I guess.
> 
> That’s the question indeed. And this is what I didn’t check.
> To avoid potential pitfalls the assignment of 0 is the save way.
> 
> Stephan
> 



More information about the lyx-devel mailing list