"Writing bug free C code" thoughts

Discussion in 'C Programming' started by Francine.Neary@googlemail.com, May 16, 2007.

  1. Guest

    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.
    , May 16, 2007
    #1
    1. Advertising

  2. 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.
    Richard Heathfield, May 16, 2007
    #2
    1. Advertising

  3. Richard Heathfield said:

    > 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.
    Richard Heathfield, May 16, 2007
    #3
  4. Ben Pfaff Guest

    Richard Heathfield already made most of the comments that I
    would. But I have a little bit to add.

    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
    Ben Pfaff, May 16, 2007
    #4
  5. Old Wolf Guest

    On May 17, 10:13 am, 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.
    Old Wolf, May 17, 2007
    #5
  6. Guest

    On May 16, 11:36 pm, Richard Heathfield <> 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.
    , May 17, 2007
    #6
  7. Guest

    On May 16, 11:52 pm, Ben Pfaff <> 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
    , May 17, 2007
    #7
  8. On Thu, 17 May 2007 00:34:18 -0700, Francine.Neary wrote:

    > On May 16, 11:36 pm, Richard Heathfield <> 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...
    Duncan Muirhead, May 17, 2007
    #8
  9. dykeinthebox Guest

    <> wrote in message
    news:...
    > 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 );
    dykeinthebox, May 17, 2007
    #9
  10. Ian Collins Guest

    Duncan Muirhead wrote:
    > On Thu, 17 May 2007 00:34:18 -0700, Francine.Neary wrote:
    >
    >> On May 16, 11:36 pm, Richard Heathfield <> 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.
    Ian Collins, May 17, 2007
    #10
  11. said:

    > On May 16, 11:36 pm, Richard Heathfield <> wrote:
    >
    >> 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.


    Yes, I know that, and you know that. Nevertheless, one-decl-per-line
    /does/ sidestep this issue.

    --
    Richard Heathfield
    "Usenet is a strange place" - dmr 29/7/1999
    http://www.cpax.org.uk
    email: rjh at the above domain, - www.
    Richard Heathfield, May 17, 2007
    #11
  12. Tor Rustad Guest

    Richard Heathfield wrote:

    > said:
    >
    >> On May 16, 11:36 pm, Richard Heathfield <> wrote:
    >>
    >>> 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.

    >
    > Yes, I know that, and you know that. Nevertheless, one-decl-per-line
    > /does/ sidestep this issue.


    As long as the compiler will detect such a typo, there is no need for such a
    side-step IMO. There are other typo's, far more interesting, which the
    compiler will silently accept.

    Readability, is a sufficient reason for having only one decl-per-line.

    --
    Tor <torust [at] online [dot] no>
    Tor Rustad, May 17, 2007
    #12
  13. On 16 May 2007 15:13:52 -0700, Francine.Neary@...com 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.
    >
    >One example early on: he suggests using


    OMG, you found a few examples that you don't like and now you slate
    the whole book.

    >#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?


    namespace? In C?

    >implying he thinks it's a good thing to compile C with a C++ compiler!


    at lest for someone who speaks of 'the implementation's namespace'

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


    wow, an earthshaking advice, deserves the utmost counteraction

    >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:


    you have never seen such macros in a C program?

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


    This books is about application design using C. It not merely presents
    some more or less clever code snippets but techniques for larger
    applications, esp. wrt infomation hiding. I know only very few other
    sources that do the same. I don't like some of the macros, too. But
    that does no harm to the book (everyone has his/her own style). In
    sum, I recommend the book to the informed reader. Thanks to your
    inappropriate critique it now gets more attention.


    --
    Roland Pibinger
    "The best software is simple, elegant, and full of drama" - Grady Booch
    Roland Pibinger, May 17, 2007
    #13
  14. Chris Dollin Guest

    Roland Pibinger wrote:

    >>#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?

    >
    > namespace? In C?


    `namespace` is a perfectly good abstract concept, even if the language
    has no keyword for it.

    That's even if you ignore the struct/label/variable name space distinction
    that C makes.

    --
    "I'm still here and I'm holding the answers" - Karnataka, /Love and Affection/

    Hewlett-Packard Limited registered no:
    registered office: Cain Road, Bracknell, Berks RG12 1HN 690597 England
    Chris Dollin, May 17, 2007
    #14
  15. >>>>> "RP" == Roland Pibinger <> writes:

    RP> OMG, you found a few examples that you don't like and now you
    RP> slate the whole book.

    If the author can't get the simple things right, how can he be
    expected to get the difficult and complex things right? And writing
    bug free code is a lot more difficult and complex than it seems.

    >> #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?


    RP> namespace? In C?

    Yes, namespace. The term used by the Standard is actually 'name space.'

    >> 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:


    RP> you have never seen such macros in a C program?

    I have seen horrifically bad code. This does not make that code an
    exemplar of good style.

    Charlton


    --
    Charlton Wilbur
    Charlton Wilbur, May 17, 2007
    #15
  16. shadowman Guest

    Duncan Muirhead wrote:
    > On Thu, 17 May 2007 00:34:18 -0700, Francine.Neary wrote:
    >
    >> On May 16, 11:36 pm, Richard Heathfield <> 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...
    >
    >

    But IMO, a better alternative would be something more like:

    double speedInKnots;
    shadowman, May 17, 2007
    #16
  17. On Thu, 17 May 2007 10:46:28 -0400, shadowman wrote:

    > Duncan Muirhead wrote:
    >> On Thu, 17 May 2007 00:34:18 -0700, Francine.Neary wrote:
    >>
    >>>

    <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...
    >>
    >>

    > But IMO, a better alternative would be something more like:
    >
    > double speedInKnots;

    In simple cases, maybe, but I find complex formulae using
    long names (e.g. speedInKnots, towLoadInDecaNewtons) to
    be more difficult to read than with short names.
    Duncan Muirhead, May 17, 2007
    #17
  18. Al Balmer Guest

    On Thu, 17 May 2007 13:22:44 +0200, Tor Rustad
    <> wrote:

    >Richard Heathfield wrote:
    >
    >> said:
    >>
    >>> On May 16, 11:36 pm, Richard Heathfield <> wrote:
    >>>
    >>>> 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.

    >>
    >> Yes, I know that, and you know that. Nevertheless, one-decl-per-line
    >> /does/ sidestep this issue.

    >
    >As long as the compiler will detect such a typo, there is no need for such a
    >side-step IMO. There are other typo's, far more interesting, which the
    >compiler will silently accept.


    While the compiler might know that

    FILE out;

    is a typo, it has no way to tell whether

    int *ip1, ip2;

    is a typo.
    >
    >Readability, is a sufficient reason for having only one decl-per-line.


    Yes.

    --
    Al Balmer
    Sun City, AZ
    Al Balmer, May 17, 2007
    #18
  19. In article <>,
    Mark McIntyre <> wrote:

    >>As long as the compiler will detect such a typo, there is no need for such a
    >>side-step IMO.


    >However its not a typo.
    > double * x, y;


    And the compiler will correctly not detect it.

    If it *had* been a typo, the compiler would almost certainly have
    generated a diagnostic when the variable was used.

    No typo in declaration, no diagnostic:

    double * x, y;
    ...
    *x = y;

    Typo in declaration, diagnostic:

    double * x, y;
    ...
    x = y;

    -- Richard
    --
    "Consideration shall be given to the need for as many as 32 characters
    in some alphabets" - X3.4, 1963.
    Richard Tobin, May 17, 2007
    #19
  20. On Thu, 17 May 2007 13:22:44 +0200, in comp.lang.c , Tor Rustad
    <> wrote:

    >Richard Heathfield wrote:
    >
    >> said:
    >>
    >>> On May 16, 11:36 pm, Richard Heathfield <> wrote:
    >>>
    >>>> 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.

    >>
    >> Yes, I know that, and you know that. Nevertheless, one-decl-per-line
    >> /does/ sidestep this issue.

    >
    >As long as the compiler will detect such a typo, there is no need for such a
    >side-step IMO.


    However its not a typo.
    double * x, y;

    --
    Mark McIntyre

    "Debugging is twice as hard as writing the code in the first place.
    Therefore, if you write the code as cleverly as possible, you are,
    by definition, not smart enough to debug it."
    --Brian Kernighan
    Mark McIntyre, May 17, 2007
    #20
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Colin Basterfield

    XSLT + XML - design thoughts

    Colin Basterfield, Dec 16, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    392
    Colin Basterfield
    Dec 16, 2003
  2. =?Utf-8?B?RGFuIE5hc2g=?=

    dictionary concept - thoughts on how to do plz!

    =?Utf-8?B?RGFuIE5hc2g=?=, Nov 8, 2004, in forum: ASP .Net
    Replies:
    0
    Views:
    326
    =?Utf-8?B?RGFuIE5hc2g=?=
    Nov 8, 2004
  3. =?Utf-8?B?Q3JhaWc=?=

    any thoughts?

    =?Utf-8?B?Q3JhaWc=?=, Dec 20, 2005, in forum: ASP .Net
    Replies:
    0
    Views:
    342
    =?Utf-8?B?Q3JhaWc=?=
    Dec 20, 2005
  4. VB Programmer

    Microsoft Expression - Your Thoughts?

    VB Programmer, Mar 6, 2006, in forum: ASP .Net
    Replies:
    5
    Views:
    409
    =?Utf-8?B?RFdT?=
    Mar 6, 2006
  5. Roedy Green

    Thoughts on control breaks

    Roedy Green, Aug 11, 2003, in forum: Java
    Replies:
    4
    Views:
    1,546
    David Segall
    Aug 12, 2003
Loading...

Share This Page