"C4127: conditional expression is constant" Huh?

Printable View

03-13-2008
cpjust

"C4127: conditional expression is constant" Huh?

Is my compiler crazy? (OK, it's VC++ 6.0, so that might be a trick question).
Code such as the following gives me C4127: conditional expression is constant

Code:

ASSERT(m_reader.m_szSourceCurrent + nNumEndSkip >= m_szSourceCurrent); ASSERT(this == &pNode->GetParent()); ASSERT(it != m_children.end());

How can those conditions possibly be constant??
03-13-2008
vart

It depends on the code
but if for example in the line above you have initialized
m_reader.m_szSourceCurrent = m_szSourc;

and nNumEndSkip is unsigned int

then first condition will be always true
03-13-2008
cpjust

I don't really see how, since nNumEndSkip can be any number, but I wonder if it has something to do with this being in an inline function?

Code:

inline void Bookmark::GetSubString(String& strString, int nNumEndSkip) { ASSERT(m_reader.m_szSourceCurrent + nNumEndSkip >= m_szSourceCurrent); ... }
03-13-2008
anon

Doesn't this warning tell you that an expression will always evaluate to true or false (that is, there is no real point in evaluating it at all)? C4127
03-13-2008
vart

Quote:

but I wonder if it has something to do with this being in an inline function?

I suppose so - compiler looks at the code there the parameters of the function are initialized - and probably makes some optimization - resulting in the conditional expression to be constant
03-13-2008
cpjust

Quote:

Originally Posted by anon

Doesn't this warning tell you that an expression will always evaluate to true or false (that is, there is no real point in evaluating it at all)? C4127

Yes, hence my confusion.

Quote:

Originally Posted by vart

I suppose so - compiler looks at the code there the parameters of the function are initialized - and probably makes some optimization - resulting in the conditional expression to be constant

I did a search for all the places where that function is called, and it looks like it always passes positive a constant as the 2nd parameter.
I'm not sure about all the other lines with that warning, but I'm guessing it's for a similar reason.
I hate when 3rd party code doesn't test their code with the highest warning levels... :(
03-13-2008
abachler

Sometimes optimizations throw too many warnings that are irrelevant. If its just a warning then ignore it. I leave warning on, but generally I ignore 99% of them.
03-13-2008
Elysia

Warnings are thrown because you aren't supposed to ignore them.
03-13-2008
laserlight

Quote:

Warnings are thrown because you aren't supposed to ignore them.

... unless they really are irrelevant. But yeah, leaving them on and then ignoring them may result in ignoring relevant warnings.
03-13-2008
Elysia

But if they are irrelevant, then you should suppress them. And in most cases, many warnings are not unfounded (read: not irrelevant).
03-13-2008
abachler

Whereas turning them off and then ignoring ensures you miss relevant ones. By ignoring, I don't mean I don't read them the first itme, it just means mostly I take no action as they are irrelevant. e.g.

\blah.cpp(15) : warning C4101: 'pTemp' : unreferenced local variable

irrelevant. used for debugging purposes, so Im not about to remove its definition, but irrelevant to the proper operation fo the app. And I dont realyl have the time to put in a pragma for every warning liek this.
03-13-2008
Elysia

You can just add "pTemp;" to get rid of it. Temporarily.
03-13-2008
anon

I somehow doubt that the compiler can emit warnings based on what parameters the function was called with. If it is warning that some condition will be always true/false, I would expect there to be something in the code that makes it so sure about it.

It is telling you that the code as it is, is potentially wrong. It shouldn't mean that in the context of this current program, some condition is always true/false - if that might change if the function is called with different arguments. In this case it means that you might be asserting things that cannot happen because of the code logic.

Do all those ASSERTs trigger the warning? Could you perhaps post the full function (and class declaration)?
03-13-2008
anon

Quote:

Originally Posted by Elysia

You can just add "pTemp;" to get rid of it. Temporarily.

And get an "expression has no effect" warning instead? :)

(Debug things probably might be compiled conditionally in the first place?)
03-13-2008
Elysia

Quote:

Originally Posted by anon

And get an "expression has no effect" warning instead? :)

It doesn't do that. Not in Visual Studio at the very least.
03-13-2008
anon

Quote:

Originally Posted by Elysia

It doesn't do that. Not in Visual Studio at the very least.

Too bad for Visual Studio then. Statements that have no effect are normally quite bad.

But then this "fix" isn't really portable. :)
03-13-2008
Elysia

Quote:

Originally Posted by anon

Too bad for Visual Studio then. Statements that have no effect are normally quite bad.

Are not. The compiler will ignore them anyway.
And it's a great way to remove the "unreferenced" warning.
I think it's a good thing.
03-13-2008
vart

Quote:

The compiler will ignore them anyway

That's the point. In most contexts you do not write a code to be ignored by the compiler. So when such a code is encountered - it is very likely to be an error
03-13-2008
Elysia

Ah yes, but they do work fine for things such as suppressing warnings, if the compiler supports it. I think it is a good feature, anyway.
03-13-2008
vart

I'm using following macro for unused function argumants - but I do not know if some compiler
will complain
(unused local vars I just remove or place inside proper #ifdefs)

Code:

#define UNUSED_ARG(_arg) if (_arg) {}
03-13-2008
anon

Wouldn't it be quite easy to do this?

Code:

void foo(int , int y) //first argument is unused { //use y }
03-13-2008
Elysia

Yep, that's what I do for function arguments.
03-13-2008
vart

Quote:

Originally Posted by anon

Wouldn't it be quite easy to do this?

I write mostly in C
03-13-2008
cpjust

I'll give you another example:

Code:

void func( char* str, int num ) { ASSERT( num < 50 ); ... // num isn't used anywhere else. }

I encountered some 3rd party code similar to this. Since they use the ASSERT() macro, num is used in Debug mode but not in Release mode. God only knows what the point is of this, but I didn't write it and I don't want to risk breaking anything, so the only ways of silencing the warning about unused parameter is either use a #pragma, or add num; to make the compiler shut up.

#pragma statements (and warning numbers/messages) are different between compilers, so I chose num; instead.
03-13-2008
swoopy

>Statements that have no effect are normally quite bad.
Agreed.
03-13-2008
anon

To do VC++ justice, it seems that only expressions of type p; don't cause a warning. If there's an operator or such thrown into the mix, you get the "effectless statement" warning (e.g a + b; ).

I could still imagine such a situation where a warning might draw attention to a problem:

Code:

//global int c; void foo() { int a, b; c; //one semicolon by mistake ... }
03-13-2008
Elysia

I don't think I've ever done such a mistake...
But then, if you tried to use c, you'd get an undeclared warning and it should be pretty obvious then that you have done a mistake there...
03-13-2008
anon

I think I have made such mistakes (semicolon instead of comma), and in this example there is a global int c. Meaning the whole function will use this, instead of a local c that was supposed to shadow it.

It is a contrived example, though...