From: Gerrit Renker <gerrit@erg.abdn.ac.uk>
To: dccp@vger.kernel.org
Subject: Re: [PATCH 1/5]: DCCP Fix use of invalid loss intervals
Date: Fri, 05 Jan 2007 13:22:23 +0000 [thread overview]
Message-ID: <200701051322.24178@strip-the-willow> (raw)
In-Reply-To: <200612201544.22122.ian.mcdonald@jandi.co.nz>
Hi Eddie,
thanks a lot for looking into this and I think we should take this on board and find
a different solution to achieve the same purpose, but without comparison against ~0 or ~0U.
| But the two bit patterns are the same, and the comparison will promote
| them both to unsigned.
Using both signed and unsigned can lead to very subtle bugs. As a recent example, we have had
real problems because time differences (signed type) was implicitly converted to unsigned.
The use of ~0U appears in the following functions:
* to mark a loss interval as empty in dccp_li_hist_interval_new
* to find non-empty loss intervals in dccp_li_hist_calc_i_mean
* to mark an empty first loss interval in ccid3_hc_rx_calc_first_li
(also connected with catching error conditions)
Sometimes the conversion happens through the return type, sometimes directly: it is not obvious
to see what happens here.
So I agree with Eddie and think we should find a different way of identifying empty loss intervals;
or check each part of the code to make sure it will be safe.
I can also see the point Ian makes, in that this will require some work - hence added as ToDo item on
http://linux-net.osdl.org/index.php/TODO#DCCP
Gerrit
| Try running the following program:
|
| int main (int c, char **v)
| {
| if (~0 != ~0U)
| printf("not equal as unknown");
| if ((int) ~0 != (int) ~0U)
| printf("not equal as ints");
| if ((unsigned) ~0 != (unsigned) ~0U)
| printf("not equal as unsigneds");
| if ((int) ~0 != (unsigned) ~0U)
| printf("not equal as int/unsigned");
| if ((unsigned) ~0 != (int) ~0U)
| printf("not equal as unsigned/int");
| }
|
| It prints nothing.
|
| If one of the two numbers is 64-bit, your analysis works. Maybe I'm
| missing something but I don't think so...
| Eddie
|
|
|
| Ian McDonald wrote:
| > On 1/5/07, Eddie Kohler <kohler@cs.ucla.edu> wrote:
| >> Ian (catching up slowly slowly), here is a nit as nitty as they come.
| >>
| >> This diff seems strange to me, since ~ actually does the same thing on
| >> integers and unsigned integers. (This code:
| >>
| >> printf("%u %u\n", ~0, ~0U);
| >>
| >> will print the same thing twice.)
| >>
| >> Perhaps dccplih_interval is a 64-bit number? In which case you want to
| >> say something like ~0ULL?
| >>
| >> Eddie
| >
| > Printing gives them the same result as you are using a %u mask. If you
| > do it with a %d mask you will get a different result.
| >
| > And that is the issue dccp_lih_interval is unsigned 32 bit and ~0 is a
| > signed number and is large negative and they therefore can't be equal.
| >
| > Ian
| -
| To unsubscribe from this list: send the line "unsubscribe dccp" in
| the body of a message to majordomo@vger.kernel.org
| More majordomo info at http://vger.kernel.org/majordomo-info.html
|
|
prev parent reply other threads:[~2007-01-05 13:22 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-12-20 2:44 [PATCH 1/5]: DCCP Fix use of invalid loss intervals Ian McDonald
2006-12-21 11:13 ` Gerrit Renker
2007-01-04 21:49 ` Eddie Kohler
2007-01-04 21:57 ` Ian McDonald
2007-01-04 22:17 ` Eddie Kohler
2007-01-04 22:45 ` Ian McDonald
2007-01-05 13:22 ` Gerrit Renker [this message]
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=200701051322.24178@strip-the-willow \
--to=gerrit@erg.abdn.ac.uk \
--cc=dccp@vger.kernel.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