While looking at DCCP sequence numbers, I stumbled over a problem with
the following definition of before in tcp.h:
static inline int before(__u32 seq1, __u32 seq2)
{
return (__s32)(seq1-seq2) < 0;
}
Problem: This definition suffers from an an ambiguity, i.e. always
From: Gerrit Renker <[EMAIL PROTECTED]>
Date: Thu, 14 Dec 2006 15:07:06 +
> While looking at DCCP sequence numbers, I stumbled over a problem with
> the following definition of before in tcp.h:
>
> static inline int before(__u32 seq1, __u32 seq2)
> {
> return (__s32)(seq1-seq2) < 0;
>
On Thu, Dec 14, 2006 at 03:07:06PM +, Gerrit Renker wrote:
> diff --git a/include/net/tcp.h b/include/net/tcp.h
> index c99774f..b7d8317 100644
> --- a/include/net/tcp.h
> +++ b/include/net/tcp.h
> @@ -242,14 +242,9 @@ extern int tcp_memory_pressure;
>
> static inline int before(__u32 seq1,
Hi David,
many thanks for taking the matter seriously and investigating
it further.
| I went over this patch and analysis a dozen times, because I
| couldn't believe something like this has been broken for
| so long :-)
It gave me some grief too, when I looked at DCCP sequence numbers %-)
RFC
David Miller <[EMAIL PROTECTED]> wrote:
> From: Gerrit Renker <[EMAIL PROTECTED]>
> Date: Thu, 14 Dec 2006 15:07:06 +
>
>> While looking at DCCP sequence numbers, I stumbled over a problem with
>> the following definition of before in tcp.h:
>>
>> static inline int before(__u32 seq1, __u32 se
Hi Herbert,
| >> While looking at DCCP sequence numbers, I stumbled over a problem with
| >> the following definition of before in tcp.h:
| >>
| >> static inline int before(__u32 seq1, __u32 seq2)
| >> {
| >> return (__s32)(seq1-seq2) < 0;
| >> }
| >>
| >> Problem: This definit
Gerrit Renker <[EMAIL PROTECTED]> wrote:
>
> | Prior to the patch, we have values x and y such that both
> | before(x, y) and before(y, x) are true. Now for those same
> | values both before(x, y) and before(y, x) are false.
> |
> | It's still as ambiguous as ever. Surely to resolve the
> |
| > With the implementation now, the output of before(x,y) is reliable: it
returns true
| > if (and only if) x is indeed `before' y.
|
| Sorry but I don't think you've answered my question.
|
| Let y = (x + 2^31) % 2^32, how is making
|
| before(x, y) == before(y, x) == 0
|
| an
On Thu, Jan 04, 2007 at 12:49:02PM +, Gerrit Renker wrote:
>
> The key point where the new definition differs from the old is that _the
> relation_
> before(x,y) is unambiguous: the case "before(x,y) && before(y,x)" will no
> longer occur.
This is highly dependent on how the before macro is
| > The key point where the new definition differs from the old is that _the
relation_
| > before(x,y) is unambiguous: the case "before(x,y) && before(y,x)" will no
longer occur.
|
| This is highly dependent on how the before macro is used in actual code.
| There is nothing to suggest that
On Fri, Jan 05, 2007 at 11:51:16AM +, Gerrit Renker wrote:
>
> | 2) Change before/after such that before(x, x+2^31) == !before(x+2^31, x).
> This is what the new definition does: in the old definition we always have
> that
> before(x, x+2^31) == before(x+2^31, x).
Sorry but the new def
Quoting Herbert Xu:
| On Fri, Jan 05, 2007 at 11:51:16AM +, Gerrit Renker wrote:
| >
| > | 2) Change before/after such that before(x, x+2^31) == !before(x+2^31,
x).
| > This is what the new definition does: in the old definition we always have
that
| > before(x, x+2^31) == before(
On Fri, Jan 05, 2007 at 12:49:13PM +, Gerrit Renker wrote:
>
> Since the old definition is not used in the way "before(x, y) && !before(y,
> x)", but rather in the
> fashion "before(x, y)" or "after(y, x)", the main advantage of the new
> definition is that it makes
> this type of use a safe
| > Since the old definition is not used in the way "before(x, y) &&
!before(y, x)", but rather in the
| > fashion "before(x, y)" or "after(y, x)", the main advantage of the new
definition is that it makes
| > this type of use a safe case.
|
| This is not true because
|
| if (befor
14 matches
Mail list logo
