Hi,
I noticed that the automated cppcheck report script [1] no longer appears
to be running. When I look at the website that hosts the html reports [2],
then the last time the script was run was about mid- June. When I look at
the last automated email that was sent to this list [3] (to notify peo
The weekly updates:
http://document-foundation-mail-archive.969070.n3.nabble.com/CppCheck-Report-Update-td4241678.html
Reports ~7000 Errors, nearly all of which are false positives. By adding the
`--check-config` parameter to analyze includes, I discovered that cppcheck
cannot find any of our h
Hi,
I noticed that the weekly scheduled 'cppcheck report update' email
notification of the March 26 run dint appear on this (dev) mailing list.
Upon investigation it turns out that the job ran correctly, but that the
email message was held (Your message to LibreOffice awaits moderator
approval) u
Hi,
Are the cppcheck reports that are used to clean up the libreoffice code
generated automatically at this point ? Would there be any interest in
someone (me) scripting that ? I was informed that Julien Nabet is
generating these reports at the moment ? Like with the lcov-reports, I
would need
On Saturday 26 of April 2014, julien2412 wrote:
> Hello,
>
> Cppcheck reported this:
> [vcl/source/gdi/bitmap4.cxx:229]: (error) Deallocation of an auto-variable
> results in undefined behaviour
> 137 long(*pKoeff)[ 256 ] = new long[ 9 ][ 256 ];
> ...
> 229 delet
http://nabble.documentfoundation.org/Cppcheck-reports-Deallocation-of-an-auto-variable-results-in-undefined-behaviour-in-vcl-part-tp4106524.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreO
On 11/04/2014 16:13, Caolán McNamara wrote:
On Sat, 2014-04-05 at 16:06 -0700, julien2412 wrote:
Indeed we have:
296 else
297 {
298 if( aTmpBmpEx.IsAlpha() )
299 aTmpBmpEx = BitmapEx( aTmpBmp,
aTmpBmp
On 11/04/2014 13:20, Caolán McNamara wrote:
On Tue, 2014-04-08 at 20:58 +0200, Julien Nabet wrote:
...
I submitted a gerrit review 4.2:
https://gerrit.libreoffice.org/8897
I'm rather reluctant to change this in 4.2 without a specific known
problem that it fixes.
Ok then, I abandonned it.
Juli
On Sat, 2014-04-05 at 16:06 -0700, julien2412 wrote:
> Indeed we have:
> 296 else
> 297 {
> 298 if( aTmpBmpEx.IsAlpha() )
> 299 aTmpBmpEx = BitmapEx( aTmpBmp,
> aTmpBmpEx.GetAlpha() );
> 300
On Tue, 2014-04-08 at 20:58 +0200, Julien Nabet wrote:
> I've just pushed the fix on master. "make check" on top level was ok.
> Searching in git history during "make check", I found this commit from 2008:
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=5d20a47c3d50d0a88543b2355ec7340fc74
On 08/04/2014 13:10, Caolán McNamara wrote:
On Sat, 2014-04-05 at 15:51 -0700, julien2412 wrote:
Hello,
Cppcheck reported this
svx/source/unodraw/unomod.cxx
492 multiCondition style Expression is always false because 'else if'
condition matches previous condition at line 460.
Remark: It
On Sat, 2014-04-05 at 15:51 -0700, julien2412 wrote:
> Hello,
>
> Cppcheck reported this
> svx/source/unodraw/unomod.cxx
> 492 multiCondition style Expression is always false because 'else if'
> condition matches previous condition at line 460.
>
> Remark: It's a new kind of cppcheck detecti
}
see
http://opengrok.libreoffice.org/xref/core/vcl/source/gdi/impimage.cxx#298
Should the else if be:
else if( aTmpBmpEx.IsTransparent())
?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-else-if-condition-matches-previous-condition-vcl-tp4104270.html
Sent fr
{
494 nType = OBJ_TABLE;
495 }
see
http://opengrok.libreoffice.org/xref/core/svx/source/unodraw/unomod.cxx#460
Which one of this block is ok?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-else-if-condition-matches-previou
On 03/29/2014 01:49 PM, julien2412 wrote:
Cppcheck reported this:
sw/source/filter/ww8/ww8scan.cxx
5158memsetClass error Using 'memset' on class that contains a virtual
method.
5158memsetClass error Using 'memset' on class that contains a
reference.
5158memsetClass er
ould the second
line be removed each time, or something else should be done?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-Same-expression-on-both-sides-of-sc-module-tp4103436.html
Sent from the Dev mailing list archive at Nabble.com.
_
x27;memset' on class that contains a
'std::map'.
See
http://opengrok.libreoffice.org/xref/core/sw/source/filter/ww8/ww8scan.cxx#5155
False positive or real problem?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-Using-memset-on
On 24/03/2014 14:38, Caolán McNamara wrote:
On Sat, 2014-03-22 at 06:50 -0700, julien2412 wrote:
or should we do something completely different?
I'd just return early if the width or height is <= 0.
Though I think I'd move the SetLineColor/SetFillColor and "DrawRect" to
the top of the method so
On Sat, 2014-03-22 at 06:50 -0700, julien2412 wrote:
> or should we do something completely different?
I'd just return early if the width or height is <= 0.
Though I think I'd move the SetLineColor/SetFillColor and "DrawRect" to
the top of the method so 4 pixel high/wide windows still get blanked
Should line 78 be replaced by:
if( nHeight < 0 ) nHeight = 1;
or should we do something completely different?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-Division-by-zero-in-new-cxx-sfx2-module-tp4102613.html
Sent from the Dev mailing
them more frequently if necessary.
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-tp4028560p4094974.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
L
On 28/02/2013 12:58, Caolán McNamara wrote:
On Tue, 2013-02-12 at 08:13 -0800, julien2412 wrote:
544 if( nMaxWidth> aSize.Width() )
545 {
...
556 }
557 else
558 nMaxWidth = aSize.Width();
see
http://opengrok.libreoffice.org/xref/core/svtools/sou
On Tue, 2013-02-12 at 08:13 -0800, julien2412 wrote:
> 544 if( nMaxWidth > aSize.Width() )
> 545 {
> 546 Size aDlgSize = GetPathDialog()->GetOutputSizePixel();
> 547 GetPathDialog()->SetOutputSizePixel( Size(
> aDlgSize.Width()+nMaxWidth-aSize.Width(), aDlgSi
On 27/02/2013 00:20, Caolán McNamara wrote:
On Wed, 2012-12-19 at 15:00 -0800, julien2412 wrote:
Hello,
Cppcheck detected this into svx/source/svdraw/svdoedge.cxx
[svdoedge.cxx:1450]: (style) Variable 'pPt1' is assigned a value that is
never used.
[svdoedge.cxx:1453]: (style) Variable 'pPt4' is
On Wed, 2012-12-19 at 15:00 -0800, julien2412 wrote:
> Hello,
>
> Cppcheck detected this into svx/source/svdraw/svdoedge.cxx
> [svdoedge.cxx:1450]: (style) Variable 'pPt1' is assigned a value that is
> never used.
> [svdoedge.cxx:1453]: (style) Variable 'pPt4' is assigned a value that is
> never u
ext:
http://nabble.documentfoundation.org/Cppcheck-reports-an-2-assignments-which-isn-t-used-in-drawinglayer-module-tp4026316p4039584.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freed
On Fri, 2012-12-28 at 09:28 -0800, julien2412 wrote:
> Hello,
>
> Cppcheck reported these:
> [drawinglayer/source/primitive2d/sceneprimitive2d.cxx:196]: (style) Variable
> 'fViewSizeX' is assigned a value that is never used.
> [drawinglayer/source/primitive2d/sceneprimitive2d.cxx:197]: (style) Var
ince 2009-10-20 (see
http://cgit.freedesktop.org/libreoffice/core/commit/?id=2a0a3168f4354285e59dd79d4477a4199c2f773b)
Should we remove the lines 196 and 197 or is something lacking?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-fViewSizeX-fViewSizeY-are-as
Hello,
Cppcheck reports this:
svtools/source/dialogs/filedlg2.cxx
558 unreadVariable style Variable 'nMaxWidth' is assigned a value that is
never used.
544 if( nMaxWidth > aSize.Width() )
545 {
546 Size aDlgSize = GetPathDialog()->GetOutputSize
On Thu, 2012-12-27 at 06:30 -0800, julien2412 wrote:
> Hello,
>
> cppcheck reported this:
> [setup_native/source/win32/wintools/makecab/parseddf.c:381]: (error)
> Resource leak: ddf
> it's in the function ParseDdf
> fclose function seems to miss.
Fixed by your own
http://cgit.freedesktop.org/libr
Just for information, I updated the cppcheck reports (LO sources updated
today + cppcheck updated today).
I also created a first version to explain how to generate all this here:
https://wiki.documentfoundation.org/Development/Cppcheck
Julien
--
View this message in context:
http
ulien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-tp4028560p4028613.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedeskto
julien2412 wrote
> Also, I uploaded detailed reports, I meant all files concerned by cppcheck
> reports + index page with links on source files "htmlized"
> You'll find it there:
> http://serval2412.free.fr/cppcheck_reports.tar.bz2
> Just uncompress and browse
Hi
Hello,
Since I build master sources and use cppcheck (C/C++ static analyzer) quite
regularly, I thought someone could be interested by cppcheck reports.
So, I updated today my master sources and launched cppcheck (git updated
today) on the sources (except "sal" because of a freeze)
cking.
Any idea?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-an-2-assignments-which-isn-t-used-in-drawinglayer-module-tp4026316.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice
On 28/12/2012 14:43, Markus Mohrhard wrote:
2012/12/28 Julien Nabet:
On 28/12/2012 12:37, Ioan Radu wrote:
Hello Julien,
but it is used, it is an array
sal_uInt16 p1 = pPtr[0], p2 = pPtr[1];
while(pPtr[2]&& (pPtr[2] - p2 == 1))
Hi Loan,
Yes but what about after line 243? What's the use of
2012/12/28 Julien Nabet :
> On 28/12/2012 12:37, Ioan Radu wrote:
>
> Hello Julien,
> but it is used, it is an array
> sal_uInt16 p1 = pPtr[0], p2 = pPtr[1];
> while(pPtr[2] && (pPtr[2] - p2 == 1))
>
> Hi Loan,
>
> Yes but what about after line 243? What's the use of line 243 if "pPtr"
> isn't us
On 28/12/2012 12:37, Ioan Radu wrote:
Hello Julien,
but it is used, it is an array
*sal_uInt16 p1 = pPtr[0], p2 = pPtr[1];
while(pPtr[2] && (pPtr[2] - p2 == 1))*
Hi Loan,
Yes but what about after line 243? What's the use of line 243 if "pPtr"
isn't used afterwards?
Julien
_
is wrong here.
>
> Any idea?
>
> Julien
>
>
>
>
> --
> View this message in context:
> http://nabble.documentfoundation.org/Cppcheck-reports-an-assignment-which-isn-t-used-in-sd-source-ui-func-fupage-cxx-tp4026217.html
> Sent from the Dev mailing list archive at Nabb
ere.
Any idea?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-an-assignment-which-isn-t-used-in-sd-source-ui-func-fupage-cxx-tp4026217.html
Sent from the Dev mailing list archive at Nabble.com.
___
L
#x27;m not able to build on Windows but I think that adding this line:
fclose (ddf);
before this line:
return DDF_OK;
should be ok.
Someone to confirm?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-Resource-leak-in-setup-native-source-win3
On Thursday 20 of December 2012, julien2412 wrote:
> Thank you again Michael for your feedback.
>
> I know there are comments like FIXME, TODO in LO and certainly others but I
> don't know if there has been some formalism (not too much since it could
> be very quickly unproductive) about this.
>
>
be useful only if a basic report (with optionnaly some
stats) + detailed report (with hyperlinks) can be quickly generated from
Doxygen
Julien
PS : hope I was clear :-)
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-reassign-before-using-variable-in-sw-
On 20/12/12 00:26, julien2412 wrote:
> Hello,
>
> Cppcheck detected this:
> [sw/source/core/doc/tblafmt.cxx:1227] ->
> [sw/source/core/doc/tblafmt.cxx:1234]: (performance) Variable 'bRet' is
> reassigned a value before the old one has been used.
>1221 // Attention: We need to save a ge
lines before will be ok or
should something be added here?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-reassign-before-using-variable-in-sw-source-core-doc-tblafmt-cxx-tp4025241.html
Sent from the Dev mailing list archive at Nabble.com.
_
pPt3->Y()-=dy2/3;
and Opengrok:
http://opengrok.libreoffice.org/xref/core/svx/source/svdraw/svdoedge.cxx#1436
Either pPt1 and pPt4 assignations may really be removed or a change must be
done here.
Any idea?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Question-cp
On 05/28/2012 06:03 PM, julien2412 wrote:
[sal/osl/unx/file.cxx:1261] -> [sal/osl/unx/file.cxx:1261]: (style) Same
expression on both sides of '-'.
1257 if (nSize> 0)
1258 {
1259 c^= pData[0];
1260 pData += nSize;
1261
dation.org/Advice-needed-about-some-cppcheck-reports-tp3986408p3986586.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice
On 29/05/12 16:04, Lubos Lunak wrote:
> On Tuesday 29 of May 2012, Michael Stahl wrote:
>> On 28/05/12 18:03, julien2412 wrote:
>>> Same thing here :
>>> [sal/osl/w32/file.cxx:880] -> [sal/osl/w32/file.cxx:880]: (style) Same
>>> expression on both sides of '-'.
>>> 876 if (nSize > 0)
>>
On Tuesday 29 of May 2012, Michael Stahl wrote:
> On 28/05/12 18:03, julien2412 wrote:
> > Same thing here :
> > [sal/osl/w32/file.cxx:880] -> [sal/osl/w32/file.cxx:880]: (style) Same
> > expression on both sides of '-'.
> > 876 if (nSize > 0)
> > 877 {
> > 878
On 28/05/12 18:03, julien2412 wrote:
> Hello,
>
> Here are some cases found by cppcheck and I don't know what to do for them :
> [sw/source/ui/docvw/SidebarWin.cxx:796] ->
> [sw/source/ui/docvw/SidebarWin.cxx:794]: (style) Found duplicate branches
> for if and else.
>
> 791 const SwViewOp
) Same expression on
both sides of '-'.
267 if ( pLong[ nSwitch ] < 0 )
268 {
269 nRetValue -= nRetValue;
270 }
271 nRetValue /= 65536;
Any idea abou
Pushed on master
(http://cgit.freedesktop.org/libreoffice/core/commit/?id=39ba666f802db07e34eb848ad4e5f39ff85dd6ed)
(cf last post
http://nabble.documentfoundation.org/Cppcheck-reports-Same-expression-on-both-sides-of-on-basctl-module-tp3893608p3895210.html)
Thank you too for this one Lubos
http://nabble.documentfoundation.org/Cppcheck-reports-Same-expression-on-both-sides-of-on-basctl-module-tp3893608p3895210.html
Sent from the Dev mailing list archive at Nabble.com.
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/ma
On Sunday 08 of April 2012, julien2412 wrote:
> Hello,
>
> On master, cppcheck reported this :
> [basctl/source/basicide/bastypes.cxx:269] ->
> [basctl/source/basicide/bastypes.cxx:269]: (style) Same expression on both
> sides of '|'.
> Here are the lines :
> 266 BasicDockingWindow::BasicDockin
On Sunday 08 of April 2012, julien2412 wrote:
> Hello,
>
> On master repo, cppcheck reported this :
> [writerfilter/source/filter/ImportFilter.cxx:227] ->
> [writerfilter/source/filter/ImportFilter.cxx:227]: (style) Same expression
> on both sides of '||'
...
> So because of the 2 things noticed, I
cent, 1 month ago with commit
0e8eb19a53338c83dab7fe19e2f23bcaecd52077.
I've got not idea, if we can just remove WB_DOCKABLE or if it should be
replaced by another constant.
Any advice ?
Julien.
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-Same-exp
1" by "2" and have "SERVICE_NAME2" as second operand.
Perhaps I'm wrong or missed something, any idea ?
Julien.
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-Same-expression-on-both-sides-in-wri
On Sun, 2012-03-18 at 02:41 -0700, julien2412 wrote:
...
> Or should there be a default value (which one ?) on readNlrSRangeAddData ?
Let just do that. pushed now as 735a2cba30c55b5aff4883389f65255fb2d07458
I suspect these things might be at the bottom of an unused code trail
myself.
C.
__
On Mon, 2012-03-26 at 18:03 +0400, Ivan Timofeev wrote:
> Hi Julien,
>
> On 24.03.2012 03:26, julien2412 wrote:
> > Just for the update, is there anybody who could help about this ?
>
> I am not expert, too, but looking at vcl/source/gdi/sallayout.cxx:115
> and http://www.unicode.org/charts/PDF/
Hi Julien,
On 24.03.2012 03:26, julien2412 wrote:
Just for the update, is there anybody who could help about this ?
I am not expert, too, but looking at vcl/source/gdi/sallayout.cxx:115
and http://www.unicode.org/charts/PDF/UFF00.pdf I'd say that the
condition should be at least
(nChar >=
Just for the update, is there anybody who could help about this ?
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-Logical-conjunction-always-evaluates-to-false-in-text-gfx-cxx-tp3836511p3852917.html
Sent from the Dev mailing list archive at
julien2412 píše v Ne 18. 03. 2012 v 10:24 -0700:
> Hello,
>
> Cppcheck reports this in sdext module :
> [source/minimizer/optimizerdialog.cxx:276]: (warning) Logical disjunction
> always evaluates to true: nNewStep >= 0 || nNewStep <= 4
> Here is the line :
> if (
On 03/19/2012 10:25 PM, julien2412 wrote:
remarks :
- I replaced this
nChar>= 0xff62&& nChar< 0xff64
by this for readability
nChar == 0xff62 || nChar == 0xff63
- I added in the outer "if", "nChar == 0xffe3" because if not, "nChar ==
0xffe3" in the inner "if" is useless.
Is this patch
t;nChar == 0xffe3" because if not, "nChar ==
0xffe3" in the inner "if" is useless.
Is this patch ok ?
If yes, I can commit and push it on master.
Julien
--
View this message in context:
http://nabble.documentfoundation.org/Cppcheck-reports-Logical-conjunction-always-eva
On 03/18/2012 02:39 PM, julien2412 wrote:
Cppcheck reports this :
[generic/print/text_gfx.cxx:105]: (warning) Logical conjunction always
Would be helpful if you gave the complete path,
vcl/generic/print/text_gfx.cxx.
evaluates to false: nChar< 65380&& nChar>= 65387
Here
Hello,
Cppcheck reports this in sdext module :
[source/minimizer/optimizerdialog.cxx:276]: (warning) Logical disjunction
always evaluates to true: nNewStep >= 0 || nNewStep <= 4
Here is the line :
if ( ( nNewStep != mnCurrentStep ) && ( ( nNewStep <= MAX_STEP ) || (
nNewStep >
On 18/03/2012 15:07, Ivan Timofeev wrote:
Hi
On 18.03.2012 12:41, julien2412 wrote:
Just to make notice that Cppcheck reports "Same expression on both
sides of
'=='" on sc/source/core/data/dpitemdata.cxx, line 217. Here are the
lines :
...
216
Hi
On 18.03.2012 12:41, julien2412 wrote:
Just to make notice that Cppcheck reports "Same expression on both sides of
'=='" on sc/source/core/data/dpitemdata.cxx, line 217. Here are the lines :
...
216 if (mbStringInterned && r.mbStringInterned)
Hello,
Cppcheck reports this :
[generic/print/text_gfx.cxx:105]: (warning) Logical conjunction always
evaluates to false: nChar < 65380 && nChar >= 65387
Here are the lines :
103 if( ( nChar >= 0x3008 && nChar < 0x3019 && nChar != 0x3012 )
||
Hello,
Cppcheck reports this :
[source/filter/oox/formulaparser.cxx:2611]: (error) Uninitialized variable:
bIsRow
Here are the lines :
2608 bool BiffFormulaParserImpl::readNlrSAddrAddData( BiffNlr& orNlr,
BiffInputStream& rStrm, bool bRow )
2609 {
2610 bool bIsRow;
2611
Hello,
Just to make notice that Cppcheck reports "Same expression on both sides of
'=='" on sc/source/core/data/dpitemdata.cxx, line 217. Here are the lines :
199 bool ScDPItemData::IsCaseInsEqual(const ScDPItemData& r) const
200 {
201 if (meT
72 matches
Mail list logo
