Stephan Bergmann wrote:
[...]
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 correspondi
Hi,
Eike Rathke wrote:
Hi Stephan,
On Wed, Aug 31, 2005 at 10:04:47 +0200, Stephan Bergmann wrote:
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
that only weird code would relay on the evaluation in c
Hi Stephan and all,
this is an answer to the _original_ posting!
Stephan Bergmann wrote:
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 n
Hi Eike,
Eike Rathke wrote:
Hi Stephan,
On Wed, Aug 31, 2005 at 10:04:47 +0200, Stephan Bergmann wrote:
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
that only weird code would relay on the evaluation
Hi Stephan,
On Wed, Aug 31, 2005 at 10:04:47 +0200, Stephan Bergmann wrote:
> >Sorry for the (may be stupid) question, but why not just change
> >OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
> >that only weird code would relay on the evaluation in case of a zero
> >
Hi Kay,
> Propagating errors is the broader concept, comparing assertions and
> error propagation. So, if in doubt, propagate! Never swallow unclear
> situations (especially _not_ in _production_ code, following effects may
> destroy valuable data), upper levels may know what to do or at least
Hi Kay,
Kay Ramme - Sun Germany - Hamburg wrote:
Just some (selected :-) examples:
case PROPERTY_ID_REFVALUE :
147 OSL_VERIFY( _rValue >>= m_sReferenceValue );
148 calcValueExchangeType();
149 break;
150
151 case PROPERTY_ID_UNCHECKED_REFVALU
Joerg,
Joerg Barfurth wrote:
Hi,
Kay Ramme - Sun Germany - Hamburg wrote:
Joerg Barfurth wrote:
I agree. If they signal runtime conditions that prevent normal
operations, they can be converted to exceptions, otherwise they should
be dealt with or propagated as approriate. (I think i
Hi,
Kay Ramme - Sun Germany - Hamburg wrote:
Joerg Barfurth wrote:
It is the very purpose of OSL_VERIFY to evaluate the expression
regardless of debug level. For expressions without side effect
OSL_ASSERT/OSL_ENSURE should be used instead.
It is used to avoid cluttering the code with extra
Joerg Barfurth wrote:
Hi Kay,
Kay Ramme - Sun Germany - Hamburg wrote:
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would
expect that only weird code would relay on the evaluation in case of a
zero debug level. An
Stephan Bergmann wrote:
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 un
Hi Kay,
Kay Ramme - Sun Germany - Hamburg wrote:
Sorry for the (may be stupid) question, but why not just change
OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
that only weird code would relay on the evaluation in case of a zero
debug level. And these case can probab
Jens-Heiner Rechtien wrote:
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
Stephan,
Stephan Bergmann wrote:
Maybe we could, but *not* on CWS warnings01. We already have enough to
do here to get rid of all warnings. If we take the burden of any
additional clean up (like unifying OSL_ENSURE and OSL_ASSERT) that is
not directly necessary to get rid of warnings, we
Hi Kay,
> Sorry for the (may be stupid) question, but why not just change
> OSL_VERIFY to emit nothing, in case OSL_DEBUG_LEVEL == 0? I would expect
> that only weird code would relay on the evaluation in case of a zero
> debug level.
Why "weird"? The alternative is something like
#if OSL_DE
Kay Ramme - Sun Germany - Hamburg wrote:
Stephan Bergmann wrote:
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 d
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.
Stephan Bergmann wrote:
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 unx
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 spuriou
19 matches
Mail list logo
