"Writing Solid Code" - compiler warnings 
Author Message
 "Writing Solid Code" - compiler warnings

Quote:

>McGuire recommends this circumlocution:
>        while(ready_to_go() != TRUE)
>                NULL;    /* wait until ready */

Ugh!  Don't we already have enough confusion about what NULL means? ;-)

I suggest you #define NOP to zero and use that instead.

However, note that in both cases the compiler may generate a warning such as
"warning: statement with no effect".

Ian Collier



Wed, 17 Apr 1996 01:50:39 GMT  
 "Writing Solid Code" - compiler warnings

Quote:



> >McGuire recommends this circumlocution:

> >        while(ready_to_go() != TRUE)
> >                NULL;    /* wait until ready */

> Ugh!  Don't we already have enough confusion about what NULL means? ;-)

> I suggest you #define NOP to zero and use that instead.

> However, note that in both cases the compiler may generate a warning such as
> "warning: statement with no effect".

Why not just:

       while(ready_to_go() != TRUE)
             ;    /* wait until ready */

The semicolon on its own line (especially with the comment) is not
particularly confusing. The only time the null loop like this is
confusing is when the semicolon is on the first line:

       while(ready_to_go() != TRUE);  /* Ugh! */

******************************************************************

Transarc Corporation                    
The Gulf Tower, 707 Grant Street
Pittsburgh, PA 15219
(412) 338-4442



Wed, 17 Apr 1996 03:53:02 GMT  
 "Writing Solid Code" - compiler warnings

Quote:

>Why not just:

>       while(ready_to_go() != TRUE)
>             ;    /* wait until ready */

Why not:

        while ( !ready_to_go() )
            continue;

The comparison to TRUE is odious, and the continue keyword makes it
obvious what's going on.

--
#include        <standard.disclaimer>
 _
Kevin D Quitt 91351-4454                96.37% of all statistics are made up



Wed, 17 Apr 1996 08:44:04 GMT  
 "Writing Solid Code" - compiler warnings

Quote:


>>McGuire recommends this circumlocution:

>>        while(ready_to_go() != TRUE)
>>                NULL;    /* wait until ready */

>Ugh!  Don't we already have enough confusion about what NULL means? ;-)

I agree - the above suggestion is awful.

Also it's really bad style to compare things to TRUE, since
in C by convention anything nonzero is true, but x != TRUE will
be false if eg. x = 2 or x = -1.

Quote:
>I suggest you #define NOP to zero and use that instead.

>However, note that in both cases the compiler may generate a warning such as
>"warning: statement with no effect".

Yes.  I suggest that you write
        while(!read_to_go())
                continue;       /* wait until ready */

This should get past even the fussiest compilers without a warning, I think.
Does anyone know of a compiler that would give a warning for the above code?

--



Thu, 18 Apr 1996 15:11:10 GMT  
 "Writing Solid Code" - compiler warnings
 > >        while(ready_to_go() != TRUE)
 > >                NULL;    /* wait until ready */

Please correct me if I'm wrong (ooo, boy ... I'm opening myself up
here), but isn't that a bit shaky?  FALSE is pretty universally
considered to be '0', but I've seen TRUE defined as everything from '1'
to '!FALSE'.

Moving from one compiler to another could cause problems.  Besides, I
saw plenty of examples in the book that went like:

      while(!fReadyToGo())
            NULL;

But, anyway ...

 >
 > I suggest you #define NOP to zero and use that instead.
 >
 > However, note that in both cases the compiler may generate a
 > warning such as
 > "warning: statement with no effect".

A way around that would be to

#define     NOP

as opposed to

#define      NOP   0

That would still work, _and_ avoid the compiler warning.  However,
things would get crazy if you forget the ';' after.

-Scotty

---------------------------------------------------------------------
 Scott Walter                     | "I'm sorra, sir ... I kinna fit
 Gateway Administrator            |  anah muhr on th' floppy!  Ye
 MinnTelligence On-Line (MOLe)    |  jes' kinna mess w' th' laws o'

---------------------------------------------------------------------
     "It's not a bug ... nor a feature ... it's an ENHANCEMENT!"

 * Origin: (1:3821/6)



Thu, 18 Apr 1996 09:14:02 GMT  
 "Writing Solid Code" - compiler warnings


Quote:


> > >McGuire recommends this circumlocution:
> > >        while(ready_to_go() != TRUE)
> > >                NULL;    /* wait until ready */

(Quick note: Others have already posted why the comparison against TRUE
is hazardous, I just wanted to point out that, despite the comment
otherwise, the code above is NOT an extract from "Writing Solid Code."
The book itself covers the "comparison against TRUE" problem on page
235.)

Quote:

> >Why not just:

> >       while(ready_to_go() != TRUE)
> >             ;    /* wait until ready */

> Why not:

>    while ( !ready_to_go() )
>        continue;

> The comparison to TRUE is odious, and the continue keyword makes it
> obvious what's going on.

I've just finished reading this thread and, as the author of "Writing
Solid Code," I'm pleased to see that people are talking about optional
compiler warnings.

There does seem to be a bit of confusion about what "Writing Solid
Code" says on the topic.  From many of the posts, it sounds as if WSC
comes out and staunchly declares that there is One True Null Statement
Workaround or that a specific compiler warning must produce a specific
error message.  WSC doesn't say either of those things.

What "Writing Solid Code" does say is that to catch bugs more easily,
programmers should enable every optional compiler warning that they
have available.  WSC does not promote specific warnings or warning
messages; it merely urges programmers to use the warnings they have,
and to be proactive about asking compiler and lint vendors for new
warnings that would help in writing bug-free code.

I think this is clear from Jim Van Zandt's original post:

| I've been reading Steve Maguire's new book -- it's _great_.
| He suggests programmers complain to their compiler suppliers
| about inadequate warnings.  Of course, reaching a consensus first would
| help.  Can we agree on what we would like?

I'd rather "suggest adding new optional compiler warnings" than
"complaining about inadequate ones," but it's clear that Jim got the
points I was making in the section.  The emphasis is on using the
warnings you have, and asking for additional warnings, not on the
specifics of how one compiler or another enforces specific warnings.

It's true that the book uses -- as an example -- the code below, complete
with an unnecessary comparison to silence an assignment warning, and a
NULL to silence the null statement warning:

        while ((*pbTo++ = *pbFrom++) != '\0')
                NULL;

This is just one of several examples in the section, all of which show
how specific errors can easily be detected if programmers would enable
the optional warnings that they aren't using.  It's true that enabling
compiler warnings is a rather basic point, but I've worked with many
programmers who refuse to enable any warnings because "the compiler
shouldn't complain about perfectly correct C code."  I hope that the
arguments I present in the book give these programmers another opportunity
to review their positions.

I'm certainly not going to claim that NULL is the ideal way to silence
the null statement warning, but then few workarounds to compiler
warnings are ideal.  I would gladly trade the NULL method for Jim
Mann's "semicolon on its own line" method.  Whether NULL is better or
worse than Kevin D Quitt's "continue" method above, I'm not sure.  I
like NULL because it makes the "null-ness" explicit and hard to miss.
I like "continue" because it feels less like a trick.  Neither solution
is appealing, but until Jim Mann's suggestion is implemented in a compiler
that runs on my system, I'd rather use NULL (or continue, or any other
less-than-ideal solution) than go without the warning.  Besides, I can
always write code without using null statements if I wish to cast aside
the entire mess....

Anybody who has read WSC knows that I consistently trade a bit of
size, speed, or readabilty for improved error detection or code
robustness.  I do it for the same reason I gladly accept the extra
hassles, weight, and cost of seatbelts, airbags, and reinforced sidings
in my car.  In an ideal world I wouldn't need all that extra stuff, but
in the real world I believe the tradeoffs make sense.

        - Steve

----------


   or: microsoft!storm!stephenm                 Seattle WA, 98103



Fri, 19 Apr 1996 06:59:40 GMT  
 "Writing Solid Code" - compiler warnings

Quote:




> > >McGuire recommends this circumlocution:

> > >        while(ready_to_go() != TRUE)
> > >                NULL;    /* wait until ready */
> Why not just:

>        while(ready_to_go() != TRUE)
>              ;    /* wait until ready */

> The semicolon on its own line (especially with the comment) is not
> particularly confusing. The only time the null loop like this is
> confusing is when the semicolon is on the first line:

>        while(ready_to_go() != TRUE);  /* Ugh! */

I still prefer:

        while(ready_to_go() != TRUE)
                { }

The two-token empty compound is easier to see when scanning quickly than
the semicolon.

The semicolon-as-null was, IMO, a blemish on C.  In C++, of course, it's
required in the language for the  for( ; ; )  statement.
--
 (This man's opinions are his own.)
 From mole-end                          Mark Terribile




Fri, 19 Apr 1996 02:42:11 GMT  
 "Writing Solid Code" - compiler warnings
 > Anybody who has read WSC knows that I consistently trade a bit of
 > size, speed, or readabilty for improved error detection or code
 > robustness.  I do it for the same reason I gladly accept the extra
 > hassles, weight, and cost of seatbelts, airbags, and reinforced
sidings
 > in my car.  In an ideal world I wouldn't need all that extra stuff,
but
 > in the real world I believe the tradeoffs make sense.
 >
 > - Steve

No arguments here, Steve.  And, good job!  The book _is_ excellent (I
embarassingly admit I saw my own _former_ style in many chapters ;)

-Scotty

---------------------------------------------------------------------
 Scott Walter                     | "I'm sorra, sir ... I kinna fit
 Gateway Administrator            |  anah muhr on th' floppy!  Ye
 MinnTelligence On-Line (MOLe)    |  jes' kinna mess w' th' laws o'

---------------------------------------------------------------------
     "It's not a bug ... nor a feature ... it's an ENHANCEMENT!"

 * Origin: (1:3821/6)



Fri, 19 Apr 1996 23:37:02 GMT  
 "Writing Solid Code" - compiler warnings
|



|> > >McGuire recommends this circumlocution:

|> > >        while(ready_to_go() != TRUE)
|> > >                NULL;    /* wait until ready */
|
|> >       while(ready_to_go() != TRUE)
|> >             ;    /* wait until ready */

|>   while ( !ready_to_go() )
|>       continue;

|I've just finished reading this thread and, as the author of "Writing
|Solid Code," I'm pleased to see that people are talking about optional
|compiler warnings.

[ ... ]

|I'd rather "suggest adding new optional compiler warnings" than
|"complaining about inadequate ones," but it's clear that Jim got the
|points I was making in the section.  The emphasis is on using the
|warnings you have, and asking for additional warnings, not on the
|specifics of how one compiler or another enforces specific warnings.
|
|It's true that the book uses -- as an example -- the code below, complete
|with an unnecessary comparison to silence an assignment warning, and a
|NULL to silence the null statement warning:
|
|       while ((*pbTo++ = *pbFrom++) != '\0')
|               NULL;
|
|This is just one of several examples in the section, all of which show
|how specific errors can easily be detected if programmers would enable
|the optional warnings that they aren't using.  It's true that enabling
|compiler warnings is a rather basic point, but I've worked with many
|programmers who refuse to enable any warnings because "the compiler
|shouldn't complain about perfectly correct C code."  I hope that the
|arguments I present in the book give these programmers another opportunity
|to review their positions.

I'm flabbergasted. Call me an animal or anything, but when I see something
like the following:

        while (<condition>)
                <some_pacifier_for the compiler>;

I get itchy feelings, because the empty statement is a perfectly legal
statement, and because so, I just _want_ to see an empty statement, I
don't want any compiler whining about it, I don't _want_ to pacify
a compiler; the thing has to pacify me, by compiling my correct code
correctly; (I know I'm rude here.) When I see something like:

        while (<condition>)
                NULL;

deep in the back of my brains I see things like:

        while (<condition>)
                ((void*)0);

or other horrible constructs and it gives me the shivers. BTW, if I
would have been a compiler (;-) I would have whined about this construct,
because I just would've detected a referential transparent, i.e. no
side effects, expression.

And if someone reasons `but this is more readable for the human being'
I often recochet it as (and I know I'm awfully rude here):
`Yeah, fine, and I find curly brackets hard to find and hard to read
too, and do you want me to do things like `#define begin {' then, just
to `add' (and mind the quotes here) readability?'

And if somebody else tells me that this is bad programming style,
I usually throw a fit by saying: `yeah fine, but do you want a
compiler to whine to you, when you use an occasional `goto' statement,
like: `foo.c: warning 42: you {*filter*}, {*filter*}, still love BASIC heh?
Because most of the time this is considered bad programming style too.'

I think (and this is all IMVHO of course) that a much better approach
would be, to feed the C sources to some sort of `indent' or functionally
equivalent program and tell the compiler about its configuration setup.
Things like:

        while (<condition>);
                bar();

would result in a warning like:

foo.c: warning 42: bar() is supposedly in the loop but it aint,

while:

        while (<condition>)
                ;
        bar();

would make the compiler tell me what I want it to tell me: nothing.

Another (infamous) example is:

        if (<lvalue>= <rvalue>)
                <statement>;

I would love to have a compiler that I could tell: `hey silly thing,
when I mean ` == ', I mean ` == ', i.e. I add spaces around the
equality operator, and when I mean `= ', I mean `= ', i.e. I just
append a space after any assignment operator. Got it?' (I know I'm more
than rude here, but I'm just talking to my hypothetical compiler now ;-)
And I know that adding a couple of more brackets would solve this
exquisite little compiler inconvenience too, but I'm not programming
LISP you know. Why should I add more brackets when _I_ know what I'm
doing and the compiler does not? A lot of mathematicians know that
a/b*c usually means a/(b*c), why doesn't the compiler whine about that?

So, when I do things similar to the example above, I don't want any, in
my humble opinion, spurious warnings, but when I do things I didn't
tell the compiler about, being inconsistent to my own programming
style, the thing can warn its head off to me.

Maybe the following question explains why I feel flabbergasted: why do
people praise the terseness of the C language, while in the mean time
they come up with the most horrible constructs to get rid of this same
terseness?

I know I was very rude in my follow-up, but I don't want to be as rude
by advising those people to program in another language. And please
allow me to say this: I had no intention at all to be rude to any of
the authors of the articles previous to this one, but I still feel
flabbergasted about this topic. Call me an animal ...

kind regards,


---------------------------------------------------------------------------
Oh my gawd, I had your plastic, like and I didn't know? That's gross!
        -- Kelly Scott (always hunting for outfits)



Sat, 20 Apr 1996 09:07:29 GMT  
 "Writing Solid Code" - compiler warnings


Quote:
}I'm flabbergasted. Call me an animal or anything, but when I see something
}like the following:
}
}       while (<condition})
}               <some_pacifier_for the compiler};
}
}I get itchy feelings, because the empty statement is a perfectly legal
}statement, and because so, I just _want_ to see an empty statement, I
}don't want any compiler whining about it, I don't _want_ to pacify
}a compiler; the thing has to pacify me, by compiling my correct code
}correctly; (I know I'm rude here.) When I see something like:

        Feel free to ignore the warnings.  I don't do things to pacify stuff
like that, although I do find a comment like /* Nothing */ makes the job of
the reader easier, even if the compiler doesn't notice.

Quote:
}I think (and this is all IMVHO of course) that a much better approach
}would be, to feed the C sources to some sort of `indent' or functionally
}equivalent program and tell the compiler about its configuration setup.
}Things like:
}
}       while (<condition});
}               bar();
}
}would result in a warning like:
}
}foo.c: warning 42: bar() is supposedly in the loop but it aint,
}
}while:
}
}       while (<condition})
}               ;
}       bar();
}
}would make the compiler tell me what I want it to tell me: nothing.

        Unfortnatly, this is impossible to do.  The first step of the
compilers, lexical analysis, strips everything to a stream of tokens, while
removing the comments.  Thus, both examples reduce to the following (with
the notation where the first part is the token value, and the second is the
semantic value)

(while,) ('(',) ... (')',)(';',)(identifier,"bar")...

        Thus, to the compiler, both are the same thing, since by the time
the information reaches the parser, all the comments, whitespace, and
everything else is removed.

        If you wish to understand exactly how the blasted things called
compilers are constructued, the first couple of chapters of Aho, Sethi,
Ulmann _Compilers, second edition_ serves as a good overview.

Quote:
}Another (infamous) example is:
}
}       if (<lvalue}= <rvalue})
}               <statement};
}
}I would love to have a compiler that I could tell: `hey silly thing,
}when I mean ` == ', I mean ` == ', i.e. I add spaces around the
}equality operator, and when I mean `= ', I mean `= ', i.e. I just
}append a space after any assignment operator. Got it?' (I know I'm more
}than rude here, but I'm just talking to my hypothetical compiler now ;-)
}And I know that adding a couple of more brackets would solve this
}exquisite little compiler inconvenience too, but I'm not programming
}LISP you know. Why should I add more brackets when _I_ know what I'm
}doing and the compiler does not? A lot of mathematicians know that
}a/b*c usually means a/(b*c), why doesn't the compiler whine about that?

        Same problem as mentioned above.

        Although I think it is one of the sillier "features" in C which has
the equality test and assignment looking so much the same.

        As for the algebraic order, this is because * and / have the same
precidence, just as + and - do.  This is a common convention.  Personally, I
prefer prefix (Lisp) or postfix (HP Calculator/postscript) arithmetic
notation, because operation order doesn't matter.

Quote:
}Maybe the following question explains why I feel flabbergasted: why do
}people praise the terseness of the C language, while in the mean time
}they come up with the most horrible constructs to get rid of this same
}terseness?

        Damned if I know.

--

 It is a tale, told by an idiot, full of sound and fury, .signifying nothing.
 I'm not paranoid.  A paranoid only thinks that the world is out to get him.



Sat, 20 Apr 1996 09:56:35 GMT  
 "Writing Solid Code" - compiler warnings
It is not true that compilers necessarily ignore whitespace during
lexical analysis, even when the language is defined to be largely
insensitive to it.  Some Ada compilers, for example (GNAT for one),
can be persuaded (with proper choice of options) to warn when
code is not properly indented.  There is no inherent reason a C/C++
compiler couldn't do the same thing.

P. Hilfinger


(Nicholas C. Weaver), responding to Jos Horsmeier writes (Weaver: ">";
Horsmeier: "> }")  

Quote:
> }  while (<condition})
> }          ;
> }  bar();
> }
> }would make the compiler tell me what I want it to tell me: nothing.

>    Unfortnatly, this is impossible to do.  The first step of the
> compilers, lexical analysis, strips everything to a stream of tokens, while
> removing the comments. .... Thus, to the compiler, both are the same
> thing, since by the time the information reaches the parser, all
> the comments, whitespace, and everything else is removed.



Sat, 20 Apr 1996 10:51:02 GMT  
 "Writing Solid Code" - compiler warnings



|>>Why not just:
|>>
|>>       while(ready_to_go() != TRUE)
|>>             ;    /* wait until ready */
|>>
|>
|>Why not:
|>
|>   while ( !ready_to_go() )
|>       continue;
|>
|>The comparison to TRUE is odious, and the continue keyword makes it
|>obvious what's going on.
|>

   Given that this may well trigger a compiler's warnings, why not go
for the simplest way to express it:

    boolean_t is_ready_to_go;

    do
        {
        is_ready_to_go = ready_to_go();
        } while (!is_ready_to_go);

   This has all the semantics you're looking for, and while it introduces
a variable, any 1/2 decent compiler will generate the same code.

   This also follows the principal of not using side-effect generating
functions inside of conditions.  You may not follow this religion, but
there is a great deal of logic behind it.

------------------------------------------------------------------------
I'm saying this, not Digital.  Don't hold them responsibile for it!

Michael J. Grier                           Digital Equipment Corporation

Stow, Mass, USA                            Mailstop OGO1-1/E16



Sat, 20 Apr 1996 11:28:50 GMT  
 "Writing Solid Code" - compiler warnings

Quote:
> It's true that the book uses -- as an example -- the code below, complete
> with an unnecessary comparison to silence an assignment warning, and a
> NULL to silence the null statement warning:

>    while ((*pbTo++ = *pbFrom++) != '\0')
>            NULL;

If I had a compiler that was paternalistic enough to issue a warning for

        while ((*pbTo++ = *pbFrom++) != '\0')
                ;

(where I have put the ; its own line to show that I meant it), but which
did NOT also issue a warning for

        #include <stdio.h>
        ...

        while ((*pbTo++ = *pbFrom++) != '\0')
                NULL;

because the EXPRESSION STATEMENT "0;" or "(void*)0;" HAS NO EFFECT...
then I would start looking for another compiler.  An expression statement
with no effect is much more likely to be a bug than a null statement in a
place where null statements are commonly used.
--
Mark Brader                             "C takes the point of view
SoftQuad Inc., Toronto                   that the programmer is always right"

This article is in the public domain.



Sat, 20 Apr 1996 16:15:00 GMT  
 "Writing Solid Code" - compiler warnings
|There are other categories of warnings.  There are things that result
|in undefined behavior at run time, such as accessing a null pointer or
|accessing a pointer to an object which has ceased to exist.

But undefined behavior in turn is simply behavior that the committee
members have agreed to not agree upon.  If they agree upon the behavior
the behavior *would* be defined.



Sat, 20 Apr 1996 10:11:50 GMT  
 "Writing Solid Code" - compiler warnings
+  > However, note that in both cases the compiler may generate a
+  > warning such as
+  > "warning: statement with no effect".
+
+ A way around that would be to
+
+ #define     NOP
+
+ as opposed to
+
+ #define      NOP   0
+
+ That would still work, _and_ avoid the compiler warning.  However,
+ things would get crazy if you forget the ';' after.

I'm not sure, but I think the first definition would be completely
removed byu the preprocessor (on *nix systems at least) and the
statement would show up as empty (no effect). I haven't tested
this of course - I'm doing what everyone else does and assume that
they know their programming tools :-(
--


===========================================================================
"Bad planning on your part does not constitue an emergency on mine." -
                                        Please attribute this quote. Thanx.



Sat, 20 Apr 1996 21:16:38 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Compiler warnings when "Generating Code"

2. False C4702 warnings for "unreachable code"

3. Simple Code Produce "INTERNAL COMPILER ERROR"

4. Writing Solid Code & Code Complete

5. NetworkStream.Write writes "sometimes"

6. "Useless keyword..." warning

7. Q:warning "defined but not used"

8. "Noalias" warning and questions

9. lint warning "function actually returns double"

10. disable "first-chance exception.." warnings

11. "loss of precision" warnings

12. "warning C4786"...Problem -- Please help

 

 
Powered by phpBB® Forum Software