[lkml]   [2007]   [Aug]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH] ptrdiff_t is not uintptr_t, damnit
    On Sunday 19 August 2007, Al Viro wrote:
    > On Sun, Aug 19, 2007 at 08:26:24PM -0700, David Brownell wrote:
    > > ISTR the warning was the other way around: about "cast from integer
    > > to pointer of a different size". The __u64 came from userspace and
    > > the kernel pointer was only 32 bits. Not really truncation, but GCC
    > > could not know that directly ... ergo the extra non-pointer cast.
    > And? Cast to integer type with the size equal to that of pointer.
    > unsigned long is just that on all supported targets.

    Some tool kept warning about that. Presumably then-current sparse.
    I've certainly heard the conventional "unsigned long fits pointers"
    wisdom, but tools disagreed. (Does ANSI C guarantee that? I'd think
    not, or uintptr_t would not be needed.)

    And ptrdiff_t was the closest relevant data type that passed both
    gcc and sparse, since uintptr_t didn't previously exist everywhere.

    > More interesting question is whether you want an error returned when
    > pointers are 32bit and value doesn't fit into that...

    Either access_ok() or copy_from_user() reports an error if the
    pointer part of that u64 (N LSBs) is bad.

    As a general policy, I think the other part is undefined and
    irrelevant to the kernel ... it's a kind of explicit padding,
    and padding isn't valdated. (At most it's zeroed to prevent
    a covert channel, but that's not relevent here.)

    - Dave

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-08-20 06:21    [W:0.023 / U:4.164 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site