_Writing Solid Code_ 
Author Message
 _Writing Solid Code_

I bought the book _Writing Solid Code_ by Steve Maguire a while
back and am currently reading it.  It covers techniques for
writing more bug-free C programs.  It is amazing how the author
manages to be full of great ideas in most of the prose and a
clueless git when it comes to writing standard-compliant C code.

In fact, some of his clever ideas have inspired me to improve my
own programming practices in a few minor ways.

Anybody else have comments on _WSC_?  (I see from Google that
accu.org has a few reviews of it up, one favorable and one
unfavorable, but the accu.org website seems to down right now and
the Google cache seems to have only the favorable review.)



Thu, 01 May 2003 13:18:11 GMT  
 _Writing Solid Code_

Quote:

> I bought the book _Writing Solid Code_ by Steve Maguire a while
> back and am currently reading it.  It covers techniques for
> writing more bug-free C programs.  It is amazing how the author
> manages to be full of great ideas in most of the prose and a
> clueless git when it comes to writing standard-compliant C code.

> In fact, some of his clever ideas have inspired me to improve my
> own programming practices in a few minor ways.

> Anybody else have comments on _WSC_?

He taught me how wonderful void ** was.

Linux taught me how unportable it is.

Generally, it's a good book, but by heaven you have to be on your guard.
And, when I read it, I wasn't. I was still in that hapless state of
believing that authors knew their subject, or else they wouldn't have
written a book about it...

<snip>

--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:

>Anybody else have comments on _WSC_?  (I see from Google that
>accu.org has a few reviews of it up, one favorable and one
>unfavorable, but the accu.org website seems to down right now and
>the Google cache seems to have only the favorable review.)

The subtitle is

"Microsoft's Techniques for Developing Bug Free C Programs"

Scary!

I have found that:
http://www.*-*-*.com/

I like the:

"Programmers who are {*filter*}ed to e{*filter*}ment will not like this book. "

--
-hs-    Tabs out, spaces in.
CLC-FAQ: http://www.*-*-*.com/ ~scs/C-faq/top.html
ISO-C Library: http://www.*-*-*.com/
FAQ de FCLC : http://www.*-*-*.com/ ~rumeau/fclc



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:

> I bought the book _Writing Solid Code_ by Steve Maguire a while
> back and am currently reading it.  It covers techniques for
> writing more bug-free C programs.  It is amazing how the author
> manages to be full of great ideas in most of the prose and a
> clueless git when it comes to writing standard-compliant C code.

You've got to remember that Microsoft want to write good _Windows_
code. They don't want programs to be portable to non-Windows platforms,
for obvious reasons.

I thought it was a good book, but mainly common sense, such as avoiding
over-optimisation and chomping garbage.

Sent via Deja.com http://www.deja.com/
Before you buy.



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:

> He taught me how wonderful void ** was.

> Linux taught me how unportable it is.

Really?  Under Linux all pointers have the same length and
format, so I'm surprised that Linux would teach you about
unportable void **.

Quote:
> Generally, it's a good book, but by heaven you have to be on your guard.
> And, when I read it, I wasn't. I was still in that hapless state of
> believing that authors knew their subject, or else they wouldn't have
> written a book about it...

Amazing how that belief goes away after you've written a little
yourself, doesn't it?  I've written far less than you and it's
already gone away for me.


Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:
> I bought the book _Writing Solid Code_ by Steve Maguire a while
> back and am currently reading it.  It covers techniques for
> writing more bug-free C programs.  It is amazing how the author
> manages to be full of great ideas in most of the prose and a
> clueless git when it comes to writing standard-compliant C code.

> In fact, some of his clever ideas have inspired me to improve my
> own programming practices in a few minor ways.

> Anybody else have comments on _WSC_?  (I see from Google that
> accu.org has a few reviews of it up, one favorable and one
> unfavorable, but the accu.org website seems to down right now and
> the Google cache seems to have only the favorable review.)

I bought this book a few years ago, and just glanced through it again. Given
that many of the code snippets are supposed to illustrate bad coding
practices, I would expect that much of the code would be bad. Could you
perhaps give some examples (quoting chapter and page) of code that is
presented by Mr. Maguire as OK, but is badly written?

Daniel Pfeffer



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

[..._WSC_...]

Quote:
> Could you perhaps give some examples (quoting chapter and page)
> of code that is presented by Mr. Maguire as OK, but is badly
> written?

1. Every time he assigns a void pointer to any other type of
   pointer, or vice versa, he uses an explicit cast.  This is
   hardly conducive to "Writing Solid Code".

2. On page 22, chapter 2, and later in the book too, he
   shamelessly declares a function strdup() without mentioning
   why you shouldn't do that.

3. He assumes that pointer arithmetic works outside of allocated
   arrays without ever mentioning that assumption.  Seen often,
   first on page 20.

4. He gratuitously ignores standard prototypes of standard
   functions and redeclares them according to his whim (type
   "byte" instead of "int", leaving off "const" specifiers, and
   so on).  He has some sort of "defense" to this in the first
   chapter, but not one that I understand.  (Leaving off const is
   particularly unforgivable: const is valuable when trying to
   write reliable code.)

5. He assumes that void ** is a generic pointer-to-pointer.  It's
   not.  Seen first on page 47, chapter 3.

6. In his pointer validator, he assumes that everything is
   allocated in dynamic memory.  Am I the only one who also uses
   pointers to automatic and static variables?  I doubt it.

7. On page 94, he states that realloc() will return the same
   pointer it is passed if the block is to be shrunk.  This is
   false: the C standard makes no such guarantee.

These are just those that I found by quickly paging through the
book up to this point, which is where I currently am in reading
it.  Basically, I believe that Steve Maguire is a good programmer
on the systems he's familiar with, but he doesn't understand the
C standard and so doesn't know how to write portable code.  Some
of the problems above would be okay (i.e., #3, which applies only
to his debug code, where it could be useful on systems where it
works and disabled somehow on systems where it doesn't) if he'd
just *mention* them instead of being blissfully unaware of them.
--
"I should killfile you where you stand, worthless human." --Kaz



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:



> > I bought the book _Writing Solid Code_ by Steve Maguire a while
> > back and am currently reading it.  It covers techniques for
> > writing more bug-free C programs.  It is amazing how the author
> > manages to be full of great ideas in most of the prose and a
> > clueless git when it comes to writing standard-compliant C code.

> > In fact, some of his clever ideas have inspired me to improve my
> > own programming practices in a few minor ways.

> > Anybody else have comments on _WSC_?  (I see from Google that
> > accu.org has a few reviews of it up, one favorable and one
> > unfavorable, but the accu.org website seems to down right now and
> > the Google cache seems to have only the favorable review.)

> I bought this book a few years ago, and just glanced through it again. Given
> that many of the code snippets are supposed to illustrate bad coding
> practices, I would expect that much of the code would be bad. Could you
> perhaps give some examples (quoting chapter and page) of code that is
> presented by Mr. Maguire as OK, but is badly written?

> Daniel Pfeffer

At random:

Page 57

flag fResizeMemory(void **ppv, size_t sizeNew)

void * is a generic pointer, but void ** is not.

This same function also unnnecessarily casts realloc.

--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:


> > He taught me how wonderful void ** was.

> > Linux taught me how unportable it is.

> Really?  Under Linux all pointers have the same length and
> format, so I'm surprised that Linux would teach you about
> unportable void **.

Well, I had an entire memory tracking library based on it, thanks to Mr
Maguire, and it completely failed to work under Linux, for this very
reason. <shrug>

Quote:

> > Generally, it's a good book, but by heaven you have to be on your guard.
> > And, when I read it, I wasn't. I was still in that hapless state of
> > believing that authors knew their subject, or else they wouldn't have
> > written a book about it...

> Amazing how that belief goes away after you've written a little
> yourself, doesn't it?  I've written far less than you and it's
> already gone away for me.

Actually, it went away long before; I think the first time was when I
re-examined Schildt's "C-TCR" after about a month of reading clc. ;-)

I really do wish there were a way to dynamically debug paper remotely. I
suspect I'm not the only one.

--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:
>I bought the book _Writing Solid Code_ by Steve Maguire a while
>back and am currently reading it.  It covers techniques for
>writing more bug-free C programs.  It is amazing how the author
>manages to be full of great ideas in most of the prose and a
>clueless git when it comes to writing standard-compliant C code.

Yes, that was my impression of the book. We had a discussion about it here some
years ago. Maybe around early 1998 or so?

I really don't like his suggestions that the pointer-returning allocator
interface where a null pointer is used to indicate failure is somehow a bad
thing, and his void ** based replacement is a joke.

For my tastes, too many of the advices in the book remind me of medieval
superstitious rituals intended to ward off bad luck and disease.
Some of it is good for rookies. E.g. if you never heard of assert(),
then you may learn something.



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:


> > I bought the book _Writing Solid Code_ by Steve Maguire a while
> > back and am currently reading it.  It covers techniques for
> > writing more bug-free C programs.  It is amazing how the author
> > manages to be full of great ideas in most of the prose and a
> > clueless git when it comes to writing standard-compliant C code.

> > In fact, some of his clever ideas have inspired me to improve my
> > own programming practices in a few minor ways.

> > Anybody else have comments on _WSC_?

> He taught me how wonderful void ** was.

> Linux taught me how unportable it is.

Why?

- Show quoted text -

Quote:

> Generally, it's a good book, but by heaven you have to be on your guard.
> And, when I read it, I wasn't. I was still in that hapless state of
> believing that authors knew their subject, or else they wouldn't have
> written a book about it...

> <snip>

> --
> Richard Heathfield
> "Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
> C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
> K&R answers, C books, etc: http://users.powernet.co.uk/eton



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:




<snip>

Quote:
> > > Anybody else have comments on _WSC_?

> > He taught me how wonderful void ** was.

> > Linux taught me how unportable it is.

> Why?

Given some object (i.e. not function) type T, it is guaranteed by the
Standard that you can convert a T * to a void * and back to a T *
without loss of information.

What is /not/ guaranteed, however, is to be able to convert a T** to a
void ** and back to a T** without loss of information.

Steve Maguire's book had persuaded me of the opposite, thus enabling me
to write a wrapper for realloc which avoided all the clumsiness of a
spare pointer. It worked fine - in Windows. It didn't, however, work on
the Linux box to which I first tried to port the code.

--
Richard Heathfield
"Usenet is a strange place." - Dennis M Ritchie, 29 July 1999.
C FAQ: http://www.eskimo.com/~scs/C-faq/top.html
K&R answers, C books, etc: http://users.powernet.co.uk/eton



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_


Quote:
>Given some object (i.e. not function) type T, it is guaranteed by the
>Standard that you can convert a T * to a void * and back to a T *
>without loss of information.

>What is /not/ guaranteed, however, is to be able to convert a T** to a
>void ** and back to a T** without loss of information.

(All of which is correct.)

Quote:
>Steve Maguire's book had persuaded me of the opposite, thus enabling me
>to write a wrapper for realloc which avoided all the clumsiness of a
>spare pointer. It worked fine - in Windows. It didn't, however, work on
>the Linux box to which I first tried to port the code.

(This surprises me, given what I know about the architectures on
which Linux runs.)

I *will* note that it is in Microsoft's interest to "lock you in" to
Windows.  If your code works on Windows, but not on system X, you
are faced with a choice: spend the time to make the code work on
system X, or run only on Windows.  If the code happens to be the
next Killer App[%], it is against Microsoft's interest to have that
code work on system X as well as Windows, especially if system X is
faster or better in some other way.  As long as everyone has to have
Windows to run your application, Microsoft still wins.
-----
[%] "Killer App" is a reference to the spreadsheet software that many
    claim caused Microsoft's {*filter*} in the first place.  The idea
    is that "everyone bought a PC so as to run Lotus", giving Microsoft
    its initial leg-up, from which they have skillfully maintained
    and enhanced their monopoly.
-----

Is there a {*filter*} here?  I doubt it: "cultural effects" and
self-interest effects lead to this sort of monopoly-maintaining
behavior without the need for conspiracies.
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc




Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_

Quote:

> Given some object (i.e. not function) type T, it is guaranteed by the
> Standard that you can convert a T * to a void * and back to a T *
> without loss of information.

> What is /not/ guaranteed, however, is to be able to convert a T** to a
> void ** and back to a T** without loss of information.

This is all true.  Here's some more elaboration of the situation
in Steve Maguire's example of a "safe" realloc function, which he
declares so:

        flag fReallocMemory(void **ppv, size_t sizeNew)

("flag" is a typedef used for Boolean values.)  The idea is that
fReallocMemory will change the size of the block pointed to by
*ppv to sizeNew, possibly moving it somewhere else and updating
*ppv in the process.

Unfortunately, this will only necessarily work if the pointer to
the block to be changed, *ppv, is of type pointer-to-void[1].  If
it is pointer-to-int or pointer-to-long or some other pointer
type, it may fail, because there is no guarantee that all pointer
types have the same format.

Now, you *can* use void * as a generic pointer, so at first you
might think that you could declare the function as follows
instead:

        flag fReallocMemory(void *ppv, size_t sizeNew)

But inside fReallocMemory(), when you go to actually access *ppv,
you will find that you have to cast it to a real
pointer-to-pointer type first.  Unless you know what that type
should be, you're still stuck.  In short, there is no such thing
as a pointer-to-generic-pointer type in C.

[1] Or pointer-to-character-type, because such pointers have the
same format.  Or maybe even pointer-to-aggregate, where the
aggregate's first member is of character type.  Anyway, a small
subset of possible pointer types.
--
Just another C hacker.



Thu, 01 May 2003 03:00:00 GMT  
 _Writing Solid Code_


Quote:
>... Here's some more elaboration of the situation
>in Steve Maguire's example of a "safe" realloc function, which he
>declares so:

>    flag fReallocMemory(void **ppv, size_t sizeNew)

>("flag" is a typedef used for Boolean values.)  The idea is that
>fReallocMemory will change the size of the block pointed to by
>*ppv to sizeNew, possibly moving it somewhere else and updating
>*ppv in the process.

>Unfortunately, this will only necessarily work if the pointer to
>the block to be changed, *ppv, is of type pointer-to-void ...

Right -- the way one could use the above is:

        struct zonk *p;
        void *vp;
        ...
        p = malloc(N * sizeof *p);
        if (p == NULL)
                ... handle failure ...
        ...

So at this point we have a valid, malloc'ed pointer converted to
"struct zonk *" and stored in "p".  Now, I forget (it has been
quite a while since I flipped through the book in question) whether
fReallocMemory returns "true" for success and "false" for failure,
or vice versa, but supposing it returns "true" for success, the
next part should read:

        vp = p;
        if (fReallocMemory(&vp, new_N * sizeof *p)) {
                p = vp;
                ... use the extra memory ...
        } else {
                ... handle failure ...
        }

Unfortunately, Maguire does not do this, probably because if he did,
he would realize that (correct) direct use of realloc():

        if ((vp = realloc(p, new_N * sizeof *p)) != NULL) {
                p = vp;
                ... use the extra memory ...
        } else {
                ... handle failure ...
        }

is actually shorter!  (Or, if you prefer separate assignment and
test, it is the same length, but remains simpler.  Note also that
with direct use of realloc, "vp" can be given type "struct zonk *";
with fReallocMemory, vp must have type "void *".)

(I also do not recall whether fReallocMemory free()s the original
pointer on failure.  In the above, I have assumed it does not.)
--
In-Real-Life: Chris Torek, Berkeley Software Design Inc




Thu, 01 May 2003 03:00:00 GMT  
 
 [ 25 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Writing Solid Code & Code Complete

2. "Writing Solid Code" - compiler warnings

3. flame: _Writing Solid Code_

4. flame: _Writing Solid Code_

5. Short review of _Writing Solid Code_

6. Querry: A good solid text on writing Macro Assemblers

7. Solid C Code

8. code/classes for Solid Modelling

9. 12 days of Christmas C code, top secret style of code writing

10. Writing optimized C code

11. standard for writing the code

12. writing portable code for structures

 

 
Powered by phpBB® Forum Software