Re: compiler warnings when building OpenOffice

2016-09-06 Thread Don Lewis 
On  1 Sep, Don Lewis wrote:

>  493 -Wunused-private-field
>  391 -Wunused-parameter
>  366 -Wunused-const-variable
>  314 -Woverloaded-virtual
>  181 -Wunused-variable
>  109 -Wlogical-op-parentheses
>   93 -Wsign-compare
>   77 -Wdelete-non-virtual-dtor
>   72 -Wint-to-void-pointer-cast
>   63 -Wshadow
>   56 -Wunused-function
>   41 -Wformat
>   36 -Wreturn-type-c-linkage
>   30 -Wchar-subscripts
>   27 -Wdeprecated-declarations
>   26 -Wundefined-bool-conversion
>   26 -Wsizeof-pointer-memaccess
>   25 -Wtautological-undefined-compare
>   24 -Wunused-local-typedef
>   22 -Wmacro-redefined
>   21 -Wswitch
>   20 -Wbitwise-op-parentheses
>   18 -Winvalid-source-encoding
>   13 -Wuninitialized
>   11 -Wtautological-compare
>   11 -Wlogical-not-parentheses
>   11 -Wdangling-else
>9 -Wmismatched-new-delete
>8 -Wimplicit-function-declaration
>8 -Wcomment
>7 -Wtautological-constant-out-of-range-compare
>7 -Wself-assign
>7 -Wheader-guard
>6 -Wunused-value
>6 -Wunneeded-internal-declaration
>6 -Wtautological-pointer-compare
>6 -Wpointer-bool-conversion
>6 -Wparentheses-equality
>6 -Wdynamic-class-memaccess
>6 -Wconstant-conversion
>5 -Wpointer-sign
>4 -Wnull-conversion
>3 -Wunsequenced
>3 -Wreorder
>3 -Wknr-promoted-parameter
>3 -Wint-to-pointer-cast
>2 -Wstrncat-size
>2 -Wstring-compare
>2 -Wsometimes-uninitialized
>2 -Wconstant-logical-operand
>2 -Warray-bounds
>1 -Wunused-comparison
>1 -Wunknown-pragmas
>1 -Wstring-plus-int
>1 -Wpotentially-evaluated-expression
>1 -Wnon-literal-null-conversion
>1 -Wmismatched-tags
>1 -Wincompatible-pointer-types-discards-qualifiers
>1 -Wimplicit-int
>1 -Wignored-qualifiers
>1 -Wformat-extra-args
>1 -Wcompare-distinct-pointer-types
>1 -Wc++11-compat-deprecated-writable-strings


Here is the per-module warning count:
 513 icc
 222 sw
 167 svx
 154 icu
 151 oox
 149 sc
 145 sd
 107 svtools
  72 vcl
  70 sal
  67 xmloff
  52 i18npool
  46 cui
  42 sfx2
  40 connectivity
  39 dbaccess
  38 canvas
  36 slideshow
  34 sdext
  31 filter
  29 xmlhelp
  29 libxmlsec
  29 chart2
  28 framework
  27 toolkit
  25 editeng
  25 accessibility
  24 reportdesign
  22 l10ntools
  20 basic
  20 basegfx
  19 desktop
  19 automation
  14 xmlsecurity
  14 avmedia
  12 ucb
  11 extensions
  11 cppuhelper
  10 writerfilter
  10 unoxml
   9 starmath
   9 basctl
   7 tools
   7 soltools


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: compiler warnings when building OpenOffice

2016-09-04 Thread Patricia Shanahan 

On 9/4/2016 3:45 PM, Patricia Shanahan wrote:

On 9/1/2016 4:00 PM, Don Lewis wrote:

On  1 Sep, Patricia Shanahan wrote:

I need a problem to work on. Would you like me to take a particular
compiler warning and try to sort it out?


Here is one:

/wrkdirs/usr/ports/editors/openoffice-devel2/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/inc/osl/diagnose.hxx:65:25:
warning: 'osl_detail_ObjectRegistry_getMutex' has C-linkage specified,
but returns user-defined type '::osl::Mutex &' which is incompatible
with C [-Wreturn-type-c-linkage]

In sal/inc/osl/diagnose.hxx,
  ::osl::Mutex & SAL_CALL osl_detail_ObjectRegistry_getMutex()
is declared inside an extern "C" block, so it should have C linkage, but
it is returning a reference, which is a C++ thing.

The obvious fix would seem to be to move it out of the extern "C" block,
but I don't know what to do about the SAL_THROW_EXTERN_C() part of the
declaration.


I have compiled and done some basic tests with the declaration simply
moved out of the extern "C" block, and it did not appear to cause any
problems. I'll look into SAL_THROW_EXTERN_C next.


SAL_THROW_EXTERN_C and SAL_THROW are concerned with generating, or not 
generating, a dynamic exception specification in a function declaration. 
According to Wikipedia, 
https://en.wikipedia.org/wiki/C%2B%2B11#Features_removed_or_deprecated, 
dynamic exception specifications have been deprecated since C++11.


SAL_THROW_EXTERN_C with __cplusplus defined generates "throw ()", 
regardless of the linkage.


My recommendation is to leave it unchanged, but at some point we should 
examine and reconsider both SAL_THROW macros.


They are declared in main/sal/inc/sal/types.h

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: compiler warnings when building OpenOffice

2016-09-04 Thread Patricia Shanahan 

On 9/1/2016 4:00 PM, Don Lewis wrote:

On  1 Sep, Patricia Shanahan wrote:

I need a problem to work on. Would you like me to take a particular
compiler warning and try to sort it out?


Here is one:

/wrkdirs/usr/ports/editors/openoffice-devel2/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/inc/osl/diagnose.hxx:65:25:
 warning: 'osl_detail_ObjectRegistry_getMutex' has C-linkage specified, but returns 
user-defined type '::osl::Mutex &' which is incompatible with C 
[-Wreturn-type-c-linkage]

In sal/inc/osl/diagnose.hxx,
  ::osl::Mutex & SAL_CALL osl_detail_ObjectRegistry_getMutex()
is declared inside an extern "C" block, so it should have C linkage, but
it is returning a reference, which is a C++ thing.

The obvious fix would seem to be to move it out of the extern "C" block,
but I don't know what to do about the SAL_THROW_EXTERN_C() part of the
declaration.


I have compiled and done some basic tests with the declaration simply 
moved out of the extern "C" block, and it did not appear to cause any 
problems. I'll look into SAL_THROW_EXTERN_C next.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: compiler warnings when building OpenOffice

2016-09-01 Thread Don Lewis 
On  1 Sep, To: Don Lewis wrote:

> One of the -Wunused-parameter warnings led me to this questionable bit
> of code in filter/source/xsltfilter/containerhelper.hxx:
> 
> template
> inline void forEachMem(FuncType pFunc, ParamType aParam) const
> {
> forEach( ::boost::bind(pFunc, _1, aParam));
> }
> 
> template
> inline void forEachMem(FuncType pFunc, ParamType1 aParam1, ParamType2 
> aParam2) const
> {
> forEach( ::boost::bind(pFunc, -1, aParam1, aParam2 ));
> }
>  
> template typename ParamType3>
> inline void forEachMem( FuncType pFunc, ParamType1 aParam1, 
> ParamType2 aParam2, ParamType3 aParam3 ) const
> {
> forEach( ::boost::bind(pFunc, _1, aParam2, aParam2, aParam3 
> ));
> }
> 
> In the three parameter version of this code, it looks like aParam1
> should be used instead of using aParam2 twice.  Also, in the two
> parameter version of the code, it looks like _1 should be used instead
> of -1.  I haven't had a chance to investigate the possible symptoms of
> these errors or how to text the appropriate fix.

The answer is that the code in question does not appear to be used. Only
the version that doesn't take any parameters (not shown above) is used
in the filter module.

There are also copies of this code in the oox module that appear to be
correct.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: compiler warnings when building OpenOffice

2016-09-01 Thread Don Lewis 
On  1 Sep, Patricia Shanahan wrote:
> I need a problem to work on. Would you like me to take a particular 
> compiler warning and try to sort it out?

Here is one:

/wrkdirs/usr/ports/editors/openoffice-devel2/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/inc/osl/diagnose.hxx:65:25:
 warning: 'osl_detail_ObjectRegistry_getMutex' has C-linkage specified, but 
returns user-defined type '::osl::Mutex &' which is incompatible with C 
[-Wreturn-type-c-linkage]

In sal/inc/osl/diagnose.hxx,
  ::osl::Mutex & SAL_CALL osl_detail_ObjectRegistry_getMutex()
is declared inside an extern "C" block, so it should have C linkage, but
it is returning a reference, which is a C++ thing.

The obvious fix would seem to be to move it out of the extern "C" block,
but I don't know what to do about the SAL_THROW_EXTERN_C() part of the
declaration.


Another one is -Woverloaded-virtual which has a number of instances.
These are the top three in terms of warning count (due to repeats):

main/solver/420/unxfbsdx.pro/inc/cppuhelper/compbase4.hxx:75:31: warning: 
'cppu::WeakComponentImplHelper4::addEventListener' hides overloaded virtual 
function [-Woverloaded-virtual]

main/solver/420/unxfbsdx.pro/inc/cppuhelper/compbase4.hxx:77:31: warning: 
'cppu::WeakComponentImplHelper4::removeEventListener' hides overloaded 
virtual function [-Woverloaded-virtual]

main/solver/420/unxfbsdx.pro/inc/canvas/base/graphicdevicebase.hxx:145:31: 
warning: 
'canvas::GraphicDeviceBase >, 
vclcanvas::SpriteDeviceHelper, vclcanvas::tools::LocalGuard, 
cppu::OWeakObject>::disposing' hides overloaded virtual function 
[-Woverloaded-virtual]

I'm not sure if there is really a problem here or if the warning is
harmless.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: compiler warnings when building OpenOffice

2016-09-01 Thread Patricia Shanahan 
I need a problem to work on. Would you like me to take a particular 
compiler warning and try to sort it out?


On 9/1/2016 3:29 PM, Don Lewis wrote:

On 29 Aug, Don Lewis wrote:

When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
I'm mostly interested in the OpenOffice code and not the bundled
external code, so I specifically built the FreeBSD port it uses
--with-system-foo extensively which minimizes the compilation of third
party code.  The total number of warnings is 5105.

1175 -Wtautological-undefined-compare
 949 -Wunused-private-field
 660 -Wshift-negative-value
 391 -Wunused-parameter
 362 -Wunused-const-variable
 312 -Woverloaded-virtual
 177 -Wunused-variable
 116 -Winfinite-recursion
 109 -Wlogical-op-parentheses
  93 -Wsign-compare
  76 -Wdelete-non-virtual-dtor
  72 -Wint-to-void-pointer-cast
  63 -Wshadow
  55 -Wunused-function
  41 -Wformat
  36 -Wreturn-type-c-linkage
  30 -Wchar-subscripts
  27 -Wdeprecated-declarations
  26 -Wundefined-bool-conversion
  26 -Wsizeof-pointer-memaccess
  26 -Wformat-security
  24 -Wunused-local-typedef
  22 -Wmacro-redefined
  21 -Wswitch
  20 -Wbitwise-op-parentheses
  18 -Winvalid-source-encoding
  13 -Wuninitialized
  11 -Wtautological-compare
  11 -Wlogical-not-parentheses
  11 -Wdangling-else
   9 -Wmismatched-new-delete
   8 -Wimplicit-function-declaration
   8 -Wheader-guard
   8 -Wcomment
   7 -Wtautological-constant-out-of-range-compare
   7 -Wself-assign
   6 -Wunused-value
   6 -Wunneeded-internal-declaration
   6 -Wtautological-pointer-compare
   6 -Wpointer-bool-conversion
   6 -Wparentheses-equality
   6 -Wdynamic-class-memaccess
   6 -Wconstant-conversion
   5 -Wpointer-sign
   4 -Wnull-conversion
   3 -Wunsequenced
   3 -Wreorder
   3 -Wknr-promoted-parameter
   3 -Wint-to-pointer-cast
   2 -Wstrncat-size
   2 -Wstring-compare
   2 -Wsometimes-uninitialized
   2 -Wconstant-logical-operand
   2 -Warray-bounds
   1 -Wunused-comparison
   1 -Wunknown-pragmas
   1 -Wstring-plus-int
   1 -Wpotentially-evaluated-expression
   1 -Wnon-literal-null-conversion
   1 -Wmismatched-tags
   1 -Wincompatible-pointer-types-discards-qualifiers
   1 -Wimplicit-int
   1 -Wignored-qualifiers
   1 -Wformat-extra-args
   1 -Wcompare-distinct-pointer-types
   1 -Wc++11-compat-deprecated-writable-strings


Now down to 2708 warnings.  It'll be slower going from this point
forward because each of the remaining issues will have a much smaller
impact on the warning count that many of the ones I have already fixed.

FWIW, bundled icc is getting to be a significant contributer to the
remaining warnings.

One of the -Wunused-parameter warnings led me to this questionable bit
of code in filter/source/xsltfilter/containerhelper.hxx:

template
inline void forEachMem(FuncType pFunc, ParamType aParam) const
{
forEach( ::boost::bind(pFunc, _1, aParam));
}

template
inline void forEachMem(FuncType pFunc, ParamType1 aParam1, ParamType2 
aParam2) const
{
forEach( ::boost::bind(pFunc, -1, aParam1, aParam2 ));
}

template
inline void forEachMem( FuncType pFunc, ParamType1 aParam1, ParamType2 
aParam2, ParamType3 aParam3 ) const
{
forEach( ::boost::bind(pFunc, _1, aParam2, aParam2, aParam3 ));
}

In the three parameter version of this code, it looks like aParam1
should be used instead of using aParam2 twice.  Also, in the two
parameter version of the code, it looks like _1 should be used instead
of -1.  I haven't had a chance to investigate the possible symptoms of
these errors or how to text the appropriate fix.

 493 -Wunused-private-field
 391 -Wunused-parameter
 366 -Wunused-const-variable
 314 -Woverloaded-virtual
 181 -Wunused-variable
 109 -Wlogical-op-parentheses
  93 -Wsign-compare
  77 -Wdelete-non-virtual-dtor
  72 -Wint-to-void-pointer-cast
  63 -Wshadow
  56 -Wunused-function
  41 -Wformat
  36 -Wreturn-type-c-linkage
  30 -Wchar-subscripts
  27 -Wdeprecated-declarations
  26 -Wundefined-bool-conversion
  26 -Wsizeof-pointer-memaccess
  25 -Wtautological-undefined-compare
  24 -Wunused-local-typedef
  22 -Wmacro-redefined
  21 -Wswitch
  20 -Wbitwise-op-parentheses
  18 -Winvalid-source-encoding
  13 -Wuninitialized
  11 -Wtautological-compare
  11 -Wlogical-not-parentheses
  11 -Wdangling-else
   9 -Wmismatched-new-delete
   8 -Wimplicit-function-declaration
   8 -Wcomment
   7 -Wtautological-constant-out-of-range-compare
   7 -Wself-assign
   7 -Wheader-guard
   6 -Wunused-value
   6 -Wunneeded-internal-declaration
   6 -Wtautological-pointer-compare
   6 -Wpointer-bool-conversion
   6 -Wparentheses-equality
   6 -Wdynamic-class-memaccess
   6 -Wconstant-conversion
   5 -Wpointer-sign
   4 -Wnull-conversion
   3 -Wunsequenced
   3 -Wreorder
   3 -Wknr-promoted-parameter
   3 -Wint-to-pointer-cast
   2 -Wstrncat-size
   2 -Wstring-compare

Re: compiler warnings when building OpenOffice

2016-09-01 Thread Don Lewis 
On 29 Aug, Don Lewis wrote:
> When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
> FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
> I'm mostly interested in the OpenOffice code and not the bundled
> external code, so I specifically built the FreeBSD port it uses
> --with-system-foo extensively which minimizes the compilation of third
> party code.  The total number of warnings is 5105.
> 
> 1175 -Wtautological-undefined-compare
>  949 -Wunused-private-field
>  660 -Wshift-negative-value
>  391 -Wunused-parameter
>  362 -Wunused-const-variable
>  312 -Woverloaded-virtual
>  177 -Wunused-variable
>  116 -Winfinite-recursion
>  109 -Wlogical-op-parentheses
>   93 -Wsign-compare
>   76 -Wdelete-non-virtual-dtor
>   72 -Wint-to-void-pointer-cast
>   63 -Wshadow
>   55 -Wunused-function
>   41 -Wformat
>   36 -Wreturn-type-c-linkage
>   30 -Wchar-subscripts
>   27 -Wdeprecated-declarations
>   26 -Wundefined-bool-conversion
>   26 -Wsizeof-pointer-memaccess
>   26 -Wformat-security
>   24 -Wunused-local-typedef
>   22 -Wmacro-redefined
>   21 -Wswitch
>   20 -Wbitwise-op-parentheses
>   18 -Winvalid-source-encoding
>   13 -Wuninitialized
>   11 -Wtautological-compare
>   11 -Wlogical-not-parentheses
>   11 -Wdangling-else
>9 -Wmismatched-new-delete
>8 -Wimplicit-function-declaration
>8 -Wheader-guard
>8 -Wcomment
>7 -Wtautological-constant-out-of-range-compare
>7 -Wself-assign
>6 -Wunused-value
>6 -Wunneeded-internal-declaration
>6 -Wtautological-pointer-compare
>6 -Wpointer-bool-conversion
>6 -Wparentheses-equality
>6 -Wdynamic-class-memaccess
>6 -Wconstant-conversion
>5 -Wpointer-sign
>4 -Wnull-conversion
>3 -Wunsequenced
>3 -Wreorder
>3 -Wknr-promoted-parameter
>3 -Wint-to-pointer-cast
>2 -Wstrncat-size
>2 -Wstring-compare
>2 -Wsometimes-uninitialized
>2 -Wconstant-logical-operand
>2 -Warray-bounds
>1 -Wunused-comparison
>1 -Wunknown-pragmas
>1 -Wstring-plus-int
>1 -Wpotentially-evaluated-expression
>1 -Wnon-literal-null-conversion
>1 -Wmismatched-tags
>1 -Wincompatible-pointer-types-discards-qualifiers
>1 -Wimplicit-int
>1 -Wignored-qualifiers
>1 -Wformat-extra-args
>1 -Wcompare-distinct-pointer-types
>1 -Wc++11-compat-deprecated-writable-strings

Now down to 2708 warnings.  It'll be slower going from this point
forward because each of the remaining issues will have a much smaller
impact on the warning count that many of the ones I have already fixed.

FWIW, bundled icc is getting to be a significant contributer to the
remaining warnings.

One of the -Wunused-parameter warnings led me to this questionable bit
of code in filter/source/xsltfilter/containerhelper.hxx:

template
inline void forEachMem(FuncType pFunc, ParamType aParam) const
{
forEach( ::boost::bind(pFunc, _1, aParam));
}

template
inline void forEachMem(FuncType pFunc, ParamType1 aParam1, ParamType2 
aParam2) const
{
forEach( ::boost::bind(pFunc, -1, aParam1, aParam2 ));
}
 
template
inline void forEachMem( FuncType pFunc, ParamType1 aParam1, ParamType2 
aParam2, ParamType3 aParam3 ) const
{
forEach( ::boost::bind(pFunc, _1, aParam2, aParam2, aParam3 ));
}

In the three parameter version of this code, it looks like aParam1
should be used instead of using aParam2 twice.  Also, in the two
parameter version of the code, it looks like _1 should be used instead
of -1.  I haven't had a chance to investigate the possible symptoms of
these errors or how to text the appropriate fix.

 493 -Wunused-private-field
 391 -Wunused-parameter
 366 -Wunused-const-variable
 314 -Woverloaded-virtual
 181 -Wunused-variable
 109 -Wlogical-op-parentheses
  93 -Wsign-compare
  77 -Wdelete-non-virtual-dtor
  72 -Wint-to-void-pointer-cast
  63 -Wshadow
  56 -Wunused-function
  41 -Wformat
  36 -Wreturn-type-c-linkage
  30 -Wchar-subscripts
  27 -Wdeprecated-declarations
  26 -Wundefined-bool-conversion
  26 -Wsizeof-pointer-memaccess
  25 -Wtautological-undefined-compare
  24 -Wunused-local-typedef
  22 -Wmacro-redefined
  21 -Wswitch
  20 -Wbitwise-op-parentheses
  18 -Winvalid-source-encoding
  13 -Wuninitialized
  11 -Wtautological-compare
  11 -Wlogical-not-parentheses
  11 -Wdangling-else
   9 -Wmismatched-new-delete
   8 -Wimplicit-function-declaration
   8 -Wcomment
   7 -Wtautological-constant-out-of-range-compare
   7 -Wself-assign
   7 -Wheader-guard
   6 -Wunused-value
   6 -Wunneeded-internal-declaration
   6 -Wtautological-pointer-compare
   6 -Wpointer-bool-conversion
   6 -Wparentheses-equality
   6 -Wdynamic-class-memaccess
   6 -Wconstant-conversion
   5 -Wpointer-sign
   4 -Wnull-conversion
   3 -Wunsequenced
   3 -Wreorder
   3 -Wknr-promoted-parameter
   3 -Wint-to-pointer-cast
   2 -Wstrncat-size
   2 -Wstring-compare
   2

Re: compiler warnings when building OpenOffice

2016-08-30 Thread Don Lewis 
On 30 Aug, Don Lewis wrote:
> On 30 Aug, Kay Schenk wrote:
>> 
>> 
>> On 08/29/2016 04:14 PM, Don Lewis wrote:

>>> A couple -Wtautological-undefined-compare warnings:
>>> 
>>> warning: reference cannot be bound to dereferenced null pointer in 
>>> well-defined C++ code; comparison may be assumed to always evaluate to 
>>> false [-Wtautologica
>>> l-undefined-compare]
>>> if ( == NULL) {
>>>  ^
>> 
>> This one is apparently an old holdoever from C and not recommended
>> currently...
>> 
>> See. e.g:
>> http://stackoverflow.com/questions/17772103/can-i-use-if-pointer-instead-of-if-pointer-null
>> 
>> It probably needs an update to accomplish what it's trying to do.
>> 
>> 
>>> 
>>> warning: 'this' pointer cannot be null in well-defined C++ code; comparison 
>>> may be assumed to always evaluate to false [-Wtautological-undefin
>>> ed-compare]
>>>   if(this == 0 || this == ) {
>>>  ^~~~~
>>> 
>> 
>> Same here...
> 
> nullptr is a c++11 thing and is not supported by older compilers.
> 
> When I upgraded one of the bundled packages (nss?) I found it had some
> test code that used nullptr that didn't compille on many of our
> platforms.  I had to disconnect the tests from the build.
> 
> The warnings are about things that can't be null.  In the first case if
> you have a reference to another variable, then the address of that
> variable can't be null.  In the second case, this could only be null if
> you call a method on a null object.
> 
> One of the bits of code that I looked at for the first error looked
> suspicious.  It looks like it is passing *ptr as a reference parameter.
> I'm not sure that's legal, and then the question is what happens if ptr
> is null?  Other calls to the same function were passing a regular
> variable by reference.  The appropriate fix in this case my be to create
> a variant function that accepts a pointer and checks for NULL.  Rather
> than checking  == NULL.

Hmn, this is what I was afraid of.  The following code compiles without
any warnings or errors:

#include 
 
void 
func(int )
{
fprintf(stderr, "%p\n", );
}
 
int 
main(void)
{
int i, *p1, *p2;

i = 42;
p1 = 
p2 = NULL;
 
func(*p1);
func(*p2);
}

Running it gives the following output:

0x7fffea7c
0x0

So basically it is allowing *p2 to be dereferenced even though it is
NULL, and the address of the reference variable inside func() is 0.

I guess this isn't well defined C++ code ...




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: compiler warnings when building OpenOffice

2016-08-30 Thread Don Lewis 
On 30 Aug, Kay Schenk wrote:
> 
> 
> On 08/29/2016 04:14 PM, Don Lewis wrote:
>> When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
>> FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
>> I'm mostly interested in the OpenOffice code and not the bundled
>> external code, so I specifically built the FreeBSD port it uses
>> --with-system-foo extensively which minimizes the compilation of third
>> party code.  The total number of warnings is 5105.
>> 
>> 1175 -Wtautological-undefined-compare
>>  949 -Wunused-private-field
>>  660 -Wshift-negative-value
>>  391 -Wunused-parameter
>>  362 -Wunused-const-variable
>>  312 -Woverloaded-virtual
>>  177 -Wunused-variable
>>  116 -Winfinite-recursion
>>  109 -Wlogical-op-parentheses
>>   93 -Wsign-compare
>>   76 -Wdelete-non-virtual-dtor
>>   72 -Wint-to-void-pointer-cast
>>   63 -Wshadow
>>   55 -Wunused-function
>>   41 -Wformat
>>   36 -Wreturn-type-c-linkage
>>   30 -Wchar-subscripts
>>   27 -Wdeprecated-declarations
>>   26 -Wundefined-bool-conversion
>>   26 -Wsizeof-pointer-memaccess
>>   26 -Wformat-security
>>   24 -Wunused-local-typedef
>>   22 -Wmacro-redefined
>>   21 -Wswitch
>>   20 -Wbitwise-op-parentheses
>>   18 -Winvalid-source-encoding
>>   13 -Wuninitialized
>>   11 -Wtautological-compare
>>   11 -Wlogical-not-parentheses
>>   11 -Wdangling-else
>>9 -Wmismatched-new-delete
>>8 -Wimplicit-function-declaration
>>8 -Wheader-guard
>>8 -Wcomment
>>7 -Wtautological-constant-out-of-range-compare
>>7 -Wself-assign
>>6 -Wunused-value
>>6 -Wunneeded-internal-declaration
>>6 -Wtautological-pointer-compare
>>6 -Wpointer-bool-conversion
>>6 -Wparentheses-equality
>>6 -Wdynamic-class-memaccess
>>6 -Wconstant-conversion
>>5 -Wpointer-sign
>>4 -Wnull-conversion
>>3 -Wunsequenced
>>3 -Wreorder
>>3 -Wknr-promoted-parameter
>>3 -Wint-to-pointer-cast
>>2 -Wstrncat-size
>>2 -Wstring-compare
>>2 -Wsometimes-uninitialized
>>2 -Wconstant-logical-operand
>>2 -Warray-bounds
>>1 -Wunused-comparison
>>1 -Wunknown-pragmas
>>1 -Wstring-plus-int
>>1 -Wpotentially-evaluated-expression
>>1 -Wnon-literal-null-conversion
>>1 -Wmismatched-tags
>>1 -Wincompatible-pointer-types-discards-qualifiers
>>1 -Wimplicit-int
>>1 -Wignored-qualifiers
>>1 -Wformat-extra-args
>>1 -Wcompare-distinct-pointer-types
>>1 -Wc++11-compat-deprecated-writable-strings
>> 
>> 
>> A couple -Wtautological-undefined-compare warnings:
>> 
>> warning: reference cannot be bound to dereferenced null pointer in 
>> well-defined C++ code; comparison may be assumed to always evaluate to false 
>> [-Wtautologica
>> l-undefined-compare]
>> if ( == NULL) {
>>  ^
> 
> This one is apparently an old holdoever from C and not recommended
> currently...
> 
> See. e.g:
> http://stackoverflow.com/questions/17772103/can-i-use-if-pointer-instead-of-if-pointer-null
> 
> It probably needs an update to accomplish what it's trying to do.
> 
> 
>> 
>> warning: 'this' pointer cannot be null in well-defined C++ code; comparison 
>> may be assumed to always evaluate to false [-Wtautological-undefin
>> ed-compare]
>>   if(this == 0 || this == ) {
>>  ^~~~~
>> 
> 
> Same here...

nullptr is a c++11 thing and is not supported by older compilers.

When I upgraded one of the bundled packages (nss?) I found it had some
test code that used nullptr that didn't compille on many of our
platforms.  I had to disconnect the tests from the build.

The warnings are about things that can't be null.  In the first case if
you have a reference to another variable, then the address of that
variable can't be null.  In the second case, this could only be null if
you call a method on a null object.

One of the bits of code that I looked at for the first error looked
suspicious.  It looks like it is passing *ptr as a reference parameter.
I'm not sure that's legal, and then the question is what happens if ptr
is null?  Other calls to the same function were passing a regular
variable by reference.  The appropriate fix in this case my be to create
a variant function that accepts a pointer and checks for NULL.  Rather
than checking  == NULL.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: compiler warnings when building OpenOffice

2016-08-30 Thread Kay Schenk 


On 08/29/2016 04:14 PM, Don Lewis wrote:
> When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
> FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
> I'm mostly interested in the OpenOffice code and not the bundled
> external code, so I specifically built the FreeBSD port it uses
> --with-system-foo extensively which minimizes the compilation of third
> party code.  The total number of warnings is 5105.
> 
> 1175 -Wtautological-undefined-compare
>  949 -Wunused-private-field
>  660 -Wshift-negative-value
>  391 -Wunused-parameter
>  362 -Wunused-const-variable
>  312 -Woverloaded-virtual
>  177 -Wunused-variable
>  116 -Winfinite-recursion
>  109 -Wlogical-op-parentheses
>   93 -Wsign-compare
>   76 -Wdelete-non-virtual-dtor
>   72 -Wint-to-void-pointer-cast
>   63 -Wshadow
>   55 -Wunused-function
>   41 -Wformat
>   36 -Wreturn-type-c-linkage
>   30 -Wchar-subscripts
>   27 -Wdeprecated-declarations
>   26 -Wundefined-bool-conversion
>   26 -Wsizeof-pointer-memaccess
>   26 -Wformat-security
>   24 -Wunused-local-typedef
>   22 -Wmacro-redefined
>   21 -Wswitch
>   20 -Wbitwise-op-parentheses
>   18 -Winvalid-source-encoding
>   13 -Wuninitialized
>   11 -Wtautological-compare
>   11 -Wlogical-not-parentheses
>   11 -Wdangling-else
>9 -Wmismatched-new-delete
>8 -Wimplicit-function-declaration
>8 -Wheader-guard
>8 -Wcomment
>7 -Wtautological-constant-out-of-range-compare
>7 -Wself-assign
>6 -Wunused-value
>6 -Wunneeded-internal-declaration
>6 -Wtautological-pointer-compare
>6 -Wpointer-bool-conversion
>6 -Wparentheses-equality
>6 -Wdynamic-class-memaccess
>6 -Wconstant-conversion
>5 -Wpointer-sign
>4 -Wnull-conversion
>3 -Wunsequenced
>3 -Wreorder
>3 -Wknr-promoted-parameter
>3 -Wint-to-pointer-cast
>2 -Wstrncat-size
>2 -Wstring-compare
>2 -Wsometimes-uninitialized
>2 -Wconstant-logical-operand
>2 -Warray-bounds
>1 -Wunused-comparison
>1 -Wunknown-pragmas
>1 -Wstring-plus-int
>1 -Wpotentially-evaluated-expression
>1 -Wnon-literal-null-conversion
>1 -Wmismatched-tags
>1 -Wincompatible-pointer-types-discards-qualifiers
>1 -Wimplicit-int
>1 -Wignored-qualifiers
>1 -Wformat-extra-args
>1 -Wcompare-distinct-pointer-types
>1 -Wc++11-compat-deprecated-writable-strings
> 
> 
> A couple -Wtautological-undefined-compare warnings:
> 
> warning: reference cannot be bound to dereferenced null pointer in 
> well-defined C++ code; comparison may be assumed to always evaluate to false 
> [-Wtautologica
> l-undefined-compare]
> if ( == NULL) {
>  ^

This one is apparently an old holdoever from C and not recommended
currently...

See. e.g:
http://stackoverflow.com/questions/17772103/can-i-use-if-pointer-instead-of-if-pointer-null

It probably needs an update to accomplish what it's trying to do.


> 
> warning: 'this' pointer cannot be null in well-defined C++ code; comparison 
> may be assumed to always evaluate to false [-Wtautological-undefin
> ed-compare]
>   if(this == 0 || this == ) {
>  ^~~~~
> 

Same here...

> I'd like to just nuke these comparisions.
> 
> 
> To fix the -Wunused-private-field private field warnings, I'd prefer to
> delete them, but that would have the side effect of breaking the ABI if
> an extensions use the class constructor.  The alternative would be to
> mark them unused.  I don't think there are actually many cases of this.
> The same warning gets generated anytime the header is included.
> 
> 
> In the case of -Wshift-negative-value, result of shifting negative
> values is undefined.  This is generally fixable by using unsigned values
> instead.
> 
> 
> I'm not sure what to about -Wunused-parameter.  It's probably a case by
> case situation where it may sometimes make sense to have a variant
> function that doesn't have that parameter and modify the callers.  The
> alternative is to mark the argument as unused.  I haven't really
> examined any of these in detail.
> 
> 
> For -Wunused-const-variable and -Wunused-variable, I propose just
> deleting them unless they are referenced by conditionally compiled code,
> in which case I would make the variable declaration conditional as well.
> 
> 
> I fixed one other case of -Winfinite-recursion.  I'm pretty sure this is
> just one error, but it is contained in a header.
> 
> 
> I think -Wshadow warnings should be fixed by renaming the variable.
> 
> 
> I don't recall ever seeing -Wunused-function scroll by, but if functions
> are totally unused, they should be deleted.
> 
> 
> The parentheses warnings should just get fixed.
> 
> 
> This is an example -Wdelete-non-virtual-dtor warning:
> 
> warning: delete called on non-final 'RscError' that has virtual functions but 
> non-virtual destructor [-Wdelete-non-virtual-dtor]
> delete pErrHdl;
> 
> My C++ book says that non-virtual destructors are bad generally bad.  We
> also compile

Re: compiler warnings when building OpenOffice

2016-08-29 Thread Don Lewis 
On 29 Aug, Don Lewis wrote:
> When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
> FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
> I'm mostly interested in the OpenOffice code and not the bundled
> external code, so I specifically built the FreeBSD port it uses
> --with-system-foo extensively which minimizes the compilation of third
> party code.  The total number of warnings is 5105.
> 
> 1175 -Wtautological-undefined-compare
>  949 -Wunused-private-field
>  660 -Wshift-negative-value
>  391 -Wunused-parameter
>  362 -Wunused-const-variable
>  312 -Woverloaded-virtual
>  177 -Wunused-variable
>  116 -Winfinite-recursion
>  109 -Wlogical-op-parentheses
>   93 -Wsign-compare
>   76 -Wdelete-non-virtual-dtor
>   72 -Wint-to-void-pointer-cast
>   63 -Wshadow
>   55 -Wunused-function
>   41 -Wformat
>   36 -Wreturn-type-c-linkage
>   30 -Wchar-subscripts
>   27 -Wdeprecated-declarations
>   26 -Wundefined-bool-conversion
>   26 -Wsizeof-pointer-memaccess
>   26 -Wformat-security
>   24 -Wunused-local-typedef
>   22 -Wmacro-redefined
>   21 -Wswitch
>   20 -Wbitwise-op-parentheses
>   18 -Winvalid-source-encoding
>   13 -Wuninitialized
>   11 -Wtautological-compare
>   11 -Wlogical-not-parentheses
>   11 -Wdangling-else
>9 -Wmismatched-new-delete
>8 -Wimplicit-function-declaration
>8 -Wheader-guard
>8 -Wcomment
>7 -Wtautological-constant-out-of-range-compare
>7 -Wself-assign
>6 -Wunused-value
>6 -Wunneeded-internal-declaration
>6 -Wtautological-pointer-compare
>6 -Wpointer-bool-conversion
>6 -Wparentheses-equality
>6 -Wdynamic-class-memaccess
>6 -Wconstant-conversion
>5 -Wpointer-sign
>4 -Wnull-conversion
>3 -Wunsequenced
>3 -Wreorder
>3 -Wknr-promoted-parameter
>3 -Wint-to-pointer-cast
>2 -Wstrncat-size
>2 -Wstring-compare
>2 -Wsometimes-uninitialized
>2 -Wconstant-logical-operand
>2 -Warray-bounds
>1 -Wunused-comparison
>1 -Wunknown-pragmas
>1 -Wstring-plus-int
>1 -Wpotentially-evaluated-expression
>1 -Wnon-literal-null-conversion
>1 -Wmismatched-tags
>1 -Wincompatible-pointer-types-discards-qualifiers
>1 -Wimplicit-int
>1 -Wignored-qualifiers
>1 -Wformat-extra-args
>1 -Wcompare-distinct-pointer-types
>1 -Wc++11-compat-deprecated-writable-strings
> 
> 
> A couple -Wtautological-undefined-compare warnings:
> 
> warning: reference cannot be bound to dereferenced null pointer in 
> well-defined C++ code; comparison may be assumed to always evaluate to false 
> [-Wtautologica
> l-undefined-compare]
> if ( == NULL) {
>  ^
> 
> warning: 'this' pointer cannot be null in well-defined C++ code; comparison 
> may be assumed to always evaluate to false [-Wtautological-undefin
> ed-compare]
>   if(this == 0 || this == ) {
>  ^~~~~
> 
> I'd like to just nuke these comparisions.

It looks like all the noise actually just stems from 26 instances of the
first of these and three of the second.


> To fix the -Wunused-private-field private field warnings, I'd prefer to
> delete them, but that would have the side effect of breaking the ABI if
> an extensions use the class constructor.  The alternative would be to
> mark them unused.  I don't think there are actually many cases of this.
> The same warning gets generated anytime the header is included.

There seem to be a lot more of these than I expected.

> In the case of -Wshift-negative-value, result of shifting negative
> values is undefined.  This is generally fixable by using unsigned values
> instead.
> 
> 
> I'm not sure what to about -Wunused-parameter.  It's probably a case by
> case situation where it may sometimes make sense to have a variant
> function that doesn't have that parameter and modify the callers.  The
> alternative is to mark the argument as unused.  I haven't really
> examined any of these in detail.

I've seen a mixture of causes.  Some are due to conditional
compiliation, some are class methods where the parameter is only
sometimes used.



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

compiler warnings when building OpenOffice

2016-08-29 Thread Don Lewis 
When building OpenOffice trunk revsion r1758161 as a FreeBSD port on
FreeBSD 12.0-CURRENT with clang 3.8.0, I get the following warnings.
I'm mostly interested in the OpenOffice code and not the bundled
external code, so I specifically built the FreeBSD port it uses
--with-system-foo extensively which minimizes the compilation of third
party code.  The total number of warnings is 5105.

1175 -Wtautological-undefined-compare
 949 -Wunused-private-field
 660 -Wshift-negative-value
 391 -Wunused-parameter
 362 -Wunused-const-variable
 312 -Woverloaded-virtual
 177 -Wunused-variable
 116 -Winfinite-recursion
 109 -Wlogical-op-parentheses
  93 -Wsign-compare
  76 -Wdelete-non-virtual-dtor
  72 -Wint-to-void-pointer-cast
  63 -Wshadow
  55 -Wunused-function
  41 -Wformat
  36 -Wreturn-type-c-linkage
  30 -Wchar-subscripts
  27 -Wdeprecated-declarations
  26 -Wundefined-bool-conversion
  26 -Wsizeof-pointer-memaccess
  26 -Wformat-security
  24 -Wunused-local-typedef
  22 -Wmacro-redefined
  21 -Wswitch
  20 -Wbitwise-op-parentheses
  18 -Winvalid-source-encoding
  13 -Wuninitialized
  11 -Wtautological-compare
  11 -Wlogical-not-parentheses
  11 -Wdangling-else
   9 -Wmismatched-new-delete
   8 -Wimplicit-function-declaration
   8 -Wheader-guard
   8 -Wcomment
   7 -Wtautological-constant-out-of-range-compare
   7 -Wself-assign
   6 -Wunused-value
   6 -Wunneeded-internal-declaration
   6 -Wtautological-pointer-compare
   6 -Wpointer-bool-conversion
   6 -Wparentheses-equality
   6 -Wdynamic-class-memaccess
   6 -Wconstant-conversion
   5 -Wpointer-sign
   4 -Wnull-conversion
   3 -Wunsequenced
   3 -Wreorder
   3 -Wknr-promoted-parameter
   3 -Wint-to-pointer-cast
   2 -Wstrncat-size
   2 -Wstring-compare
   2 -Wsometimes-uninitialized
   2 -Wconstant-logical-operand
   2 -Warray-bounds
   1 -Wunused-comparison
   1 -Wunknown-pragmas
   1 -Wstring-plus-int
   1 -Wpotentially-evaluated-expression
   1 -Wnon-literal-null-conversion
   1 -Wmismatched-tags
   1 -Wincompatible-pointer-types-discards-qualifiers
   1 -Wimplicit-int
   1 -Wignored-qualifiers
   1 -Wformat-extra-args
   1 -Wcompare-distinct-pointer-types
   1 -Wc++11-compat-deprecated-writable-strings


A couple -Wtautological-undefined-compare warnings:

warning: reference cannot be bound to dereferenced null pointer in well-defined 
C++ code; comparison may be assumed to always evaluate to false [-Wtautologica
l-undefined-compare]
if ( == NULL) {
 ^

warning: 'this' pointer cannot be null in well-defined C++ code; comparison may 
be assumed to always evaluate to false [-Wtautological-undefin
ed-compare]
  if(this == 0 || this == ) {
 ^~~~~

I'd like to just nuke these comparisions.


To fix the -Wunused-private-field private field warnings, I'd prefer to
delete them, but that would have the side effect of breaking the ABI if
an extensions use the class constructor.  The alternative would be to
mark them unused.  I don't think there are actually many cases of this.
The same warning gets generated anytime the header is included.


In the case of -Wshift-negative-value, result of shifting negative
values is undefined.  This is generally fixable by using unsigned values
instead.


I'm not sure what to about -Wunused-parameter.  It's probably a case by
case situation where it may sometimes make sense to have a variant
function that doesn't have that parameter and modify the callers.  The
alternative is to mark the argument as unused.  I haven't really
examined any of these in detail.


For -Wunused-const-variable and -Wunused-variable, I propose just
deleting them unless they are referenced by conditionally compiled code,
in which case I would make the variable declaration conditional as well.


I fixed one other case of -Winfinite-recursion.  I'm pretty sure this is
just one error, but it is contained in a header.


I think -Wshadow warnings should be fixed by renaming the variable.


I don't recall ever seeing -Wunused-function scroll by, but if functions
are totally unused, they should be deleted.


The parentheses warnings should just get fixed.


This is an example -Wdelete-non-virtual-dtor warning:

warning: delete called on non-final 'RscError' that has virtual functions but 
non-virtual destructor [-Wdelete-non-virtual-dtor]
delete pErrHdl;

My C++ book says that non-virtual destructors are bad generally bad.  We
also compile with -Wno-non-virtual-dtor to suppress even more warnings.
Does anyone know why?


The -Wformat-security warnings should definitely be fixed.


The -Wformat warnings should also be fixed, though care must be taken
for both 32-bit and 64-bit builds.


I haven't really looked at the other warnings in any detail.


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-10 Thread Andre Fischer 

On 05.03.2014 11:54, Andre Fischer wrote:

On 05.03.2014 09:30, Andre Fischer wrote:




I have created issue 124361 for this.  The 4555 warning is triggered 
by the hash_map wrapper in module stl_port/ when it includes 
unordered_map.  Luckily this allows us to turn of the warning 
temporarily for just this header.


Revision 1575930 enables exception support for all source files of sc.  
So if you experience any problems, this is the change to roll back :-)


-Andre


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Compiler warnings

2014-03-05 Thread Andre Fischer 
I am currently working on some bug in the sc module and find that it is 
really hard to even find compiler errors among the many warning 
messages.  Some of these warnings are caused directly by code in sc but 
the majority of the warnings originate in header files.  Platform is 
Windows.  The most annoying warnings are



   warning C4530: C++ exception handler used, but unwind semantics are 
not enabled. Specify /EHsc


and even more (because of the warning text that is repeated again and 
again)


warning C4555: expression has no effect; expected expression with 
side-effect


(see full text below)


Any ideas how to silence these two?

 re C4530: One option would be to compile all sc code with exceptions 
enabled.  Does anyone know of a reason not to do that?



Best regards,

Andre



PS: here is the complete output for one instance of the C4555 warning:

  C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1137) : 
warning C4555: expression has no effect; expected expression with 
side-effect
C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1126) : while 
compiling class template member function 'void 
std::list_Ty,_Ax::_Splice(std::list_Ty,_Ax::_Const_iterator_Secure_validation,std::list_Ty,_Ax 
,std::list_Ty,_Ax::_Const_iterator_Secure_validation,std::list_Ty,_Ax::_Const_iterator_Secure_validation,unsigned 
int,bool)'

with
[
_Ty=std::pairconst String,OpCode,
_Ax=std::allocatorstd::pairconst String,OpCode,
_Secure_validation=true
]
C:\PROGRA~2\MICROS~1.0\VC\include\xhash(205) : see reference to 
class template instantiation 'std::list_Ty,_Ax' being compiled

with
[
_Ty=std::pairconst String,OpCode,
_Ax=std::allocatorstd::pairconst String,OpCode
]
C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/unordered_map(86) : 
see reference to class template instantiation 'stdext::_Hash_Traits' 
being compiled

with
[
_Traits=std::tr1::_Umap_traitsString,OpCode,stdext::_Hash_compareString,formula::StringHashCode,std::equal_toString,std::allocatorstd::pairString,OpCode,false
]
C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\stl\hash_map(59) : 
see reference to class template instantiation 
'std::tr1::unordered_map_Kty,_Ty,_Hasher,_Keyeq,_Alloc' being compiled

with
[
_Kty=String,
_Ty=OpCode,
_Hasher=formula::StringHashCode,
_Keyeq=std::equal_toString,
_Alloc=std::allocatorstd::pairString,OpCode
]
C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\formula/FormulaCompiler.hxx(109) 
: see reference to class template instantiation 
'std::hash_map__K,__T,__H,__E' being compiled

with
[
__K=String,
__T=OpCode,
__H=formula::StringHashCode,
__E=std::equal_toString
]


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Herbert Duerr 

On 05.03.2014 09:30, Andre Fischer wrote:

I am currently working on some bug in the sc module and find that it is
really hard to even find compiler errors among the many warning
messages.  Some of these warnings are caused directly by code in sc but
the majority of the warnings originate in header files.  Platform is
Windows.  The most annoying warnings are


warning C4530: C++ exception handler used, but unwind semantics are
not enabled. Specify /EHsc

and even more (because of the warning text that is repeated again and
again)

warning C4555: expression has no effect; expected expression with
side-effect


The problem is in MSVC2008's list header. They probably fixed that in 
their newer versions. Another reason to update our build environment on 
that platform to something newer.


The warning expression has no effect itself is interesting enough, 
just not in in list header. Fortunately terms like list(1137) can be 
filtered out easily.



Any ideas how to silence these two?


We could disable such warnings altogether by adding e.g. the -wd4555 
option to CFLAGSWARNCXX in main/solenv/inc/wntmsci11.mk and 
main/solenv/gbuild/platform/windows.mk



  re C4530: One option would be to compile all sc code with exceptions
enabled.


That sounds reasonable.


 Does anyone know of a reason not to do that?


Not that I'm aware of.

Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Andre Fischer 

On 05.03.2014 10:01, Herbert Duerr wrote:

On 05.03.2014 09:30, Andre Fischer wrote:

I am currently working on some bug in the sc module and find that it is
really hard to even find compiler errors among the many warning
messages.  Some of these warnings are caused directly by code in sc but
the majority of the warnings originate in header files. Platform is
Windows.  The most annoying warnings are


warning C4530: C++ exception handler used, but unwind semantics are
not enabled. Specify /EHsc

and even more (because of the warning text that is repeated again and
again)

warning C4555: expression has no effect; expected expression with
side-effect


The problem is in MSVC2008's list header. They probably fixed that in 
their newer versions. Another reason to update our build environment 
on that platform to something newer.


The warning expression has no effect itself is interesting enough, 
just not in in list header. Fortunately terms like list(1137) can be 
filtered out easily.


Please explain how that can be filtered out easily.




Any ideas how to silence these two?


We could disable such warnings altogether by adding e.g. the -wd4555 
option to CFLAGSWARNCXX in main/solenv/inc/wntmsci11.mk and 
main/solenv/gbuild/platform/windows.mk


How do we do that only for the system headers?

-Andre


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Herbert Duerr 

On 05.03.2014 10:28, Andre Fischer wrote:

On 05.03.2014 10:01, Herbert Duerr wrote:

The warning expression has no effect itself is interesting enough,
just not in in list header. Fortunately terms like list(1137) can be
filtered out easily.


Please explain how that can be filtered out easily.


e.g. by piping the output through the command
perl -ne 'print if not /^.*list.1137/../^\S/'
It removes all list.1137 lines and their indented followup lines. 
Unfortunately also one more line but perl experts can probably fix that 
easily.


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Andre Fischer 

On 05.03.2014 11:28, Herbert Duerr wrote:

On 05.03.2014 10:28, Andre Fischer wrote:

On 05.03.2014 10:01, Herbert Duerr wrote:

The warning expression has no effect itself is interesting enough,
just not in in list header. Fortunately terms like list(1137) can be
filtered out easily.


Please explain how that can be filtered out easily.


e.g. by piping the output through the command
perl -ne 'print if not /^.*list.1137/../^\S/'
It removes all list.1137 lines and their indented followup lines. 
Unfortunately also one more line but perl experts can probably fix 
that easily.


Of course, on the command line this is easy, but I am building inside 
emacs.  Any idea how to do it there?


-Andre



Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Herbert Duerr 

On 05.03.2014 11:45, Andre Fischer wrote:

On 05.03.2014 11:28, Herbert Duerr wrote:

On 05.03.2014 10:28, Andre Fischer wrote:

On 05.03.2014 10:01, Herbert Duerr wrote:

The warning expression has no effect itself is interesting enough,
just not in in list header. Fortunately terms like list(1137) can be
filtered out easily.


Please explain how that can be filtered out easily.


e.g. by piping the output through the command
perl -ne 'print if not /^.*list.1137/../^\S/'
It removes all list.1137 lines and their indented followup lines.
Unfortunately also one more line but perl experts can probably fix
that easily.


Of course, on the command line this is easy, but I am building inside
emacs.  Any idea how to do it there?


As I don't use emacs I had to rely on my googling skills instead and 
found [1] that looks relevant. Does it help?


[1] 
http://stackoverflow.com/questions/206806/filtering-text-through-a-shell-command-in-emacs


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread John O'Sullivan 
Use MSVC's WD flag to disable the warning. You'll probably need to hack
wntmsci11.mk...
On 5 Mar 2014 08:31, Andre Fischer awf@gmail.com wrote:

 I am currently working on some bug in the sc module and find that it is
 really hard to even find compiler errors among the many warning messages.
  Some of these warnings are caused directly by code in sc but the majority
 of the warnings originate in header files.  Platform is Windows.  The most
 annoying warnings are


warning C4530: C++ exception handler used, but unwind semantics are not
 enabled. Specify /EHsc

 and even more (because of the warning text that is repeated again and
 again)

 warning C4555: expression has no effect; expected expression with
 side-effect

 (see full text below)


 Any ideas how to silence these two?

  re C4530: One option would be to compile all sc code with exceptions
 enabled.  Does anyone know of a reason not to do that?


 Best regards,

 Andre



 PS: here is the complete output for one instance of the C4555 warning:

   C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1137) : warning
 C4555: expression has no effect; expected expression with side-effect
 C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/list(1126) : while
 compiling class template member function 'void std::list_Ty,_Ax::_Splice(
 std::list_Ty,_Ax::_Const_iterator_Secure_validation,std::list_Ty,_Ax
 ,std::list_Ty,_Ax::_Const_iterator_Secure_validation,
 std::list_Ty,_Ax::_Const_iterator_Secure_validation,unsigned
 int,bool)'
 with
 [
 _Ty=std::pairconst String,OpCode,
 _Ax=std::allocatorstd::pairconst String,OpCode,
 _Secure_validation=true
 ]
 C:\PROGRA~2\MICROS~1.0\VC\include\xhash(205) : see reference to
 class template instantiation 'std::list_Ty,_Ax' being compiled
 with
 [
 _Ty=std::pairconst String,OpCode,
 _Ax=std::allocatorstd::pairconst String,OpCode
 ]
 C:\PROGRA~2\MICROS~1.0\VC\include\../../VC/include/unordered_map(86) :
 see reference to class template instantiation 'stdext::_Hash_Traits'
 being compiled
 with
 [
 _Traits=std::tr1::_Umap_traitsString,OpCode,stdext::_
 Hash_compareString,formula::StringHashCode,std::equal_to
 String,std::allocatorstd::pairString,OpCode,false
 ]
 C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\stl\hash_map(59) :
 see reference to class template instantiation 
 'std::tr1::unordered_map_Kty,_Ty,_Hasher,_Keyeq,_Alloc'
 being compiled
 with
 [
 _Kty=String,
 _Ty=OpCode,
 _Hasher=formula::StringHashCode,
 _Keyeq=std::equal_toString,
 _Alloc=std::allocatorstd::pairString,OpCode
 ]
 C:\source\trunk\git\main\solver\410\wntmsci12.pro\inc\
 formula/FormulaCompiler.hxx(109) : see reference to class template
 instantiation 'std::hash_map__K,__T,__H,__E' being compiled
 with
 [
 __K=String,
 __T=OpCode,
 __H=formula::StringHashCode,
 __E=std::equal_toString
 ]


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Andre Fischer 

On 05.03.2014 12:38, John O'Sullivan wrote:

Use MSVC's WD flag to disable the warning. You'll probably need to hack
wntmsci11.mk...


I wouldn't like to turn off this warning globally.  I only don't want to 
see it for system headers that I can't change anyway.


-Andre


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread jan i 
On 5 March 2014 12:46, Andre Fischer awf@gmail.com wrote:

 On 05.03.2014 12:38, John O'Sullivan wrote:

 Use MSVC's WD flag to disable the warning. You'll probably need to hack
 wntmsci11.mk...


 I wouldn't like to turn off this warning globally.  I only don't want to
 see it for system headers that I can't change anyway.


Use #pragma  to disable/enable the warnings. Put the #pragma around the
include statement.

rgds
jan I.

-Andre



 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Rob Weir 
On Wed, Mar 5, 2014 at 7:32 AM, jan i j...@apache.org wrote:
 On 5 March 2014 12:46, Andre Fischer awf@gmail.com wrote:

 On 05.03.2014 12:38, John O'Sullivan wrote:

 Use MSVC's WD flag to disable the warning. You'll probably need to hack
 wntmsci11.mk...


 I wouldn't like to turn off this warning globally.  I only don't want to
 see it for system headers that I can't change anyway.


 Use #pragma  to disable/enable the warnings. Put the #pragma around the
 include statement.


Or use a push/pop set of pragmas, which handles nested inclusion
scenarios safer:

http://msdn.microsoft.com/en-us/library/2c8f766e%28v=vs.90%29.aspx

-Rob


 rgds
 jan I.

 -Andre



 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread jan i 
On 5 March 2014 14:18, Rob Weir robw...@apache.org wrote:

 On Wed, Mar 5, 2014 at 7:32 AM, jan i j...@apache.org wrote:
  On 5 March 2014 12:46, Andre Fischer awf@gmail.com wrote:
 
  On 05.03.2014 12:38, John O'Sullivan wrote:
 
  Use MSVC's WD flag to disable the warning. You'll probably need to hack
  wntmsci11.mk...
 
 
  I wouldn't like to turn off this warning globally.  I only don't want to
  see it for system headers that I can't change anyway.
 
 
  Use #pragma  to disable/enable the warnings. Put the #pragma around the
  include statement.
 

 Or use a push/pop set of pragmas, which handles nested inclusion
 scenarios safer:

 http://msdn.microsoft.com/en-us/library/2c8f766e%28v=vs.90%29.aspx


If you use push/pop please check for platform, since this is not supported
by all C++ compilers, whereas #pragma alone is.

rgds
jan I.



 -Rob


  rgds
  jan I.
 
  -Andre
 
 
 
  -
  To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
  For additional commands, e-mail: dev-h...@openoffice.apache.org
 
 

 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Andre Fischer 

On 05.03.2014 10:01, Herbert Duerr wrote:

On 05.03.2014 09:30, Andre Fischer wrote:


  re C4530: One option would be to compile all sc code with exceptions
enabled.


That sounds reasonable.


 Does anyone know of a reason not to do that?


Not that I'm aware of.


I am neither, that's why I ask :-)

Exception support does make object files larger and possibly a bit 
slower.  The question is, is that significant?  Module sw nowadays has 
exception support for all its files.  And not changing at least the 
files in sc/ for which there are warnings might lead to memory leaks 
when there are exceptions.  So it is probably best to activate support 
for exceptions module wide.


-Andre



Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Andre Fischer 

On 05.03.2014 11:53, Herbert Duerr wrote:

On 05.03.2014 11:45, Andre Fischer wrote:

On 05.03.2014 11:28, Herbert Duerr wrote:

On 05.03.2014 10:28, Andre Fischer wrote:

On 05.03.2014 10:01, Herbert Duerr wrote:

The warning expression has no effect itself is interesting enough,
just not in in list header. Fortunately terms like list(1137) 
can be

filtered out easily.


Please explain how that can be filtered out easily.


e.g. by piping the output through the command
perl -ne 'print if not /^.*list.1137/../^\S/'
It removes all list.1137 lines and their indented followup lines.
Unfortunately also one more line but perl experts can probably fix
that easily.


Of course, on the command line this is easy, but I am building inside
emacs.  Any idea how to do it there?


As I don't use emacs I had to rely on my googling skills instead and 
found [1] that looks relevant. Does it help?


No, building in emacs works a little different.  But keep trying :-)

-Andre



[1] 
http://stackoverflow.com/questions/206806/filtering-text-through-a-shell-command-in-emacs


Herbert

-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread jan i 
On 5 March 2014 14:42, Andre Fischer awf@gmail.com wrote:

 On 05.03.2014 10:01, Herbert Duerr wrote:

 On 05.03.2014 09:30, Andre Fischer wrote:

re C4530: One option would be to compile all sc code with exceptions
 enabled.


 That sounds reasonable.

   Does anyone know of a reason not to do that?


 Not that I'm aware of.


 I am neither, that's why I ask :-)

 Exception support does make object files larger and possibly a bit slower.
  The question is, is that significant?  Module sw nowadays has exception
 support for all its files.  And not changing at least the files in sc/ for
 which there are warnings might lead to memory leaks when there are
 exceptions.  So it is probably best to activate support for exceptions
 module wide.


On ubuntu, the  slower is not measureable. It is basically to extra
function calls, and a word extra on heap, I assume it is identical on
windows.

On ubuntu object files seems to be 5-10% bigger, but the final exe (I use
this in e.g. genLang) in my case is less than 1% bigger.

I had problems with exceptions in modules where java is called (just a
warning).


rgds
jan I.


 -Andre
 Herbert


 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org



 -
 To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
 For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Andre Fischer 

On 05.03.2014 14:49, jan i wrote:

On 5 March 2014 14:42, Andre Fischer awf@gmail.com wrote:


On 05.03.2014 10:01, Herbert Duerr wrote:


On 05.03.2014 09:30, Andre Fischer wrote:

re C4530: One option would be to compile all sc code with exceptions

enabled.


That sounds reasonable.

   Does anyone know of a reason not to do that?
Not that I'm aware of.


I am neither, that's why I ask :-)

Exception support does make object files larger and possibly a bit slower.
  The question is, is that significant?  Module sw nowadays has exception
support for all its files.  And not changing at least the files in sc/ for
which there are warnings might lead to memory leaks when there are
exceptions.  So it is probably best to activate support for exceptions
module wide.


On ubuntu, the  slower is not measureable. It is basically to extra
function calls, and a word extra on heap, I assume it is identical on
windows.

On ubuntu object files seems to be 5-10% bigger, but the final exe (I use
this in e.g. genLang) in my case is less than 1% bigger.


Thanks, that is good to know.  I remember vaguely that the size increase 
on Solaris was more noticeable.   But that was years ago.


-Andre



I had problems with exceptions in modules where java is called (just a
warning).


rgds
jan I.



-Andre
Herbert


-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org





-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: Compiler warnings

2014-03-05 Thread Andre Fischer 

On 05.03.2014 14:18, Rob Weir wrote:

On Wed, Mar 5, 2014 at 7:32 AM, jan i j...@apache.org wrote:

On 5 March 2014 12:46, Andre Fischer awf@gmail.com wrote:


On 05.03.2014 12:38, John O'Sullivan wrote:


Use MSVC's WD flag to disable the warning. You'll probably need to hack
wntmsci11.mk...


I wouldn't like to turn off this warning globally.  I only don't want to
see it for system headers that I can't change anyway.



Use #pragma  to disable/enable the warnings. Put the #pragma around the
include statement.


Or use a push/pop set of pragmas, which handles nested inclusion
scenarios safer:

http://msdn.microsoft.com/en-us/library/2c8f766e%28v=vs.90%29.aspx

-Rob



Thanks John, Rob, Jan, I think I have this warning under control now.  
As suggested I use


#if defined(_MSC_VER)
#pragma warning(push)
#pragma warning(disable:4555)
#include ...
#pragma warning(pop)
#endif

After putting this in hash_map and still seeing warnings 4555 I thought 
that maybe not only the definition of the list template had to be 
treated this way but also the template instantiation, which would have 
required a lot more work.  Luckily I just had to do the same fix for the 
list template.  No more 4555.


-Andre



rgds
jan I.

-Andre



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org




-
To unsubscribe, e-mail: dev-unsubscr...@openoffice.apache.org
For additional commands, e-mail: dev-h...@openoffice.apache.org

Re: WaE: sw/source/filter/ww8 compiler warnings

2012-12-03 Thread chengjh 
Hi Pavel,

I committed some changes to solve the found warnings...Please help to
verify again..And I will have a check to the whole sw module to see whether
any missed warning is still existing.thanks.

On Fri, Nov 30, 2012 at 3:54 AM, Pavel Janík pa...@janik.cz wrote:

 Hi,

 current trunk issues few warnings in sw/source/filter/ww8:

 cc1plus: warnings being treated as errors
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/ww8par3.cxx:
 In member function ‘SwNumRule* WW8ListManager::GetNumRule(int)’:
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/ww8par3.cxx:1125:
 warning: comparison between signed and unsigned integer expressions
 make: *** [/Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/
 unxmacxi.pro/workdir/CxxObject/sw/source/filter/ww8/ww8par3.o] Error 1

 cc1plus: warnings being treated as errors
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:
 In member function ‘void WW8_WrtBookmarks::MoveFieldMarks(sal_uLong,
 sal_uLong)’:
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:317:
 warning: comparison between signed and unsigned integer expressions
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:
 In member function ‘int WW8Export::CollectGrfsOfBullets() const’:
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:1452:
 warning: comparison between signed and unsigned integer expressions
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:
 In member function ‘int WW8Export::GetGrfIndex(const SvxBrushItem)’:
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:1535:
 warning: comparison between signed and unsigned integer expressions
 make: *** [/Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/
 unxmacxi.pro/workdir/CxxObject/sw/source/filter/ww8/wrtww8.o] Error 1

 The following patch fixes these issues, but I'd like to see author
 committing the change:

 ===
 --- wrtww8.cxx  (revision 1415339)
 +++ wrtww8.cxx  (working copy)
 @@ -314,7 +314,7 @@
  {
  if (aItr-second)
  {
 -if (aItr-second-first == nFrom)
 +if (aItr-second-first == static_castlong(nFrom))
  {
  aItr-second-second.first = true;
  aItr-second-first = nTo;
 @@ -1449,7 +1449,7 @@
 if ( pGrf )
 {
 bool bHas = false;
 -   for (int i = 0; i 
 m_vecBulletPic.size(); ++i)
 +   for (unsigned int i = 0; i 
 m_vecBulletPic.size(); ++i)
 {
 if
 (m_vecBulletPic[i]-GetChecksum() == pGrf-GetChecksum())
 {
 @@ -1532,7 +1532,7 @@
 int nIndex = -1;
 if ( rBrush.GetGraphic() )
 {
 -   for (int i = 0; i  m_vecBulletPic.size(); ++i)
 +   for (unsigned int i = 0; i  m_vecBulletPic.size(); ++i)
 {
 if (m_vecBulletPic[i]-GetChecksum() ==
 rBrush.GetGraphic()-GetChecksum())
 {
 Index: ww8par3.cxx
 ===
 --- ww8par3.cxx (revision 1415339)
 +++ ww8par3.cxx (working copy)
 @@ -1122,7 +1122,7 @@

  SwNumRule* WW8ListManager::GetNumRule(int i)
  {
 -   if ( i = 0  i  maLSTInfos.size() )
 +   if ( i = 0  static_castsal_Size(i)  maLSTInfos.size() )
 return maLSTInfos[i]-pNumRule;
 else
 return 0;


 --
 Pavel Janík






-- 

Best Regards,Jianhong Cheng

Re: WaE: sw/source/filter/ww8 compiler warnings

2012-12-03 Thread Pavel Janík 
Hi!

On Dec 3, 2012, at 4:18 PM, chengjh wrote:

 I committed some changes to solve the found warnings...Please help to
 verify again..And I will have a check to the whole sw module to see whether
 any missed warning is still existing.thanks.

thanks. The module is almost clean now.

I only see:

sw/source/filter/ww8/ww8par3.cxx:1125: warning: comparison is always true due 
to limited range of data type

SwNumRule* WW8ListManager::GetNumRule(sal_uInt16 i)
{
if ( i = 0  i  maLSTInfos.size() )


surely i=0 when it is unsigned.
-- 
Pavel Janík

Re: WaE: sw/source/filter/ww8 compiler warnings

2012-12-03 Thread chengjh 
Sure,Pavel, after I have a clean build for this module, I get this warning
too, and I have already committed the change and don't find any other
warning..From that,I think my environment on Mac OS X 10.5.8 can identify
the same warning set with yours, but level is still less than yours because
I didn't catch any compile errors caused by these warnings.Before that,for
there are many output logs during build, the warning messages are mixed
among the output info,easily ignored if not leading to compile error. Now,I
use this way $build  out.txt to filter other output info and only
warnings left on the screen. Thus, I can get the compile warnings obviously.

I attach my configure parameter for your comparison. If you think this way
is valuable for other developers, could you please composite them and add
to the build guide as attention items when doing AOO build, especially
individual module build, to avoid the same issue in the future?Thanks.

./configure --with-dmake-url=
http://dmake.apache-extras.org.codespot.com/files/dmake-4.12.1.tar.bz2; \
  --with-epm-url=
http://ftp.easysw.com/pub/epm/3.7/epm-3.7-source.tar.gz; \
  --disable-mozilla --disable-build-mozilla
--enable-verbose --enable-category-b \
  --enable-minimizer --enable-presenter-console
--enable-wiki-publisher --disable-odk

On Tue, Dec 4, 2012 at 3:28 AM, Pavel Janík pa...@janik.cz wrote:

 Hi!

 On Dec 3, 2012, at 4:18 PM, chengjh wrote:

  I committed some changes to solve the found warnings...Please help to
  verify again..And I will have a check to the whole sw module to see
 whether
  any missed warning is still existing.thanks.

 thanks. The module is almost clean now.

 I only see:

 sw/source/filter/ww8/ww8par3.cxx:1125: warning: comparison is always true
 due to limited range of data type

 SwNumRule* WW8ListManager::GetNumRule(sal_uInt16 i)
 {
 if ( i = 0  i  maLSTInfos.size() )


 surely i=0 when it is unsigned.
 --
 Pavel Janík






-- 

Best Regards,Jianhong Cheng

Re: WaE: sw/source/filter/ww8 compiler warnings

2012-11-30 Thread chengjh 
I will have a look.

On Fri, Nov 30, 2012 at 3:54 AM, Pavel Janík pa...@janik.cz wrote:

 Hi,

 current trunk issues few warnings in sw/source/filter/ww8:

 cc1plus: warnings being treated as errors
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/ww8par3.cxx:
 In member function ‘SwNumRule* WW8ListManager::GetNumRule(int)’:
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/ww8par3.cxx:1125:
 warning: comparison between signed and unsigned integer expressions
 make: *** [/Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/
 unxmacxi.pro/workdir/CxxObject/sw/source/filter/ww8/ww8par3.o] Error 1

 cc1plus: warnings being treated as errors
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:
 In member function ‘void WW8_WrtBookmarks::MoveFieldMarks(sal_uLong,
 sal_uLong)’:
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:317:
 warning: comparison between signed and unsigned integer expressions
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:
 In member function ‘int WW8Export::CollectGrfsOfBullets() const’:
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:1452:
 warning: comparison between signed and unsigned integer expressions
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:
 In member function ‘int WW8Export::GetGrfIndex(const SvxBrushItem)’:
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:1535:
 warning: comparison between signed and unsigned integer expressions
 make: *** [/Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/
 unxmacxi.pro/workdir/CxxObject/sw/source/filter/ww8/wrtww8.o] Error 1

 The following patch fixes these issues, but I'd like to see author
 committing the change:

 ===
 --- wrtww8.cxx  (revision 1415339)
 +++ wrtww8.cxx  (working copy)
 @@ -314,7 +314,7 @@
  {
  if (aItr-second)
  {
 -if (aItr-second-first == nFrom)
 +if (aItr-second-first == static_castlong(nFrom))
  {
  aItr-second-second.first = true;
  aItr-second-first = nTo;
 @@ -1449,7 +1449,7 @@
 if ( pGrf )
 {
 bool bHas = false;
 -   for (int i = 0; i 
 m_vecBulletPic.size(); ++i)
 +   for (unsigned int i = 0; i 
 m_vecBulletPic.size(); ++i)
 {
 if
 (m_vecBulletPic[i]-GetChecksum() == pGrf-GetChecksum())
 {
 @@ -1532,7 +1532,7 @@
 int nIndex = -1;
 if ( rBrush.GetGraphic() )
 {
 -   for (int i = 0; i  m_vecBulletPic.size(); ++i)
 +   for (unsigned int i = 0; i  m_vecBulletPic.size(); ++i)
 {
 if (m_vecBulletPic[i]-GetChecksum() ==
 rBrush.GetGraphic()-GetChecksum())
 {
 Index: ww8par3.cxx
 ===
 --- ww8par3.cxx (revision 1415339)
 +++ ww8par3.cxx (working copy)
 @@ -1122,7 +1122,7 @@

  SwNumRule* WW8ListManager::GetNumRule(int i)
  {
 -   if ( i = 0  i  maLSTInfos.size() )
 +   if ( i = 0  static_castsal_Size(i)  maLSTInfos.size() )
 return maLSTInfos[i]-pNumRule;
 else
 return 0;


 --
 Pavel Janík






-- 

Best Regards,Jianhong Cheng

Re: WaE: sw/source/filter/ww8 compiler warnings

2012-11-30 Thread chengjh 
Hi Pavel, this is unnecessary checking, and it will be revised soon..Thanks
for your care.

On Sat, Dec 1, 2012 at 3:19 AM, Pavel Janík pa...@janik.cz wrote:


 On Nov 30, 2012, at 8:16 PM, Pavel Janík wrote:

 
  On Nov 30, 2012, at 12:04 PM, chengjh wrote:
 
  I will have a look.
 
  Next one:
 
 
 /Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/ww8graf.cxx:2749:
 warning: comparison between signed and unsigned integer expressions

 What does this code mean?

 if(pObject)
 {
 sal_uInt16 nCount = pObject ? pObject-GetUserDataCount()
 : 0;

 ?
 --
 Pavel Janík






-- 

Best Regards,Jianhong Cheng

WaE: sw/source/filter/ww8 compiler warnings

2012-11-29 Thread Pavel Janík 
Hi,

current trunk issues few warnings in sw/source/filter/ww8:

cc1plus: warnings being treated as errors
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/ww8par3.cxx: In 
member function ‘SwNumRule* WW8ListManager::GetNumRule(int)’:
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/ww8par3.cxx:1125:
 warning: comparison between signed and unsigned integer expressions
make: *** 
[/Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/unxmacxi.pro/workdir/CxxObject/sw/source/filter/ww8/ww8par3.o]
 Error 1

cc1plus: warnings being treated as errors
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx: In 
member function ‘void WW8_WrtBookmarks::MoveFieldMarks(sal_uLong, sal_uLong)’:
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:317: 
warning: comparison between signed and unsigned integer expressions
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx: In 
member function ‘int WW8Export::CollectGrfsOfBullets() const’:
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:1452: 
warning: comparison between signed and unsigned integer expressions
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx: In 
member function ‘int WW8Export::GetGrfIndex(const SvxBrushItem)’:
/Users/pavel/BUILD/BuildDir/ooo_trunk_src/sw/source/filter/ww8/wrtww8.cxx:1535: 
warning: comparison between signed and unsigned integer expressions
make: *** 
[/Users/pavel/BUILD/BuildDir/ooo_trunk_src/solver/350/unxmacxi.pro/workdir/CxxObject/sw/source/filter/ww8/wrtww8.o]
 Error 1

The following patch fixes these issues, but I'd like to see author committing 
the change:

===
--- wrtww8.cxx  (revision 1415339)
+++ wrtww8.cxx  (working copy)
@@ -314,7 +314,7 @@
 {
 if (aItr-second)
 {
-if (aItr-second-first == nFrom)
+if (aItr-second-first == static_castlong(nFrom))
 {
 aItr-second-second.first = true;
 aItr-second-first = nTo;
@@ -1449,7 +1449,7 @@
if ( pGrf )
{
bool bHas = false;
-   for (int i = 0; i  
m_vecBulletPic.size(); ++i)
+   for (unsigned int i = 0; i  
m_vecBulletPic.size(); ++i)
{
if 
(m_vecBulletPic[i]-GetChecksum() == pGrf-GetChecksum())
{
@@ -1532,7 +1532,7 @@
int nIndex = -1;
if ( rBrush.GetGraphic() )
{
-   for (int i = 0; i  m_vecBulletPic.size(); ++i)
+   for (unsigned int i = 0; i  m_vecBulletPic.size(); ++i)
{
if (m_vecBulletPic[i]-GetChecksum() == 
rBrush.GetGraphic()-GetChecksum())
{
Index: ww8par3.cxx
===
--- ww8par3.cxx (revision 1415339)
+++ ww8par3.cxx (working copy)
@@ -1122,7 +1122,7 @@
 
 SwNumRule* WW8ListManager::GetNumRule(int i)
 {
-   if ( i = 0  i  maLSTInfos.size() )
+   if ( i = 0  static_castsal_Size(i)  maLSTInfos.size() )
return maLSTInfos[i]-pNumRule;
else
return 0;


-- 
Pavel Janík