On Sunday 19 August 2007, Al Viro wrote:
> Use unsigned long or uintptr_t instead. There are several places misusing
> ptrdiff_t (one - in a very odd way; WTF did that cast to __user ptrdiff_t
> in ntfs expect to happen, anyway?) Fixed...
>
> Signed-off-by: Al Viro <[EMAIL PROTECTED]>
By the
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. N
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
On Sunday 19 August 2007, Satyam Sharma wrote:
> > > On a 32-bit arch "unsigned long" is 32-bit and pointers are 32-bit.
> > >
> > > On a 64-bit archi "unsigned long" is 64-bit and pointers are 64-bit.
> >
> > So with 32 bit userspace "unsigned long long" is the type to use
> > when talking to a
On Sun, 19 Aug 2007, David Brownell wrote:
> On Sunday 19 August 2007, Anton Altaparmakov wrote:
> > >
> > > ISTR we don't *have* a uintptr_t on all architectures, or that would
> > > be the appropriate thing to use in these 32/64 bit ABI scenarios.
> > >
> > >
> > >> Use unsigned long or uintpt
On Sunday 19 August 2007, Al Viro wrote:
> On Mon, Aug 20, 2007 at 01:27:13AM +0100, Anton Altaparmakov wrote:
>
> > And what the cast was doing I can't remember. I may well have just
> > copied it from the VFS or I was perhaps trying to silence a warning
> > and this happened to work...
>
>
On Mon, Aug 20, 2007 at 01:29:21AM +0100, Anton Altaparmakov wrote:
> Hi,
>
> On 20 Aug 2007, at 01:19, David Brownell wrote:
> >On Sunday 19 August 2007, Al Viro wrote:
> >>is wrong; for one thing, it's a bad C (it's what uintptr_t is for;
> >>in general
> >>we are not even promised that ptrdif
On Sunday 19 August 2007, Anton Altaparmakov wrote:
> >
> > ISTR we don't *have* a uintptr_t on all architectures, or that would
> > be the appropriate thing to use in these 32/64 bit ABI scenarios.
> >
> >
> >> Use unsigned long or uintptr_t instead.
> >
> > I suspect you mean "unsigned long long"
On Mon, Aug 20, 2007 at 01:27:13AM +0100, Anton Altaparmakov wrote:
> And what the cast was doing I can't remember. I may well have just
> copied it from the VFS or I was perhaps trying to silence a warning
> and this happened to work...
... due to sparse bug (it miscalculated address space
Hi,
On 20 Aug 2007, at 01:19, David Brownell wrote:
On Sunday 19 August 2007, Al Viro wrote:
is wrong; for one thing, it's a bad C (it's what uintptr_t is for;
in general
we are not even promised that ptrdiff_t is large enough to hold a
pointer,
ISTR we don't *have* a uintptr_t on all arch
On 19 Aug 2007, at 23:55, Al Viro wrote:
Use of ptrdiff_t in
- if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf,
u_tmp->len))
+ if (!access_ok(VERIFY_WRITE, (u8 __user *)
+ (ptrdiff_t) u_tmp-
>rx_buf,
+
On Sunday 19 August 2007, Al Viro wrote:
> is wrong; for one thing, it's a bad C (it's what uintptr_t is for; in general
> we are not even promised that ptrdiff_t is large enough to hold a pointer,
ISTR we don't *have* a uintptr_t on all architectures, or that would
be the appropriate thing to use
Use of ptrdiff_t in
- if (!access_ok(VERIFY_WRITE, u_tmp->rx_buf, u_tmp->len))
+ if (!access_ok(VERIFY_WRITE, (u8 __user *)
+ (ptrdiff_t) u_tmp->rx_buf,
+ u_tmp->
13 matches
Mail list logo
