From: Jamie Lokier <jamie@shareable.org>
To: Lennart Sorensen <lsorense@csclub.uwaterloo.ca>
Cc: blauwirbel@gmail.com, qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [7234] Use a more natural order
Date: Thu, 23 Apr 2009 23:52:42 +0100 [thread overview]
Message-ID: <20090423225242.GQ13326@shareable.org> (raw)
In-Reply-To: <20090423192844.GJ3795@csclub.uwaterloo.ca>
Lennart Sorensen wrote:
> > if (x < 1)
> >
> > becomes
> >
> > if (1 >= x)
>
> No it doesn't. It becomes:
>
> if (1 > x)
Exactly.
You just proved that it's error prone to someone unfamiliar with it.
We all see the mistake now. But it was too easy to make in the first
place. Maybe you never do that, but you have to choose practices
which don't trigger mistakes from others too.
> > The compiler will warn about your example, but won't warn if I
> > transcribe things wrongly as
> >
> > if (1 < x)
>
> Nothing wrong with that. That's perfectly valid, if you want to check
> that x is greater than 1.
By transcribing he meant that one is prone to writing "if (1 < x)" _by
accident_ when one means to check that x is less than 1. Even worse,
the mistake is prone to being missed when reading it too.
> Putting constants first means that you can't accidentally use assignment
> when you meant equality. You can't fix all the stupidies possible in C,
> but you can at least try to avoid some of them when possible.
You can't do that anyway, without a warning or error, with any
compiler released in the last 10 years. Unless you're so stupid as to
turn that warning off. Now that _would_ be a stupidity possible in C :-)
-- Jame
next prev parent reply other threads:[~2009-04-23 22:52 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-04-23 18:29 [Qemu-devel] [7234] Use a more natural order Blue Swirl
2009-04-23 18:39 ` Andreas Färber
2009-04-23 18:43 ` Blue Swirl
2009-04-23 18:53 ` Lennart Sorensen
2009-04-23 19:01 ` Blue Swirl
2009-04-23 19:10 ` Lennart Sorensen
2009-04-23 19:15 ` Glauber Costa
2009-04-23 19:39 ` Blue Swirl
2009-04-23 19:59 ` Anthony Liguori
2009-04-23 20:20 ` Blue Swirl
2009-04-23 19:57 ` Anthony Liguori
2009-04-23 19:59 ` Lennart Sorensen
2009-04-23 20:03 ` Anthony Liguori
2009-04-23 20:54 ` Lennart Sorensen
2009-04-23 21:15 ` Anthony Liguori
2009-04-23 22:13 ` Jamie Lokier
2009-04-24 0:10 ` Anthony Liguori
2009-04-24 8:18 ` Gerd Hoffmann
2009-04-24 12:14 ` Anthony Liguori
2009-04-24 12:32 ` Stefan Weil
2009-04-23 19:31 ` Blue Swirl
2009-04-23 19:44 ` Lennart Sorensen
2009-04-23 22:46 ` Jamie Lokier
2009-04-24 18:07 ` Lennart Sorensen
2009-04-24 18:58 ` Nathan Froyd
2009-04-23 19:12 ` M. Warner Losh
2009-04-23 19:28 ` Lennart Sorensen
2009-04-23 19:41 ` M. Warner Losh
2009-04-23 19:55 ` Lennart Sorensen
2009-04-23 20:07 ` M. Warner Losh
2009-04-23 21:01 ` Lennart Sorensen
2009-04-23 23:02 ` Jamie Lokier
2009-04-23 22:52 ` Jamie Lokier [this message]
2009-04-23 19:37 ` [Qemu-devel] " Jan Kiszka
2009-04-23 19:46 ` Lennart Sorensen
2009-04-23 21:30 ` malc
2009-04-23 22:10 ` Jamie Lokier
2009-04-24 8:09 ` [Qemu-devel] " Gerd Hoffmann
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=20090423225242.GQ13326@shareable.org \
--to=jamie@shareable.org \
--cc=blauwirbel@gmail.com \
--cc=lsorense@csclub.uwaterloo.ca \
--cc=qemu-devel@nongnu.org \
/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).