Annoying compiler warning

[Bob]

Hi,

I have been trying to use some inventive alternative idioms for infinite
loops in my code, rather than the same old for(; and while(1) - this
could be a nice amusing Easter-egg for any future maintenance
programmers!

One of my ideas was this:

unsigned u = SHRT_MAX << 2; // misleading initialization - tee hee!
while(++u>=0)
{
// loop
}

Unfortunately, the compiler gives a warning for this, which rather
spoils the fun... does the compiler have to give a diagnostic here, and
can anyone think of a way of using the same basic idea but without
generating a warning?

 

[pete]

Hi,

I have been trying to use some inventive alternative
idioms for infinite
loops in my code, rather than the same old for(; and while(1) - this
could be a nice amusing Easter-egg for any future maintenance
programmers!

One of my ideas was this:

unsigned u = SHRT_MAX << 2; // misleading initialization - tee hee!
while(++u>=0)
{
// loop
}

Unfortunately, the compiler gives a warning for this, which rather
spoils the fun...
does the compiler have to give a diagnostic here,

If it did, I could look it up.

and can anyone think of a way
of using the same basic idea but without generating a warning?

How to suppress an unidentified warning?
That's not a bad one.

unsigned u = SHRT_MAX / 1000;
while(--u >= 0u)
{
// loop
}

 

[pete]

Hi,

I have been trying to use some inventive alternative idioms for infinite
loops in my code, rather than the same old for(; and while(1) - this
could be a nice amusing Easter-egg for any future maintenance
programmers!

One of my ideas was this:

unsigned u = SHRT_MAX << 2; // misleading initialization - tee hee!
while(++u>=0)
{
// loop
}

Unfortunately, the compiler gives a warning for this, which rather
spoils the fun...
does the compiler have to give a diagnostic here, and
can anyone think of a way of using the same basic idea but without
generating a warning?

unsigned u;

for (u = 1 /* or any odd number */ ; u++ > 0u; ++u)
{
// loop
}

 

[John Smith]

Hi,

I have been trying to use some inventive alternative idioms for infinite
loops in my code, rather than the same old for(; and while(1) - this
could be a nice amusing Easter-egg for any future maintenance
programmers!

One of my ideas was this:

unsigned u = SHRT_MAX << 2; // misleading initialization - tee hee!
while(++u>=0)
{
// loop
}

Unfortunately, the compiler gives a warning for this, which rather
spoils the fun... does the compiler have to give a diagnostic here, and
can anyone think of a way of using the same basic idea but without
generating a warning?

What message do you get from the compiler ?

Works for me with #include <limits.h>

 

[James Kuyper]

pete said:



Much better.

But still capable of triggering a compiler warning from a sufficiently
clever compiler.

 

[Richard Heathfield]

pete said:

How to suppress an unidentified warning?
That's not a bad one.

unsigned u = SHRT_MAX / 1000;
while(--u >= 0u)

I get a warning for that code:

foo.c:6: warning: comparison of unsigned expression >= 0 is always true

 

[Richard Heathfield]

pete said:

unsigned u;

for (u = 1 /* or any odd number */ ; u++ > 0u; ++u)

Much better.

 

[Richard Bos]

I have been trying to use some inventive alternative idioms for infinite
loops in my code, rather than the same old for(; and while(1) - this
could be a nice amusing Easter-egg for any future maintenance
programmers!

May I suggest a different kind of solution for your problem?

Ok, then I suggest that you _not_ be a pain in the arse for your
successor.

Richard

 

[Spiros Bousbouras]

Hi,

I have been trying to use some inventive alternative idioms for infinite
loops in my code, rather than the same old for(; and while(1) - this
could be a nice amusing Easter-egg for any future maintenance
programmers!

One of my ideas was this:

unsigned u = SHRT_MAX << 2; // misleading initialization - tee hee!
while(++u>=0)
{
// loop

}

Unfortunately, the compiler gives a warning for this, which rather
spoils the fun... does the compiler have to give a diagnostic here...

No , the compiler doesn't have to give a warning but
I would expect from any decent diagnostic tool (which
includes a compiler with all warnings on) to warn you
that the while test is always true.

 

[Keith Thompson]

I have been trying to use some inventive alternative idioms for infinite
loops in my code, rather than the same old for(; and while(1) - this
could be a nice amusing Easter-egg for any future maintenance
programmers!

One of my ideas was this:

unsigned u = SHRT_MAX << 2; // misleading initialization - tee hee!
while(++u>=0)
{
// loop
}

If you do this kind of thing in production code, I hope I never have
to work with you.

Unfortunately, the compiler gives a warning for this, which rather
spoils the fun...

[...]

Good for the compiler. You should pay attention to the warning and
write clear code -- "for thy creativity is better used in solving
problems than in creating beautiful new impediments to understanding"
(Henry Spencer, "The Ten Commandments for C Programmers").

 

[Bob]

unsigned u;

for (u = 1 /* or any odd number */ ; u++ > 0u; ++u)
{
// loop
}

Cool! That's a really neat solution, thanks.

The life of a maintenance programmer is a pretty boring one, and I think
finding the odd little amusement must make the task more fun!

 

[Ian Collins]

But still capable of triggering a compiler warning from a sufficiently
clever compiler.

How about:

for( u = 1; u&1; u += 2 )

 

[CBFalconer]

.... snip ...

unsigned u;

for (u = 1 /* or any odd number */ ; u++ > 0u; ++u)
{
// loop
}

More useful snippet:

puts("Enter answer:"); fflush(stdout);
for (u = 1; u++; ++u) continue;

 

[Walter Roberson]

James Kuyper wrote:

How about:

for( u = 1; u&1; u += 2 )

Theoretically, UINT_MAX could be even, which would lead to a wrapping
to 0 at the end of the first pass of the loop. I'm not certain
it would be allowed with C99, but C89 has fewer restrictions on
value representation and could (I believe) have a non-binary
value system.

Hmmm... let's see... unsigned char is guaranteed not to have any
trap value, but I don't recall that the same applies to unsigned
int, so (for example) UINT_MAX could be 2^N-2 and 2^N-1 could be
a trap value. Might be a bit of a nuisance to convert unsigned
long to unsigned int if it were that way: UINT_MAX+1 is repeatedly
subtracted, which in the nice binary case corresponds to just dropping
leading bits, but if UINT_MAX is 2^N-2 then you effectively
end up subtracting the higher order bytes from the lower order bytes
to make the wrapping semantics come out right. Something for the DS9001
perhaps.

 

[Richard Heathfield]

Walter Roberson said:

Theoretically, UINT_MAX could be even,

How?

 

[Flash Gordon]

Bob wrote, On 20/12/07 01:29:

Cool! That's a really neat solution, thanks.

The life of a maintenance programmer is a pretty boring one, and I think
finding the odd little amusement must make the task more fun!

Having done maintenance work I can tell you that I would take the effort
to work back through the changes to find out who put that in and then
recommend to the head of development that they get rid of the person
responsible and the people who let the code through review.

If you want to do it for an IOCC entry, fine, if you want to do it for
your own amusement, fine. If you really are doing it to make the life of
a maintenance programmer "more fun" then you should not be working on
software at all, not as a job and not as a contributor to open source
projects.

 

[Ben Bacarisse]

Theoretically, UINT_MAX could be even,

I don't think so.

which would lead to a wrapping
to 0 at the end of the first pass of the loop. I'm not certain
it would be allowed with C99, but C89 has fewer restrictions on
value representation and could (I believe) have a non-binary
value system.

No, C89 says: "The representations of integral types shall define
values by use of a pure binary numeration system."

Hmmm... let's see... unsigned char is guaranteed not to have any
trap value, but I don't recall that the same applies to unsigned
int, so (for example) UINT_MAX could be 2^N-2 and 2^N-1 could be
a trap value.

UINT_MAX is defined to be the maximum value of an object of unsigned
int type. This type is made up of N value bits whose values are
consecutive powers of two from 2^0 upwards. I can see no permission
for some values to be excluded from UINT_MAX.

unsigned int can have trap representations, but a bit is either a
value bit or a non-value bit. If the "top" bit is a value bit, all
values where it is combined with settings of the other values bits are
legal and permitted. If it is a padding bit, then you have fewer
value bits (N is one less) but UINT_MAX is still 2^N - 1.

This is from C99 and there may be more wriggle room in C89, but if so,
I would guess it is unintended.

 

[James Kuyper]

How about:

for( u = 1; u&1; u += 2 )

A compiler is free to complain about anything it wants to. Any idiom for
a loop that never exits that is sufficiently clear to not count as
obfuscated is sufficiently simple that a sufficiently clever compiler
can recognize it. And a loop that never exits is a reasonable thing for
a compiler to warn about.
There's no guaranteed way to avoid such a message; the best you can do
is find a way that silences the messages that a particular compiler
generates, or learn to live with the warning messages.

 

[James Kuyper]

Cool! That's a really neat solution, thanks.

The life of a maintenance programmer is a pretty boring one, and I think
finding the odd little amusement must make the task more fun!

Your little amusement may end up causing problems when the next
maintenance programmer wastes time trying to figure out the purpose of
your loop control. Write clear, easy to understand code, and let the
warnings fall where they may.

 

[James Kuyper]

Theoretically, UINT_MAX could be even,

Section 6.2.6.2p1 of the C99 standard is quite clear about this; if N is
the number of value bits in an unsigned type, the corresponding maximum
is 2^N-1, which is inherently never a negative number.
There's no correspondingly specific description for signed integer types.