Clyde Smith-Stubbs <PICLIST@MITVMA.MIT.EDU> wrote:

>     if(fred = 1)
>
> .... is legal C, but almost certainly was meant to be
>
>     if(fred == 1)

    Clyde:

    I'm sure you already know this, but others might not:  If your
    compiler doesn't have an option to generate warnings when it
    sees simple assignments within "if" expressions (or an option to
    disable such assignments), you can prevent the bug by reordering
    the expression thusly:

        if (1 == fred)

    If you write your expressions this way, they'll still work fine,
    but if you make a mistake and accidentally write:

        if (1 = fred)

    the compiler will generate an error, since you can't assign
    anything to a constant.

    This doesn't work for "if" expressions that contain two
    variables rather than a variable and a constant, but it's a
    start.

    Reordering the operands is also useful in "for" and "while"
    expressions, and around "&&" and "||" operations.

> Then there's the hoary old trap that I still fall into occasionally:
>
>     if(fred & 0x60 == 0x20)
>
> which should have been
>
>     if((fred & 0x60) == 0x20)
>
> becuz & has a lower precedence than ==.

    Kim Otten (nee Cooper) and I have THIS favorite precedence bug:

        *ip++

    which, of course, should be:

        (*ip)++

    since unary operators associate right-to-left.

    -Andy

=== Andrew Warren - fastfwd@ix.netcom.com
=== Fast Forward Engineering - Vista, California
=== http://www.geocities.com/SiliconValley/2499