Speaking of STLPort: It seems that these incredible number of
ANACHRONISM warnings regarding missing typenames on unxsols4 and
unxsoli4 can be fixed with a single line of change in STLPort. I'll
suggest that we fix this one in another CWS which has a chance to get in
OOo 2.0, if Martin agrees.
Heiner
Stephan Bergmann wrote:
As anounced elsewhere, we want to discuss here all C/C++ compiler
warnings we stumble over on CWS warnings01 and that we want to disable.
Now, I have three issues to discuss:
1 STLport
I already wrote this before, but maybe it did not get the necessary
attention. To ensure that all spurious warnings from within any STLport
headers are suppressed, the following changes are necessary:
On unxsoli4 and unxsols4 the warnings inllargeuse ("function is too
large and will not be expanded inline") and notemsource ("Could not find
source for function") are globally disabled in each compilation unit
(regardless of whether or not it includes an STLport header), because
those warnings seem to only be generated at the end of a compilation unit.
On wntmsci10 the warnings 4514 ("unreferenced inline function has been
removed") and 4710 ("function not inlined") are globally disabled in
each compilation unit that includes an STLport header, from the point of
inclusion onwards, because those warnings seem to only be generated at
the end of a compilation unit.
2 doubunder
On unxsoli4 and unxsols4, to suppress the doubunder warning "There are
two consecutive underbars in __sal_NoAcquire", IMO it is best to disable
doubunder globally. For one, __sal_NoAcquire is part of our published
API, so we cannot easily change it, and for another, there are probably
more similarly broken identifiers waiting for us in the rest of the code.
3 OSL_VERIFY
On unxsoli4 and unxsols4 PRODUCT builds, OSL_VERIFY(a == b) causes a
spurious warning "The result of a comparison is unused" (because the
argument of OSL_VERIFY is always executed, even for OSL_DEBUG_LEVEL ==
0). Instead of disabling the corresponding unxsoli4 and unxsols4
warning, I would vote to change code
OSL_VERIFY(e);
to
if (!e) {
OSL_ASSERT(false);
}
(and thus work around the warning) on the ground that OSL_VERIFY is
dangerous and confusing---unlike the other OSL diagnose functions, it
*does* evaluate its argument for OSL_DEBUG_LEVEL == 0. In the interest
of the "least surprise" principle, we IMO should deprecate OSL_VERIFY
and replace all its occurrences as described above.
-Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
