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] [day] [month] [year] [list]
Date:	Wed, 18 May 2016 12:08:58 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Stefano Stabellini <sstabellini@...nel.org>
Cc:	Boris Ostrovsky <boris.ostrovsky@...cle.com>,
	David Vrabel <david.vrabel@...rix.com>,
	Juergen Gross <jgross@...e.com>,
	Stefano Stabellini <stefano.stabellini@...citrix.com>,
	Ian Campbell <ian.campbell@...rix.com>,
	Shannon Zhao <shannon.zhao@...aro.org>,
	Konrad Rzeszutek Wilk <konrad.wilk@...cle.com>,
	xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] Xen: don't warn about 2-byte wchar_t in efi

On Monday 16 May 2016 12:08:17 Stefano Stabellini wrote:
> On Wed, 11 May 2016, Arnd Bergmann wrote:
> > The XEN UEFI code has become available on the ARM architecture
> > recently, but now causes a link-time warning:
> > 
> > ld: warning: drivers/xen/efi.o uses 2-byte wchar_t yet the output is to use 4-byte wchar_t; use of wchar_t values across objects may fail
> > 
> > This seems harmless, because the efi code only uses 2-byte
> > characters when interacting with EFI, so we don't pass on those
> > strings to elsewhere in the system, and we just need to
> > silence the warning.
> > 
> > It is not clear to me whether we actually need to build the file
> > with the -fshort-wchar flag, but if we do, then we should also
> > pass --no-wchar-size-warning to the linker, to avoid the warning.
> > 
> > Signed-off-by: Arnd Bergmann <arnd@...db.de>
> > Fixes: 37060935dc04 ("ARM64: XEN: Add a function to initialize Xen specific UEFI runtime services")
> 
> Given that drivers/xen/efi.c doesn't actually use any wchar_t, it is not
> clear to me whether we need to pass -fshort-wchar either. However this
> patch is correct any, so I committed it to xentip.

Right, I was wondering about that too, but it has been this way since the
code was first merged, so I couldn't figure out if removing the flag
had any side-effects.

	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ