Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > C Programming > "Writing bug free C code" thoughts

Reply
Thread Tools

"Writing bug free C code" thoughts

 
 
Francine.Neary@googlemail.com
Guest
Posts: n/a
 
      05-16-2007
I was browsing through this on the internet (http://www.duckware.com/
bugfreec/index.html). I have to say, it seems pretty awful to me.

One example early on: he suggests using
#define CompilerAssert(exp) extern char _CompilerAssert[(exp)?1:-1]
for compile-time debugging, but this seems to me to be a bug in itself
- doesn't declaring a variable starting with _ provoke undefined
behavior by incroaching on the implementation's namespace?

And then he goes on to recommend using hungarian notation (yeuch!)...
in chapter 8, he says
"If you do not have access to a C++ compiler, use the standard C /* */
comment form"
implying he thinks it's a good thing to compile C with a C++ compiler!
And some of the advice is just bizarre:
"auto variables should be defined one per line"
(why? do whatever makes the meaning clearest. And is it OK to define
multiple static variables per line?), and
"using the comma operator can lead to code that is hard to read and
maintain. It is best to avoid using it"
- I often find the comma operator helps make code briefer.

The main problem seems to be that he wants to teach other people
style, while he has absolutely no taste himself - the following macros
speak for themselves:

#define LOOP(nArg) { int _nMax=nArg; int loop; \
for (loop=0; loop<_nMax; ++loop)
#define LLOOP(lArg) { long _lMax=lArg; long lLoop; \
for (lLoop=0; lLoop<_lMax; ++lLoop)
#define ENDLOOP }

Bring me the sick bucket!

In summary, I'd advise anyone to avoid this like the plague.

 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      05-16-2007
http://www.velocityreviews.com/forums/(E-Mail Removed) said:

> I was browsing through this on the internet (http://www.duckware.com/
> bugfreec/index.html). I have to say, it seems pretty awful to me.
>
> One example early on: he suggests using
> #define CompilerAssert(exp) extern char _CompilerAssert[(exp)?1:-1]
> for compile-time debugging, but this seems to me to be a bug in itself
> - doesn't declaring a variable starting with _ provoke undefined
> behavior by incroaching on the implementation's namespace?


Yes, it does.

> And then he goes on to recommend using hungarian notation (yeuch!)...


Yes, it is!

> in chapter 8, he says
> "If you do not have access to a C++ compiler, use the standard C /* */
> comment form"
> implying he thinks it's a good thing to compile C with a C++ compiler!


Which isn't actually possible. A C++ compiler compiles C++ code, not C
code. Or, to put it another way, a compiler takes a source program as
input and translates it into another representation (either another
language or object code, which might anyway be regarded as another
language). The translation is done according to certain rules. If you
use a C++ compiler, it's done according to C++ rules. If you use a C
compiler, it's done according to C rules. And if you use a Pascal
compiler, it's done according to Pascal rules. So you pick the rules
you want, and use the appropriate compiler. If you write a program
according to the rules of C, and then compile it with a C++ compiler,
you're just asking for trouble, misunderstandings, and much
head-scratching.

> And some of the advice is just bizarre:
> "auto variables should be defined one per line"
> (why?


I can think of a few reasons. Firstly, it don't arf make it a lot
quicker to delete a redundant declaration! Secondly, it means you
can give a winged comment to every object, if that kind of thing takes
your fancy. Thirdly, it completely sidesteps the

FILE * in, out;

problem. Fourthly, some people think it looks neater and easier to read.

> do whatever makes the meaning clearest.


Right. In my view, that normally means one decl per line.

> And is it OK to define
> multiple static variables per line?),


What do *you* think? The same reasons apply as to auto objects. But
again, "do whatever makes the meaning clearest" is the right rule here.

> and
> "using the comma operator can lead to code that is hard to read and
> maintain. It is best to avoid using it"
> - I often find the comma operator helps make code briefer.


Brevity may be the soul of wit, but it is rarely the best guide to
writing good code. (Neither is verbosity, of course.) Do whatever makes
the meaning clearest.

> The main problem seems to be that he wants to teach other people
> style, while he has absolutely no taste himself - the following macros
> speak for themselves:
>
> #define LOOP(nArg) { int _nMax=nArg; int loop; \
> for (loop=0; loop<_nMax; ++loop)
> #define LLOOP(lArg) { long _lMax=lArg; long lLoop; \
> for (lLoop=0; lLoop<_lMax; ++lLoop)
> #define ENDLOOP }


Oof.

> Bring me the sick bucket!
>
> In summary, I'd advise anyone to avoid this like the plague.


I'll take a look at the site - not because I distrust your advice, but
out of sheer natural curiosity.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
 
 
 
Richard Heathfield
Guest
Posts: n/a
 
      05-16-2007
Richard Heathfield said:

> (E-Mail Removed) said:
>
>> I was browsing through this on the internet (http://www.duckware.com/
>> bugfreec/index.html). I have to say, it seems pretty awful to me.
>>

<snip>
>>
>> In summary, I'd advise anyone to avoid this like the plague.

>
> I'll take a look at the site - not because I distrust your advice, but
> out of sheer natural curiosity.


I have now done so, and I concur wholeheartedly with your sentiments.

--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999
http://www.cpax.org.uk
email: rjh at the above domain, - www.
 
Reply With Quote
 
Ben Pfaff
Guest
Posts: n/a
 
      05-16-2007
Richard Heathfield already made most of the comments that I
would. But I have a little bit to add.

(E-Mail Removed) writes:

> One example early on: he suggests using
> #define CompilerAssert(exp) extern char _CompilerAssert[(exp)?1:-1]
> for compile-time debugging, but this seems to me to be a bug in itself
> - doesn't declaring a variable starting with _ provoke undefined
> behavior by incroaching on the implementation's namespace?


Yes. Also, such a macro could only be used a single time in a
given scope. I've seen people sidestep that by token-pasting
__LINE__ into the name, though.

> The main problem seems to be that he wants to teach other people
> style, while he has absolutely no taste himself - the following macros
> speak for themselves:
>
> #define LOOP(nArg) { int _nMax=nArg; int loop; \
> for (loop=0; loop<_nMax; ++loop)
> #define LLOOP(lArg) { long _lMax=lArg; long lLoop; \
> for (lLoop=0; lLoop<_lMax; ++lLoop)
> #define ENDLOOP }


I've seen fairly good reason to embed partial loops into macros,
in particular for linked list traversal as seen in the Linux
kernel, but the good versions of these macros don't embed
unbalanced braces and they do something more useful than
counting.
--
Comp-sci PhD expected before end of 2007
Seeking industrial or academic position *outside California* in 2008
 
Reply With Quote
 
Old Wolf
Guest
Posts: n/a
 
      05-17-2007
On May 17, 10:13 am, (E-Mail Removed) wrote:
> I was browsing through this on the internet (http://www.duckware.com/
> bugfreec/index.html). I have to say, it seems pretty awful to me.


Same here, I'm just agreeing with you but nobody
else had replied yet so I thought I would.

> One example early on: he suggests using
> #define CompilerAssert(exp) extern char _CompilerAssert[(exp)?1:-1]
> for compile-time debugging, but this seems to me to be a bug in itself


Certainly is

> in chapter 8, he says
> "If you do not have access to a C++ compiler, use the standard C /* */
> comment form"
> implying he thinks it's a good thing to compile C with a C++ compiler!


Might have been written by Paul Hsieh then

> "auto variables should be defined one per line"
> "using the comma operator can lead to code that is hard to read and
> maintain. It is best to avoid using it"
>
> The main problem seems to be that he wants to teach other people
> style, while he has absolutely no taste himself


You could argue that good style makes it less likely you'll write a
bug.
For example, conceivably putting 1 variable per line makes it
more obvious if you forget to initialize a variable (hence the
distinction between auto and static).

This seems pretty specious to me apart from the basics (e.g.
indenting loops). A better way to not write bugs is to learn
the language better.

 
Reply With Quote
 
Francine.Neary@googlemail.com
Guest
Posts: n/a
 
      05-17-2007
On May 16, 11:36 pm, Richard Heathfield <(E-Mail Removed)> wrote:
> > And some of the advice is just bizarre:
> > "auto variables should be defined one per line"
> > (why?

>
> I can think of a few reasons. Firstly, it don't arf make it a lot
> quicker to delete a redundant declaration! Secondly, it means you
> can give a winged comment to every object, if that kind of thing takes
> your fancy.


I rarely find it useful to comment a specific variable. Either it's
used in one place for something simple, in which case a generic name
like i or p gets this across, or else it's a key variable used
repeatedly, in which case give it a descriptive name... but in that
case it's self-documenting.

> Thirdly, it completely sidesteps the
>
> FILE * in, out;
>
> problem.


This doesn't arise if you do
FILE *in, *out;
or even
FILE *in,*out;
instead.

> > And is it OK to define
> > multiple static variables per line?),

>
> What do *you* think? The same reasons apply as to auto objects. But
> again, "do whatever makes the meaning clearest" is the right rule here.


I agree - I was just making the point that for some reason the author
of this website singled out auto variables as being unsuitable for
multiple declarations on a line, as if static variables need different
treatment in this regard.

> > and
> > "using the comma operator can lead to code that is hard to read and
> > maintain. It is best to avoid using it"
> > - I often find the comma operator helps make code briefer.

>
> Brevity may be the soul of wit, but it is rarely the best guide to
> writing good code. (Neither is verbosity, of course.) Do whatever makes
> the meaning clearest.
>
> > The main problem seems to be that he wants to teach other people
> > style, while he has absolutely no taste himself - the following macros
> > speak for themselves:

>
> > #define LOOP(nArg) { int _nMax=nArg; int loop; \
> > for (loop=0; loop<_nMax; ++loop)
> > #define LLOOP(lArg) { long _lMax=lArg; long lLoop; \
> > for (lLoop=0; lLoop<_lMax; ++lLoop)
> > #define ENDLOOP }

>
> Oof.
>
> > Bring me the sick bucket!

>
> > In summary, I'd advise anyone to avoid this like the plague.

>
> I'll take a look at the site - not because I distrust your advice, but
> out of sheer natural curiosity.
>
> --
> Richard Heathfield
> "Usenet is a strange place" - dmr 29/7/1999http://www.cpax.org.uk
> email: rjh at the above domain, - www.



 
Reply With Quote
 
Francine.Neary@googlemail.com
Guest
Posts: n/a
 
      05-17-2007
On May 16, 11:52 pm, Ben Pfaff <(E-Mail Removed)> wrote:
> > One example early on: he suggests using
> > #define CompilerAssert(exp) extern char _CompilerAssert[(exp)?1:-1]
> > for compile-time debugging, but this seems to me to be a bug in itself
> > - doesn't declaring a variable starting with _ provoke undefined
> > behavior by incroaching on the implementation's namespace?

>
> Yes. Also, such a macro could only be used a single time in a
> given scope.


I don't think that's right - I think you can have multiple identical
declarations of the same thing (with extern, no storage is allocated,
it just tells the compiler that if it sees a symbol called
_CompilerAssert then it should believe that to be an array of char).

> I've seen people sidestep that by token-pasting
> __LINE__ into the name, though.
>
> > The main problem seems to be that he wants to teach other people
> > style, while he has absolutely no taste himself - the following macros
> > speak for themselves:

>
> > #define LOOP(nArg) { int _nMax=nArg; int loop; \
> > for (loop=0; loop<_nMax; ++loop)
> > #define LLOOP(lArg) { long _lMax=lArg; long lLoop; \
> > for (lLoop=0; lLoop<_lMax; ++lLoop)
> > #define ENDLOOP }

>
> I've seen fairly good reason to embed partial loops into macros,
> in particular for linked list traversal as seen in the Linux
> kernel, but the good versions of these macros don't embed
> unbalanced braces and they do something more useful than
> counting.
> --
> Comp-sci PhD expected before end of 2007
> Seeking industrial or academic position *outside California* in 2008



 
Reply With Quote
 
Duncan Muirhead
Guest
Posts: n/a
 
      05-17-2007
On Thu, 17 May 2007 00:34:18 -0700, Francine.Neary wrote:

> On May 16, 11:36 pm, Richard Heathfield <(E-Mail Removed)> wrote:
>> > And some of the advice is just bizarre:
>> > "auto variables should be defined one per line"
>> > (why?

>>
>> I can think of a few reasons. Firstly, it don't arf make it a lot
>> quicker to delete a redundant declaration! Secondly, it means you
>> can give a winged comment to every object, if that kind of thing takes
>> your fancy.

>
> I rarely find it useful to comment a specific variable. Either it's
> used in one place for something simple, in which case a generic name
> like i or p gets this across, or else it's a key variable used
> repeatedly, in which case give it a descriptive name... but in that
> case it's self-documenting.
>

<snip>
One case where I think individual variable (and field, argument etc)
comments are very useful is to describe the units of things that
represent physical quantities, especially if there are a variety of units
used. In "double speed;" the name is descriptive, but I think
"double speed; /* knots */" is far more informative. I seem to recall a
space vehicle crashed into Mars because of units mismatch...


 
Reply With Quote
 
dykeinthebox
Guest
Posts: n/a
 
      05-17-2007

<(E-Mail Removed)> wrote in message
news:(E-Mail Removed) ups.com...
> I was browsing through this on the internet (http://www.duckware.com/
> bugfreec/index.html). I have to say, it seems pretty awful to me.
>

[snip]
>
> In summary, I'd advise anyone to avoid this like the plague.
>


I agree. The following is an excerpt from these pages (2.1.9 Adjacent String
Literals):

===========
It is also a good way to place macro arguments in a string.

Placing macro arguments in a string literal
#define PRINTD(var) printf( "Variable " #var "=%d\n", var )

PRINTD() works by using the stringizing operator (#) on the macro argument,
namely #var. This places the macro argument in quotes and allows the
compiler to concatenate the adjacent string literals.
===========

Consider what happens when this macro is being used in the following way

PRINTD( 6%2 );


 
Reply With Quote
 
Ian Collins
Guest
Posts: n/a
 
      05-17-2007
Duncan Muirhead wrote:
> On Thu, 17 May 2007 00:34:18 -0700, Francine.Neary wrote:
>
>> On May 16, 11:36 pm, Richard Heathfield <(E-Mail Removed)> wrote:
>>>> And some of the advice is just bizarre:
>>>> "auto variables should be defined one per line"
>>>> (why?
>>> I can think of a few reasons. Firstly, it don't arf make it a lot
>>> quicker to delete a redundant declaration! Secondly, it means you
>>> can give a winged comment to every object, if that kind of thing takes
>>> your fancy.

>> I rarely find it useful to comment a specific variable. Either it's
>> used in one place for something simple, in which case a generic name
>> like i or p gets this across, or else it's a key variable used
>> repeatedly, in which case give it a descriptive name... but in that
>> case it's self-documenting.
>>

> <snip>
> One case where I think individual variable (and field, argument etc)
> comments are very useful is to describe the units of things that
> represent physical quantities, especially if there are a variety of units
> used. In "double speed;" the name is descriptive, but I think
> "double speed; /* knots */" is far more informative. I seem to recall a
> space vehicle crashed into Mars because of units mismatch...
>

Better for the name to define the units - a name that requires a
descriptive comment is a smell.

--
Ian Collins.
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
*bug* *bug* *bug* David Raleigh Arnold Firefox 12 04-02-2007 03:13 AM
Any Good (Possibly Free) Alternatives To Photoshop Elements ? Thoughts On Gimp ? Robert11 Digital Photography 21 03-07-2005 08:44 PM



Advertisments