9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
From: Russ Cox <rsc@swtch.com>
To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net>
Subject: Re: [9fans] Unexpected 8c warning message
Date: Mon, 10 Aug 2009 10:19:07 -0700	[thread overview]
Message-ID: <dd6fe68a0908101019x5449c72axc794bdd56ab87977@mail.gmail.com> (raw)
In-Reply-To: <eb42bda6b242c29b771a38acec3032ca@quanstro.net>

This problem is uncomputable, so trying to
handle every case that comes up is problematic.
There has to be a line somewhere.  Saying that
the compiler could figure out does not imply
that it must.

I think it's perfectly reasonable that a compiler,
when presented with a program like

    int x;

    for(___; ___; ___) {
        x = ___;
        ___;
    }
    if(!x)
        ___;

should complain about a possible used-but-not-set
of x.  As a person reading that code, I can't look at
the overall structure of the code and see that x is
obviously initialized at the if statement, unless I analyze
the various abstracted-away ___ pieces.  And if one of
those changes, then there is now a real error.

SET is hard to use correctly and not portable.
You are better off with a simple assignment,
simpler than the one you used in your example:
just zero the variable before the loop.

    int x;

    x = 0;
    for(___; ___; ___) {
        x = ___;
        ___;
    }
    if(!x)
        ___;

Now at least the people reading the code can see
that x is initialized, for sure.  It's very hard for me to
see how "x = 0" is a medicine worse than the disease.
I do agree that the "SD = SDList[0];" you had is not
a good solution, because it makes it look like that
value is important, but "SD = nil;" avoids that issue.

Alternately, since the if(!x) is really the continuation
of the last iteration of the loop, you could move it
inside the loop:

    int x;

    for(___; ___; ___) {
        x = ___;
        ___;
        if(last iteration && !x)
            ___;
    }

which makes it clear to both people and compilers
that x is set before it is used.

It is not the compiler's job to enable you to be as
clever as possible.  If this really matters to you and
you don't want the compiler warnings, you can
always turn them off.

Russ


  reply	other threads:[~2009-08-10 17:19 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-08-09 19:33 Adriano Verardo
2009-08-09 19:46 ` Russ Cox
2009-08-09 21:20   ` Adriano Verardo
2009-08-09 21:48     ` erik quanstrom
2009-08-10 16:24       ` Adriano Verardo
2009-08-10 16:43         ` erik quanstrom
2009-08-10 17:19           ` Russ Cox [this message]
2009-08-10 23:30             ` Adriano Verardo
2009-08-11  0:19               ` Charles Forsyth
2009-08-10 20:33           ` Adriano Verardo
2009-08-10 21:01 ` James Tomaschke
2009-08-11 10:30   ` Ethan Grammatikidis
2009-08-11 22:16     ` James Tomaschke

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=dd6fe68a0908101019x5449c72axc794bdd56ab87977@mail.gmail.com \
    --to=rsc@swtch.com \
    --cc=9fans@9fans.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).