linux-kernel - Re: sound/pci/asihpi/hpioctl.c:125:6: warning: cast to pointer from integer of different size

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130208185057.GK9135@intel.com>
Date:	Fri, 8 Feb 2013 20:50:57 +0200
From:	Ville Syrjälä <ville.syrjala@...ux.intel.com>
To:	"H. Peter Anvin" <hpa@...ux.intel.com>
Cc:	Russell King - ARM Linux <linux@....linux.org.uk>,
	kbuild test robot <fengguang.wu@...el.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: sound/pci/asihpi/hpioctl.c:125:6: warning: cast to pointer from
 integer of different size

On Fri, Feb 08, 2013 at 09:06:52AM -0800, H. Peter Anvin wrote:
> On 02/08/2013 07:28 AM, Russell King - ARM Linux wrote:
> > 
> > Whether that's safe for x86 or not, I don't know, but my suspicions are
> > that it's unsafe on x86 as it's possible to refer to the various bytes/
> > half-words of eax separately.
> > 
> > So, I came to the conclusion that if x86 remains a problem, there's
> > little point supporting it on ARM.
> > 
> 
> It is possible to access bytes separately, but gcc generally doesn't.
> However, whether or not that can be relied upon safely is a tricky question.
> 
> It *is* also worth nothing that the x86 ABI does allow two words to be
> returned in registers from a normal C function, simply by returning a
> structure.  That doesn't solve the problem at hand, though, which is how
> to make a type-neutral macro which can handle doublewords...

I just tried to compare a couple of options:

1)
	unsigned long __val_gu;
	unsigned long long __val_gu8;

2)
	register typeof(x) __val_gu asm("eax");

	I was still using a test app based on my orignal patch which
	used eax and edx for the value.

3)
	typeof(x) __val_gu;

While options 2 and 3 get rid of the warnings, they unfortunately
produce different results as well.

I've attached my test app in case you want to see it.

One other note is that if I include the memtest() call in the test,
option 1 and 2 produce the same results, but w/o the memtest() the
results differ. I didn't look into it any further.

-- 
Ville Syrjälä
Intel OTC

View attachment "get_user.S" of type "text/x-asm" (701 bytes)

View attachment "Makefile" of type "text/plain" (204 bytes)

View attachment "uaccess.c" of type "text/x-c" (3711 bytes)