Re: [Libreoffice] [REVIEW] fdo#40701 Base crashes when "Find Record" button is clicked

[Lionel Elie Mamane]

On Mon, Sep 12, 2011 at 01:50:29AM +0200, Lionel Elie Mamane wrote:
> On Mon, Sep 12, 2011 at 01:07:53AM +0200, Eike Rathke wrote:
>> On Monday, 2011-09-12 00:25:51 +0200, Lionel Elie Mamane wrote:

>>> 0001-fdo-40701-DbGridControl-RemoveColumn-even-if-no-corr.patch
>>> fixes the root cause of the bug, which caused
>>> void DbGridControl::EnableHandle(sal_Bool bEnable)
>>> {
>>> RemoveColumn(0);
>>> m_bHandle = bEnable;
>>> InsertHandleColumn();
>>> }
>>> to misfunction: RemoveColumn(0) silently did not remove the column, so
>>> the call to InsertHandleColumn() added a second Handle Column, which
>>> confused the code in other places.

>> Hmm.. this

>> @@ -1723,11 +1723,12 @@ sal_uInt16 DbGridControl::AppendColumn(const 
>> XubString& rName, sal_uInt16 nWidth
>>  void DbGridControl::RemoveColumn(sal_uInt16 nId)
>>  {
>>  sal_uInt16 nIndex = GetModelColumnPos(nId);
>> -if (nIndex == GRID_COLUMN_NOT_FOUND)
>> -return;
>>  
>>  DbGridControl_Base::RemoveColumn(nId);
>>  
>> +if (nIndex == GRID_COLUMN_NOT_FOUND)
>> +return;
> +
>>  delete m_aColumns[ nIndex ];
>>  DbGridColumns::iterator it = m_aColumns.begin();
>>  ::std::advance( it, nIndex );


>> now attempts to unconditionally remove any column nId. I don't know if
>> and how the underlying code handles such cases,

> Good point; it handles it well

>> but a safer approach would be to still check for a valid index and
>> additionally the handle column case, so

>> if (nIndex != GRID_COLUMN_NOT_FOUND || nId == 0)
>> DbGridControl_Base::RemoveColumn(nId);

>> might be better suited.

> I don't think it makes a real difference either way.

After having slept on it, no. The situation is that there are *two*
column sequences:

1) BrowseBox::pCols

2) DbGridControl::m_aColumns

The call to "DbGridControl_Base::RemoveColumn(nId)" does "remove
column from BrowseBox::pCols, if it is present there";
DbGridControl_base is a class derived from BrowseBox.

The rest of the code of the function does "remove column from
DbGridControl::m_aColumns, if it is present there".

Tour version implements the logic is "if the column is not in
DbGridControl::m_aColumns, then do not remove it from
BrowseBox::pCols, except for the known case if nId==0".

>From a general robustness principle, my version seems preferable. For
example, it makes this code work as intended:

uInt16 nId = ...;
try
{
addColumTo_pCols(nId, ...);

// some code that may throw
(...)

addColumnTo_m_aColumns(nId, ...);
}
catch (...)
{
removeColumn(nId);
throw;
}

And actually, now that this is clear in my mind, I think the patch
should be, for more clarity:

 void DbGridControl::RemoveColumn(sal_uInt16 nId)
 {
+DbGridControl_Base::RemoveColumn(nId);
+
 sal_uInt16 nIndex = GetModelColumnPos(nId);
 if (nIndex == GRID_COLUMN_NOT_FOUND)
 return;
 
-DbGridControl_Base::RemoveColumn(nId);
-
 delete m_aColumns[ nIndex ];
 DbGridColumns::iterator it = m_aColumns.begin();
 ::std::advance( it, nIndex );


This makes it more clear that the call to
DbGridControl_Base::RemoveColumn and the result of
GetModelColumnPos(nId) are meant to be completely independent.

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [Review] [PUSHED] simple bugfix (too simple ?)

[julien2412]

Commited and pushed on master.

Thanks !

--
View this message in context: 
http://nabble.documentfoundation.org/Review-simple-bugfix-too-simple-tp3327833p3328796.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

Re: [Libreoffice] [PUSHED 3.4] fix javaldx call in oosplash

[Norbert Thiebaud]

On Sun, Sep 11, 2011 at 6:37 PM, Eike Rathke  wrote:
> Hi Lionel,
>
> On Monday, 2011-09-12 01:17:32 +0200, Lionel Elie Mamane wrote:
>
>> Looks good & low-risk to me, pushed.
>
> You were 8 minutes faster than me ;)
>
> Please attribute the proper author in commits, either use git am or stg
> import -m or some such to read in the patch from a mail, or explicitly
> set the author with git commit --author=...

Indeed,
or, when the proposed patch is not in a suitable git-format-patch
format,  git apply --index + git commit --author  -s -m 

>
> Also, a Signed-off-by line on 3-4 branch commits is nice to have (or do
> we even require it?),

yes, normally for a 3.x branch we require one sign-off (which is why
rene did not push it himself directly)... and when we get to
pre-release candidate (3.X.Y) we require 3 sign-off
(the author of the patch is not considered a sign-off).

Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] libreoffice.boldandbusted.com: Updated cppcheck

[Jesse Adelman]

P.P.S. Alas, I forgot to patch cppcheck-htmlreport with my local
changes, so next run the page will return to its former sortable glory.

-- 
Jesse Adelman
Senior Systems Shepherd
ilikelinux Consulting/Bold and Busted, LLC
http://ilikelinux.com/ http://boldandbusted.com/
Brisbane, CA
Tel: (415) 656-4480
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] libreoffice.boldandbusted.com: Updated cppcheck

[Jesse Adelman]

Hi *,

I updated cppcheck to the "latest" from the project's git repo. Hope it
works well. :) The first run against this version of cppcheck is in
progress; you should see the page updated in ~2 hours.

http://libreoffice.boldandbusted.com/

BTW, the entire git pull + cppcheck + htmlreport run against LO's git is
taking about 2 hours these days. Because I'm using the excellent fcron
(http://fcron.free.fr/) to handle the jobs, there is little time wasted
between runs.

I have some hope that I'll have time next weekend to get Jenkins's
cppcheck module setup, so I can get those nice graphs of "cppcheck
elements" (style, error, etc.) over time. We'll see.

Happy coding! :)

Cheers,
Jesse

P.S. Here's the nice info Gentoo gives me regarding the cppcheck git clone:

 * GIT NEW clone -->
 *repository:   git://github.com/danmar/cppcheck.git
 *at the commit:19928e26d1c93f789435b0b608f119498471ff5d
 *branch:   master
 *storage directory:"/usr/portage/distfiles/git-src/cppcheck"

-- 
Jesse Adelman
Senior Systems Shepherd
ilikelinux Consulting/Bold and Busted, LLC
http://ilikelinux.com/ http://boldandbusted.com/
Brisbane, CA
Tel: (415) 656-4480
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] fdo#40701 Base crashes when "Find Record" button is clicked

[Lionel Elie Mamane]

On Mon, Sep 12, 2011 at 01:07:53AM +0200, Eike Rathke wrote:
> On Monday, 2011-09-12 00:25:51 +0200, Lionel Elie Mamane wrote:

>> 0001-fdo-40701-DbGridControl-RemoveColumn-even-if-no-corr.patch
>> fixes the root cause of the bug, which caused
>> void DbGridControl::EnableHandle(sal_Bool bEnable)
>> {
>> RemoveColumn(0);
>> m_bHandle = bEnable;
>> InsertHandleColumn();
>> }
>> to misfunction: RemoveColumn(0) silently did not remove the column, so
>> the call to InsertHandleColumn() added a second Handle Column, which
>> confused the code in other places.

> Hmm.. this

> @@ -1723,11 +1723,12 @@ sal_uInt16 DbGridControl::AppendColumn(const 
> XubString& rName, sal_uInt16 nWidth
>  void DbGridControl::RemoveColumn(sal_uInt16 nId)
>  {
>  sal_uInt16 nIndex = GetModelColumnPos(nId);
> -if (nIndex == GRID_COLUMN_NOT_FOUND)
> -return;
>  
>  DbGridControl_Base::RemoveColumn(nId);
>  
> +if (nIndex == GRID_COLUMN_NOT_FOUND)
> +return;
> +
>  delete m_aColumns[ nIndex ];
>  DbGridColumns::iterator it = m_aColumns.begin();
>  ::std::advance( it, nIndex );


> now attempts to unconditionally remove any column nId. I don't know if
> and how the underlying code handles such cases,

Good point; it handles it well:

void BrowseBox::RemoveColumn( sal_uInt16 nItemId )
{
// Spaltenposition ermitteln
sal_uInt16 nPos = GetColumnPos(nItemId);
if ( nPos >= ColCount() )
// nicht vorhanden
return;
(...)
}

and

sal_uInt16 BrowseBox::GetColumnPos( sal_uInt16 nId ) const
{
DBG_CHKTHIS(BrowseBox,BrowseBoxCheckInvariants);

for ( sal_uInt16 nPos = 0; nPos < pCols->size(); ++nPos )
if ( (*pCols)[ nPos ]->GetId() == nId )
return nPos;
return BROWSER_INVALIDID;
}

and

#define BROWSER_INVALIDID   USHRT_MAX

> but a safer approach would be to still check for a valid index and
> additionally the handle column case, so

> if (nIndex != GRID_COLUMN_NOT_FOUND || nId == 0)
> DbGridControl_Base::RemoveColumn(nId);

> might be better suited.

This does the same as long as the class invariant of "one column in
BrowseBox::pCols for each DbGridControl::m_aColumns and vice-versa,
except for the handle column" holds. OTOH, if the invariant is broken
in that the column is in BrowseBox::pCols, but not in
DbGridControl::m_aColumns, my version actually "fixes" that, while
yours does not :) OTOH, your version is indeed more prudent in that it
avoids to do anything if the situation is not as it expects (invariant
broken).

I don't think it makes a real difference either way.

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PUSHED 3.4] fix javaldx call in oosplash

[Eike Rathke]

Hi Lionel,

On Monday, 2011-09-12 01:17:32 +0200, Lionel Elie Mamane wrote:

> Looks good & low-risk to me, pushed.

You were 8 minutes faster than me ;)

Please attribute the proper author in commits, either use git am or stg
import -m or some such to read in the patch from a mail, or explicitly
set the author with git commit --author=...

Also, a Signed-off-by line on 3-4 branch commits is nice to have (or do
we even require it?), in this case you're committer and reviewer in one
person so you'd add yourself to that, again with git am --signoff or stg
import --sign or git commit --signoff

Thanks
  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PUSHED 3.4] fix javaldx call in oosplash

[Lionel Elie Mamane]

On Sun, Sep 11, 2011 at 03:58:14PM +0200, Rene Engelhard wrote:

> see http://bugs.debian.org/637829. Basically oosplash relies
> on ../ure/bin being present, which isn't always the case. E.g.
> on Debian we have the whole ure in /usr/lib/ure.

> We should use the proper mechanism (like basis-link/ure-link.
> I already committed it to master, OK for -3-4?

Looks good & low-risk to me, pushed.

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [REVIEW] fdo#40701 Base crashes when "Find Record" button is clicked

[Eike Rathke]

Hi Lionel,

On Monday, 2011-09-12 00:25:51 +0200, Lionel Elie Mamane wrote:

> 0001-fdo-40701-DbGridControl-RemoveColumn-even-if-no-corr.patch
> fixes the root cause of the bug, which caused
> void DbGridControl::EnableHandle(sal_Bool bEnable)
> {
> RemoveColumn(0);
> m_bHandle = bEnable;
> InsertHandleColumn();
> }
> to misfunction: RemoveColumn(0) silently did not remove the column, so
> the call to InsertHandleColumn() added a second Handle Column, which
> confused the code in other places.

Hmm.. this

@@ -1723,11 +1723,12 @@ sal_uInt16 DbGridControl::AppendColumn(const XubString& 
rName, sal_uInt16 nWidth
 void DbGridControl::RemoveColumn(sal_uInt16 nId)
 {
 sal_uInt16 nIndex = GetModelColumnPos(nId);
-if (nIndex == GRID_COLUMN_NOT_FOUND)
-return;
 
 DbGridControl_Base::RemoveColumn(nId);
 
+if (nIndex == GRID_COLUMN_NOT_FOUND)
+return;
+
 delete m_aColumns[ nIndex ];
 DbGridColumns::iterator it = m_aColumns.begin();
 ::std::advance( it, nIndex );


now attempts to unconditionally remove any column nId. I don't know if
and how the underlying code handles such cases, but a safer approach
would be to still check for a valid index and additionally the handle
column case, so

if (nIndex != GRID_COLUMN_NOT_FOUND || nId == 0)
DbGridControl_Base::RemoveColumn(nId);

might be better suited.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Mi first very little patch

[Lionel Elie Mamane]

On Sun, Sep 11, 2011 at 10:04:52PM +0200, CaStarCo wrote:
> I've created a second (very little too) patch to reduce the scope of a
> variable.

> --- a/sal/osl/w32/file_dirvol.cxx
> +++ b/sal/osl/w32/file_dirvol.cxx
> @@ -60,7 +60,6 @@ extern "C" BOOL TimeValueToFileTime(const TimeValue 
> *cpTimeVal, FILETIME *pFTime

Thank you for your contribution to LibreOffice, it is most
welcome. Looking at that function in that file, it needs a more
thorough cleanup, and maybe other functions in that file and/or in
other files in the same directory; see
http://msdn.microsoft.com/en-us/library/ms724284%28v=VS.85%29.aspx, in
particular:

 It is not recommended that you add and subtract values from the
 FILETIME structure to obtain relative times. Instead, you should copy
 the low- and high-order parts of the file time to a ULARGE_INTEGER
 structure, perform 64-bit arithmetic on the QuadPart member, and copy
 the LowPart and HighPart members into the FILETIME structure.

 Do not cast a pointer to a FILETIME structure to either a
 ULARGE_INTEGER* or __int64* value because it can cause alignment
 faults on 64-bit Windows.

It would be best to look at every place that FILETIME is used in that
directory.

Just in case you want to volunteer for that cleanup :)

When you send a patch, could you please confirm the patch is licensed
under MPL1.1/LGPLv3+? To make things easier, you can do a one-time
blanket "all my patches" thing if you wish, sort of common to do that.


Best Regards,

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [Review] simple bugfix (too simple ?)

[Eike Rathke]

Hi Julien,

On Sunday, 2011-09-11 22:53:45 +0200, Julien Nabet wrote:

> @@ -124,7 +124,7 @@ void createSettingsStructure(xmlDoc * document,
> bool * bNeedsSave)
>  }
>  if (bFound)
>  {
> -bNeedsSave = false;
> +*bNeedsSave = false;
>  return;
>  }
>  //We will modify this document
> 
> Too simple to be true ? I prefer asking instead of having missed a
> "special C++ trick".

There's no special trick involved here ;-)
The only caller of createSettingsStructure() passes a bool* and one line
below your diff there's also

//We will modify this document
*bNeedsSave = true;

> (As usual, I can of course commit and push it on master if it's ok).

Do so. Btw, apparently the current code leads to the document not being
saved at this place if it should.. hopefully it's saved later anyway.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [Review] simple bugfix (too simple ?)

[Lionel Elie Mamane]

On Sun, Sep 11, 2011 at 10:53:45PM +0200, Julien Nabet wrote:

> Cppcheck detected this :
> core/jvmfwk/source/elements.cxx
> 127assignBoolToPointererrorAssigning bool value to
> pointer (converting bool value to address)

> Here is a simple patch :


> Too simple to be true ? I prefer asking instead of having missed a
> "special C++ trick".

Looks good to me. Commit!

(The incorrect code did not lead to any actual bug because the
function is only called with a pointer to a bool of value false and
the setting to true happened nicely with dereference; obviously, it
was a bug waiting to happen as soon as some code somewhere calls the
function with a pointer to a true bool...)

-- 
Lionel
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEW] fdo#40701 Base crashes when "Find Record" button is clicked

[Lionel Elie Mamane]

The attached patches are backport to 3.4 of my master commits
b71d12fbfdd4aad0b576645a0d7bbf71d1da7a3a
0ef7ce4a234c6649dcca219b96185acb7634fe34
1b6310433280ae4e8439dcbf17dfa763bf2826cc

They are related to fdo#40701.

0001-fdo-40701-DbGridControl-RemoveColumn-even-if-no-corr.patch
fixes the root cause of the bug, which caused
void DbGridControl::EnableHandle(sal_Bool bEnable)
{
RemoveColumn(0);
m_bHandle = bEnable;
InsertHandleColumn();
}
to misfunction: RemoveColumn(0) silently did not remove the column, so
the call to InsertHandleColumn() added a second Handle Column, which
confused the code in other places.

0002-FmXGridPeer-getByIndex-Error-checking-of-pGrid-GetMo.patch
fixes the reason the bug was a crasher instead of just "broken
feature, nothing happens when "Find Record" button is clicked".

0003-Don-t-touch-handle-when-setting-property-Enabled.patch
is not per se directly related to fdo#40701, but it looks like a
(subtle) bug waiting to be discovered: The code enables/disables the
handle when the property "Enabled" is set, according to the value of
the "Enabled" property, while should do so (only) when setting the
property RecordMarker, according to its value. If one looks at the
commit message of 448cd2de7919401a0a84cd6e5dd5ede276ddf28e and its
diff, it looks rather strongly like this was *not* an intended change,
as that commit looks like a janitorial commit that did not intend to
change behaviour of the code.

As such, my case for
0003-Don-t-touch-handle-when-setting-property-Enabled.patch
in libreoffice-3-4 is much weaker, but I'm throwing it in and let's
see what you guys think of it.

-- 
Lionel
>From f6a89eaf00a6230ddbfbb8bc5a09cc0f32b519af Mon Sep 17 00:00:00 2001
From: Lionel Elie Mamane 
Date: Mon, 12 Sep 2011 00:00:33 +0200
Subject: [PATCH 1/3] fdo#40701: DbGridControl::RemoveColumn even if no corresponding Model column

That case crops up when nId==0 i.e. the Handle column
---
 svx/source/fmcomp/gridctrl.cxx |5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/svx/source/fmcomp/gridctrl.cxx b/svx/source/fmcomp/gridctrl.cxx
index bb666bc..aec3738 100644
--- a/svx/source/fmcomp/gridctrl.cxx
+++ b/svx/source/fmcomp/gridctrl.cxx
@@ -1723,11 +1723,12 @@ sal_uInt16 DbGridControl::AppendColumn(const XubString& rName, sal_uInt16 nWidth
 void DbGridControl::RemoveColumn(sal_uInt16 nId)
 {
 sal_uInt16 nIndex = GetModelColumnPos(nId);
-if (nIndex == GRID_COLUMN_NOT_FOUND)
-return;
 
 DbGridControl_Base::RemoveColumn(nId);
 
+if (nIndex == GRID_COLUMN_NOT_FOUND)
+return;
+
 delete m_aColumns[ nIndex ];
 DbGridColumns::iterator it = m_aColumns.begin();
 ::std::advance( it, nIndex );
-- 
1.7.2.5

>From 9e34b69c3db910c51a910c8be3df9c740541fb12 Mon Sep 17 00:00:00 2001
From: Lionel Elie Mamane 
Date: Sun, 11 Sep 2011 23:40:09 +0200
Subject: [PATCH 2/3] FmXGridPeer::getByIndex: Error checking of pGrid->GetModelColumnPos(nId) call

Fixes crash of fdo#40701, but not broken feature
---
 svx/source/fmcomp/fmgridif.cxx |3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/svx/source/fmcomp/fmgridif.cxx b/svx/source/fmcomp/fmgridif.cxx
index 3080d77..a4146a9 100644
--- a/svx/source/fmcomp/fmgridif.cxx
+++ b/svx/source/fmcomp/fmgridif.cxx
@@ -2442,6 +2442,9 @@ Any FmXGridPeer::getByIndex(sal_Int32 _nIndex) throw( IndexOutOfBoundsException,
 // get the list position
 sal_uInt16 nPos = pGrid->GetModelColumnPos(nId);
 
+if ( nPos == GRID_COLUMN_NOT_FOUND )
+return aElement;
+
 DbGridColumn* pCol = pGrid->GetColumns().at( nPos );
 Reference< ::com::sun::star::awt::XControl >  xControl(pCol->GetCell());
 aElement <<= xControl;
-- 
1.7.2.5

>From 17f18e8d57639f000565cdb57468b983f2412474 Mon Sep 17 00:00:00 2001
From: Lionel Elie Mamane 
Date: Sun, 11 Sep 2011 23:44:41 +0200
Subject: [PATCH 3/3] Don't touch handle when setting property Enabled

Handle enabling/disabling is controlled by property RecordMarker,
not by property Enabled.

Source of the error is most probably a copy/paste error in
commit 448cd2de7919401a0a84cd6e5dd5ede276ddf28e
Author: Frank Schoenheit [fs] 
Date:   Tue Nov 23 11:38:49 2010 +0100
---
 svx/source/fmcomp/fmgridif.cxx |1 -
 1 files changed, 0 insertions(+), 1 deletions(-)

diff --git a/svx/source/fmcomp/fmgridif.cxx b/svx/source/fmcomp/fmgridif.cxx
index a4146a9..222b2b5 100644
--- a/svx/source/fmcomp/fmgridif.cxx
+++ b/svx/source/fmcomp/fmgridif.cxx
@@ -2090,7 +2090,6 @@ void FmXGridPeer::setProperty( const ::rtl::OUString& PropertyName, const Any& V
 {
 sal_Bool bValue( sal_True );
 OSL_VERIFY( Value >>= bValue );
-pGrid->EnableHandle( bValue );
 
 // Im DesignModus nur das Datenfenster disablen
 // Sonst kann das Control nicht mehr konfiguriert werden
-- 
1.7.2.5

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/list

Re: [Libreoffice] git account request

[Olivier Hallot]

Hi Marco

Do you mind to write some lines on how you succeded to have the big 
source code set under Eclipse CDT?


Thanks in advance

Olivier

Em 11-09-2011 17:14, Marco escreveu:


Hi Thorsten,
I completed the switch to the new unified repository, everything
built smoothly and I also succeeded in configuring eclipse cdt with
the new big source code set. Now before bringing my project forward
I'm going to request a git repo account through Freedesktop bugzilla
site. I created a new feature branch named "feature/svg-anims" that
I'll push as soon as I commit something new.

Cheers,
Marco




--
Olivier Hallot
Founder, Steering Commitee Member - The Document Foundation
Voicing the enterprise needs
LibreOffice translation leader for Brazilian Portuguese
+55-21-8822-8812

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [Review] simple bugfix (too simple ?)

[Julien Nabet]

Hello,

Cppcheck detected this :
core/jvmfwk/source/elements.cxx
127assignBoolToPointererrorAssigning bool value to pointer 
(converting bool value to address)


Here is a simple patch :

diff --git a/jvmfwk/source/elements.cxx b/jvmfwk/source/elements.cxx
index bb5cf62..b54e380 100644
--- a/jvmfwk/source/elements.cxx
+++ b/jvmfwk/source/elements.cxx
@@ -124,7 +124,7 @@ void createSettingsStructure(xmlDoc * document, bool 
* bNeedsSave)

 }
 if (bFound)
 {
-bNeedsSave = false;
+*bNeedsSave = false;
 return;
 }
 //We will modify this document

Too simple to be true ? I prefer asking instead of having missed a 
"special C++ trick".


Julien.
(As usual, I can of course commit and push it on master if it's ok).
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] git account request

[Thorsten Behrens]

Marco wrote:
> Now before bringing my project forward I'm going to request a git
> repo account through Freedesktop bugzilla site.
>
Hey Marco, sure, go for it -
http://www.freedesktop.org/wiki/AccountRequests has the details.

Cheers,

-- Thorsten


pgpqx8mPyDtim.pgp
Description: PGP signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Mi first very little patch

[Norbert Thiebaud]

On Sun, Sep 11, 2011 at 2:39 PM, CaStarCo  wrote:
> Hello, I've created a very little patch to solve the next CppCheck warning (
> http://libreoffice.boldandbusted.com/464.html ) . (This is my first patch in
> LibreOffice)

Welcome to libreoffice and thanks for the patch.

Unfortunately you got the parenthses wrong...

--- a/sw/source/core/crsr/findfmt.cxx
+++ b/sw/source/core/crsr/findfmt.cxx
@@ -61,7 +61,7 @@ sal_Bool SwPaM::Find( const SwFmt& rFmt, SwMoveFn fnMove,
 while( !bFound &&
 0 != ( pNode = ::GetNode( *pPam, bFirst, fnMove, bInReadOnly )))
 {
-if( 0 != ( bFound = pNode->GetFmtColl() == &rFmt ))
+if( 0 != ( ( bFound = pNode->GetFmtColl() ) == &rFmt ))

here bFound is a boolean. The intent is to check if pNode->getFmtCol()
is equal to &rFmt. the original author decided to store that test in
boFound (although that is not needed here, because if boFound is true
(ie != 0) then we break out of the while loop and never need to test
boFound again...


so

the minimum patch should have been

+if( 0 != ( bFound = (pNode->GetFmtColl()  == &rFmt )


a more 'involved' clean-up could have been (considering that th
function already has more than one return point)

diff --git a/sw/source/core/crsr/findfmt.cxx b/sw/source/core/crsr/findfmt.cxx
index 7a548c3..5b29686 100644
--- a/sw/source/core/crsr/findfmt.cxx
+++ b/sw/source/core/crsr/findfmt.cxx
@@ -37,7 +37,6 @@
 sal_Bool SwPaM::Find( const SwFmt& rFmt, SwMoveFn fnMove,
 const SwPaM *pRegion, sal_Bool bInReadOnly  )
 {
-sal_Bool bFound = sal_False;
 sal_Bool bSrchForward = fnMove == fnMoveForward;
 SwPaM* pPam = MakeRegion( fnMove, pRegion );

@@ -58,10 +57,9 @@ sal_Bool SwPaM::Find( const SwFmt& rFmt, SwMoveFn fnMove,

 sal_Bool bFirst = sal_True;
 SwCntntNode* pNode;
-while( !bFound &&
-0 != ( pNode = ::GetNode( *pPam, bFirst, fnMove, bInReadOnly )))
+while( (pNode = ::GetNode( *pPam, bFirst, fnMove, bInReadOnly )) != 0)
 {
-if( 0 != ( bFound = pNode->GetFmtColl() == &rFmt ))
+if( pNode->GetFmtColl() == &rFmt )
 {
 // wurde die FormatCollection gefunden, dann handelt es sich auf
 // jedenfall um einen SwCntntNode !!
@@ -75,11 +73,13 @@ sal_Bool SwPaM::Find( const SwFmt& rFmt, SwMoveFn fnMove,
 GetMark()->nContent = 0;
 if( !bSrchForward ) // rueckwaerts Suche?
 Exchange(); // SPoint und GetMark tauschen
+delete pPam;
+return sal_True;
 break;
 }
 }
 delete pPam;
-return bFound;
+return sal_False;
 }

 Norbert
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] git account request

[Marco]

Hi Thorsten,
I completed the switch to the new unified repository, everything
built smoothly and I also succeeded in configuring eclipse cdt with
the new big source code set. Now before bringing my project forward
I'm going to request a git repo account through Freedesktop bugzilla
site. I created a new feature branch named "feature/svg-anims" that
I'll push as soon as I commit something new.

Cheers,
Marco


--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Mi first very little patch

[CaStarCo]

Ups :( , my patch introduced a bug, it's not valid.

2011/9/11 CaStarCo 

> Hello, I've created a very little patch to solve the next CppCheck warning
> ( http://libreoffice.boldandbusted.com/464.html ) . (This is my first
> patch in LibreOffice)
>
>


-- 
- Per la llibertat del coneixement -
- Per la llibertat de la ment...   -
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Mi first very little patch

[CaStarCo]

I've created a second (very little too) patch to reduce the scope of a
variable.
From 7c434fd7af9892fee7b120e00a135d01693265af Mon Sep 17 00:00:00 2001
From: Andreu Correa Casablanca 
Date: Sun, 11 Sep 2011 22:01:10 +0200
Subject: [PATCH] Reduced the scope of a variable in core/sal/osl/w32/file_dirvol.cxx

---
 sal/osl/w32/file_dirvol.cxx |3 ++-
 1 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/sal/osl/w32/file_dirvol.cxx b/sal/osl/w32/file_dirvol.cxx
index b6dc002..e5852eb 100644
--- a/sal/osl/w32/file_dirvol.cxx
+++ b/sal/osl/w32/file_dirvol.cxx
@@ -60,7 +60,6 @@ extern "C" BOOL TimeValueToFileTime(const TimeValue *cpTimeVal, FILETIME *pFTime
 SYSTEMTIME  BaseSysTime;
 FILETIMEBaseFileTime;
 FILETIMEFTime;
-__int64 localTime;
 BOOLfSuccess = FALSE;
 
 BaseSysTime.wYear = 1970;
@@ -77,7 +76,9 @@ extern "C" BOOL TimeValueToFileTime(const TimeValue *cpTimeVal, FILETIME *pFTime
 
 if ( SystemTimeToFileTime(&BaseSysTime, &BaseFileTime) )
 {
+__int64 localTime;
 __int64 timeValue;
+
 localTime=cpTimeVal->Seconds*(__int64)1000+cpTimeVal->Nanosec/100;
 *(__int64 *)&FTime=localTime;
 fSuccess = 0 <= (timeValue= *((__int64 *)&BaseFileTime) + *((__int64 *) &FTime));
-- 
1.7.4.1

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] Mi first very little patch

[CaStarCo]

Hello, I've created a very little patch to solve the next CppCheck warning (
http://libreoffice.boldandbusted.com/464.html ) . (This is my first patch in
LibreOffice)
From b7646c6393ae557c9f3e11ea68651fca0589360c Mon Sep 17 00:00:00 2001
From: Andreu Correa Casablanca 
Date: Sun, 11 Sep 2011 21:28:37 +0200
Subject: [PATCH] Clarified the CppCheck report: http://libreoffice.boldandbusted.com/464.html

---
 sw/source/core/crsr/findfmt.cxx |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/sw/source/core/crsr/findfmt.cxx b/sw/source/core/crsr/findfmt.cxx
index 7a548c3..0567c6e 100644
--- a/sw/source/core/crsr/findfmt.cxx
+++ b/sw/source/core/crsr/findfmt.cxx
@@ -61,7 +61,7 @@ sal_Bool SwPaM::Find( const SwFmt& rFmt, SwMoveFn fnMove,
 while( !bFound &&
 0 != ( pNode = ::GetNode( *pPam, bFirst, fnMove, bInReadOnly )))
 {
-if( 0 != ( bFound = pNode->GetFmtColl() == &rFmt ))
+if( 0 != ( ( bFound = pNode->GetFmtColl() ) == &rFmt ))
 {
 // wurde die FormatCollection gefunden, dann handelt es sich auf
 // jedenfall um einen SwCntntNode !!
-- 
1.7.4.1

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEW] cherry-pick to 3-4: fix fdo#39485 Data corruption for matrices

[Eike Rathke]

Hi,

Please review and cherry-pick to 3-4
http://cgit.freedesktop.org/libreoffice/core/commit/?id=90e489f068d09aaaf46ab15d35091198ed84bed1

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39485

Thanks
  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] SAL_DEPRECATED (was: [Libreoffice-commits] .: sal/inc)

[Stephan Bergmann]

On 09/09/2011 09:45 PM, Stephan Bergmann wrote:

On 09/07/2011 02:56 PM, Bjoern Michaelsen wrote:

sal/inc/sal/types.h | 16 
1 file changed, 16 insertions(+)

New commits:
commit de290e726ed2aa5a4c007d61a7db1042c45d43db
Author: Bjoern Michaelsen
Date: Wed Sep 7 12:37:08 2011 +0200

introduce SAL_DEPRECATED macro


Is it true that __declspec must go before the return type for MSC (i.e.,
that the return type must go within the SAL_DEPRECATED argument)? Then,
SAL_DEPRECATED suffers from the multiple-argument template return type
unpleasantness described at
.
:(


It turns out SAL_DEPRECATED can be simplified after all, see 
.


-Stephan
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [PATCH] build system patches

[Peter Foley]

On Wed, 7 Sep 2011, Stephan Bergmann wrote:

> On 09/07/2011 10:28 AM, Norbert Thiebaud wrote:
> > On Wed, Sep 7, 2011 at 1:47 AM, Stephan Bergmann
> wrote:
> > > On 09/07/2011 03:14 AM, Norbert Thiebaud wrote:
> > > >
> > > > On Tue, Sep 6, 2011 at 5:32 PM, Peter Foley
> wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > Here are some patches for various problems I encountered while
> building
> > > > > libreoffice.
> > > >
> > > > 0001-libcrnf.a
> > > >
> > > > is that a consequence of
> > > >
> > > >
> http://cgit.freedesktop.org/libreoffice/core/commit/?id=291b85778669b4e4e2
> 76faab22add9d0e80046df
> > > > ?
> > >
> > > I would suspect so.  That one apparently also broke my Mac OS X build,
> but I
> > > did not yet find time to look into it.  (What fits somewhat nicely is
> that
> > > it shows up in a chroot build.  My impression from the Mac OS X build
> > > failure logs was that building moz now inadvertently takes certain
> libraries
> > > from the system, instead of from (now) intended to be built in nss vs.
> > > (before) being built as part of building moz itself, and those
> libraries are
> > > not present, on Mac OS X nor in a chroot.  Something like that.)
> >
> > humm.. and that would also explain the 0002- patch (well not the patch
> > but the reason that motivated it)
> > I think you are right, and maybe the commit above should be revisited
> > in light of these... (I means instead of papering over the symptom :-)
> > )
> 
> Yes, definitely dig in and try to understand the root cause, than fixing the
> symptoms.  Putting kendy as the author of the above changeset on cc.
> 
> -Stephan
> ___
> LibreOffice mailing list
> LibreOffice@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/libreoffice
> 

ping?

I'm still using my libcrmf.a patch (attached) to work around this build 
breakage.

PeterFrom 60694dd3e47402326bf53aa1d0573f898a64ec4d Mon Sep 17 00:00:00 2001
From: Peter Foley 
Date: Mon, 5 Sep 2011 21:38:47 -0400
Subject: [PATCH 1/4] libcrmf.a

---
 nss/makefile.mk |2 +-
 nss/prj/d.lst   |1 +
 2 files changed, 2 insertions(+), 1 deletions(-)

diff --git a/nss/makefile.mk b/nss/makefile.mk
index aa242bd..75ebb21 100644
--- a/nss/makefile.mk
+++ b/nss/makefile.mk
@@ -91,7 +91,7 @@ MACOS_SDK_DIR*=$(MACDEVSDK)
 .ENDIF # "$(EXTRA_CFLAGS)"!=""
 .ENDIF # "$(OS)"=="MACOSX"
 
-OUT2LIB=mozilla$/dist$/out$/lib$/*$(DLLPOST)
+OUT2LIB=mozilla$/dist$/out$/lib$/*$(DLLPOST) mozilla$/dist$/out$/lib$/libcrmf.a
 
 OUT2BIN=config$/nspr-config mozilla$/security$/nss$/nss-config
 
diff --git a/nss/prj/d.lst b/nss/prj/d.lst
index cc36eb1..a887c36 100644
--- a/nss/prj/d.lst
+++ b/nss/prj/d.lst
@@ -25,6 +25,7 @@ mkdir: %_DEST%\lib\sqlite
 ..\%__SRC%\lib\libsmime3.* %_DEST%\lib\libsmime3.*
 ..\%__SRC%\lib\libsoftokn3.* %_DEST%\lib\libsoftokn3.*
 ..\%__SRC%\lib\libssl3.* %_DEST%\lib\libssl3.*
+..\%__SRC%\lib\libcrmf.a %_DEST%\lib\libcrmf.a
 
 ..\%__SRC%\lib\libsqlite3.* %_DEST%\lib\sqlite\libsqlite3.*
 ..\%__SRC%\lib\*.lib %_DEST%\lib
-- 
1.7.6.1

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEW][PATCH] fix javaldx call in oosplash

[Rene Engelhard]

Hi,

see http://bugs.debian.org/637829. Basically oosplash relies
on ../ure/bin being present, which isn't always the case. E.g.
on Debian we have the whole ure in /usr/lib/ure.

We should use the proper mechanism (like basis-link/ure-link.
I already committed it to master, OK for -3-4?

diff --git a/desktop/unx/source/start.c b/desktop/unx/source/start.c
index 85e2e28..3ad641c 100755
--- a/desktop/unx/source/start.c
+++ b/desktop/unx/source/start.c
@@ -845,7 +845,7 @@ exec_javaldx (Args *args)
 rtl_uString_newFromAscii( &pApp, "file://" );
 rtl_uString_newConcat( &pApp, pApp, args->pAppPath );
 pTmp = NULL;
-rtl_uString_newFromAscii( &pTmp, "/../ure/bin/javaldx" );
+rtl_uString_newFromAscii( &pTmp, "/../basis-link/ure-link/bin/javaldx" );
 rtl_uString_newConcat( &pApp, pApp, pTmp );
 rtl_uString_release( pTmp );


Grüße/Regards,

René
-- 
 .''`.  René Engelhard -- Debian GNU/Linux Developer
 : :' : http://www.debian.org | http://people.debian.org/~rene/
 `. `'  r...@debian.org | GnuPG-Key ID: D03E3E70
   `-   Fingerprint: E12D EA46 7506 70CF A960 801D 0AA0 4571 D03E 3E70
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] [patch] memset used on struc with std::vector / Windows code

[Eike Rathke]

Hi Pierre-André,

On Sunday, 2011-09-11 14:20:57 +0200, Pierre-André Jacquod wrote:

> the struct DdeInstData contains a std::vector, but was initialized
> with memset( pData,0,sizeof(DdeInstData) )

Good catch.

> So I tried to have a consistent initialization with the new struct layout.

That should happen in a DdeInstData ctor instead. Note that you don't
need to explicitly clear the vector on that newly allocated object, it
is created empty anyway.

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [REVIEW] cherry-pick to 3-4: fix fdo#40590 defined names not resolved during file load

[Eike Rathke]

Hi,

Please review and cherry-pick to 3-4
http://cgit.freedesktop.org/libreoffice/core/commit/?id=6f42e4d03b04204b7a864f3c5c9c03548f5e2392
http://cgit.freedesktop.org/libreoffice/core/commit/?id=34c9a01b075788653b89c244eb8b3fcee54bfa68

Fixes https://bugs.freedesktop.org/show_bug.cgi?id=40590

  Eike

-- 
 PGP/OpenPGP/GnuPG encrypted mail preferred in all private communication.
 Key ID: 0x293C05FD - 997A 4C60 CE41 0149 0DB3  9E96 2F1A D073 293C 05FD


signature.asc
Description: Digital signature
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [patch] memset used on struc with std::vector / Windows code

[Pierre-André Jacquod]

hello,
I allow me to send also this patch (I should really find out a Windows 
box in order to compile / test by myself).


In short: since
a39d4eae Remove DECLARE_LIST(DdeConnections,DdeConnection*)

the struct DdeInstData contains a std::vector, but was initialized with 
memset( pData,0,sizeof(DdeInstData) )


So I tried to have a consistent initialization with the new struct layout.

regards
Pierre-André



0007-wrong-initialization-of-DdeInstData-with-memset-desp.patch
Description: application/mbox
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Cppcheck defect when @ is present

[Pierre-André Jacquod]

Hello,


  What's the best thing to do :
- to keep objective C++ parts ?
- to replace objective C++ by plain (with or without boost) C++ ?


for me there are already too many languages and flavour of languages. I 
would stay with  plain C++, not adding objective C++ on top


Just my feelings
regards
Pierre-André
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

[Libreoffice] [PATCH] Fix compilation in gtk3salnativewidgets-gtk.cxx

[Lucas Baudin]

Hi,

The small attached patch fixes the compilation in 
gtk3salnativewidgets-gtk.cxx, it's just a cast from long int to int.


The errors were:
/media/dev/LibreOffice/gtk3/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx:191:83: 
error: narrowing conversion of 'aClipRect.Rectangle::Left()' from 'long 
int' to 'int' inside { } [-fpermissive]
/media/dev/LibreOffice/gtk3/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx:191:83: 
error: narrowing conversion of 'aClipRect.Rectangle::Top()' from 'long 
int' to 'int' inside { } [-fpermissive]
/media/dev/LibreOffice/gtk3/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx:191:83: 
error: narrowing conversion of 'aClipRect.Rectangle::Right()' from 'long 
int' to 'int' inside { } [-fpermissive]
/media/dev/LibreOffice/gtk3/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx:191:83: 
error: narrowing conversion of 'aClipRect.Rectangle::Bottom()' from 
'long int' to 'int' inside { } [-fpermissive]


Lucas
>From e11b706452cc8b2191462008a5dc4c2eb68dd466 Mon Sep 17 00:00:00 2001
From: Lucas Baudin 
Date: Sun, 11 Sep 2011 10:10:07 +0200
Subject: [PATCH] Fix compilation in salnativewidgets fpr gtk3, it's just a
 trivial cast

---
 vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx b/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx
index ae655dd..2dc64fc 100644
--- a/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx
+++ b/vcl/unx/gtk3/gdi/gtk3salnativewidgets-gtk.cxx
@@ -187,8 +187,8 @@ void GtkSalGraphics::copyArea( long nDestX, long nDestY,
 RegionHandle aHnd = m_aClipRegion.BeginEnumRects();
 while( m_aClipRegion.GetNextEnumRect( aHnd, aClipRect ) )
 {
-cairo_rectangle_int_t aRect = { aClipRect.Left(), aClipRect.Top(),
-aClipRect.Right(), aClipRect.Bottom() };
+cairo_rectangle_int_t aRect = { (int)aClipRect.Left(), (int)aClipRect.Top(),
+(int)aClipRect.Right(), (int)aClipRect.Bottom() };
 cairo_region_union_rectangle( clip_region, &aRect );
 }
 m_aClipRegion.EndEnumRects (aHnd);
-- 
1.7.5.4

___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice

Re: [Libreoffice] Cppcheck defect when @ is present

[julien2412]

Hello,

I got this comment of a cppcheck developper :
is this objective c++? Can the code be replaced in the tokenizer
 with plain C++ somehow?

He seems to be right about objective C++. Then I made a opengrok research, 4
files use "@try". Perhaps, there are other files which use "@ expression",
since @try and @catch are not the only "@ expressions".

 What's the best thing to do :
- to keep objective C++ parts ?
- to replace objective C++ by plain (with or without boost) C++ ?

Julien. 

--
View this message in context: 
http://nabble.documentfoundation.org/Cppcheck-defect-when-is-present-tp3324103p3326563.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