Alternatives to modifying loop var in the loop.

[Aleksandar Kuktin]

(e-mail address removed) (Joe keane) writes:
That particular warning is not enabled by default so you can simply,
well, not enable it. I guess that's sort of like turning it off.

How about this:

const char foo[6] = "abcdef";

What about it? What are you asking? (gcc 4.7.2 at least doesn't warn
about it with "-Wall -Wextra".)

No NULL terminator. String six chars long is stored in a buffer six
chars long.

True - which might or might not be a problem, depending upon whether or
not the author intended that to be the case. Keith was probably well
aware of that - the question is, what was Joe's point in bringing that
up?

Apologies - I'm too trigger happy for my own good.

I thought this is part of the str* discussion in the other part of the
thread. And, in that context, I assumed Joe was asking bringing up
something along the lines strlcpy vs. non-terminated string but, again, I
confused the discussion in which this series of posts appears.

 

[Keith Thompson]

That particular warning is not enabled by default so you can simply,
well, not enable it. I guess that's sort of like turning it off.

How about this:

const char foo[6] = "abcdef";

What about it? What are you asking? (gcc 4.7.2 at least doesn't warn
about it with "-Wall -Wextra".)

No NULL terminator. String six chars long is stored in a buffer six chars
long.

Yes, I know. BTW, NULL is (a macro that expands to) a null *pointer*
constant; it shouldn't be used to refer to the null character.

 

[Aleksandar Kuktin]

Yes, I know. BTW, NULL is (a macro that expands to) a null *pointer*
constant; it shouldn't be used to refer to the null character.

Sorry for the noise. Confused the discussion.

 

[Keith Thompson]

Odd - I've used that construct occasionally, and I always wrote it the
first way, which seems more natural to me. My compiler doesn't warn
about that issue with the settings I use.


How do you decide when to stop adding !=0? All of the following mean the
same thing:

while (a)
while (a!=0)
while ((a!=0) !=0)
etc.

My policy is to stop adding !=0 before the first time.

My policy (not to imply that there's anything wrong with yours)
is to use an explicit comparison when the value being tested is not
"boolean", i.e., when it carries information beyond "zero is false,
non-zero is true". For example, I don't use a pointer value directly
as a condition; I'd write "if (ptr != NULL)" rather than "if (ptr)".

 

[Ben Bacarisse]

[...] If I have to change

while (*d++=*s++);

to

while ((*d++ = *s++) != 0)

How do you decide when to stop adding !=0?

He stops there, because that form (apparently) silences a warning. The
explanation was in the immediately following text that got snipped: "If
I have to change ... to ... /to avoid warnings that's fine with me/.".

 

[James Kuyper]

[...] If I have to change

while (*d++=*s++);

to

while ((*d++ = *s++) != 0)

How do you decide when to stop adding !=0?

He stops there, because that form (apparently) silences a warning. The
explanation was in the immediately following text that got snipped: "If
I have to change ... to ... /to avoid warnings that's fine with me/.".

Yes, but he also explaining that he was willing to turn off warnings
that he considered unjustified - implying that he considers this one
justified. I'm don't remember if my compiler has the option to warn
about such things, but if it did, I've turned it off. So my question was
equivalent to asking "why don't your turn that warning off?".

 

[glen herrmannsfeldt]

(e-mail address removed) (Joe keane) writes:

(snip)

How about this:
const char foo[6] = "abcdef";

(snip)
No NULL terminator. String six chars long is stored in a
buffer six chars long.

No, not a string but six characters are stored there.

It is short for:

const char foo[6]={'a', 'b', 'c', 'd', 'e', 'f',};

which has many uses. (Among others, note that sizeof gives
the right size in both cases, but not if you add the null.)

If you really want the string, leave off the 6, the compiler will
count them for you, including the null. Compilers count better
than people do.

-- glen

 

[glen herrmannsfeldt]

(e-mail address removed) wrote:

(snip)

One of the warnings is for "result of assignment cannot be
used as controlling expression of an if, for, or while statement".
If you write "if (a = b)... " it is obviously not clear whether
you meant it or meant to use "==". Several ways to tell the
compiler "I meant it". One is to write "if ((a = b))...", another
is "if ((a = b) != 0)...". The first one looks daft to me,
so I use the second.

The wording doesn't sound like warning wording. "Cannot"
should be used for violations of the standard language.
Maybe "should not" or "preferably not" would be better.

The second warning is to avoid code like

for (i = 0; i < n; ++i);
a = 0;

or

if (x > 0);
++x;

which both most likely do _not_ do what the programmer intended.

I usually put at least one space. I suppose some might use {}.

Since the above loop has no other effect than to set i equal to n,
unless n is negative, I wouldn't be against the warning.

If the loop has more useful side effects, though, I would rather
not have a warning.

I don't remember ever having made that mistake.

And there are really two criteria for deciding which warnings
to enable: (1) How likely is it if I get the warning that it
is actually a bug in my code, and (2) how much of a pain is it
to write code that avoids the warning when it is not justified.
In the string copy loop, the change is quite trivial.

It is always cost vs. benefit. Reading warnings takes time,
and so has a cost. The cost, multiplied by its probability
should be balanced against the benefit, that is, the cost
and probability of missing the bug.

-- glen