On ARM32 only, it appears that whenever Visual Studio inlines the FloatToString()
call (which it does for Release builds), the resulting executable produces an
"Undefined OpCode Exception" on Print() invocation, regardless of whether there
is an actual float to string conversion occurring there.
To work around this, add an explicit clause to prevent inlining, and do so on all
platform just in case.
Signed-off-by: Pete Batard <pete@akeo.ie>
This is ascii order but with upper and lower case letters mixed, so
things like 'X' and 'x' that use fallthrough still stay together.
Signed-off-by: Peter Jones <pjones@redhat.com>
When compiling for x64, Visual Studio 2019's Code Analysis produces the following warnings:
C:\Projects\gnu-efi\lib\print.c(1380): warning C26451: Arithmetic overflow: Using operator '+' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '+' to avoid overflow (io.2).
C:\Projects\gnu-efi\lib\smbios.c(47): warning C26451: Arithmetic overflow: Using operator '+' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '+' to avoid overflow (io.2).
C:\Projects\gnu-efi\lib\str.c(289): warning C26451: Arithmetic overflow: Using operator '-' on a 4 byte value and then casting the result to a 8 byte value. Cast the value to the wider type before calling operator '-' to avoid overflow (io.2).
Fix these by adding an explicit cast to UINTN.
Per https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/PrintLib.h
AsciiPrint() is the official name of APrint() so declare it as such and define
an APrint alias for compatibility.
Also add an AsciiVSPrint() to print a formatted ASCII string to a buffer using
a va_list. AsciiPrint() too is defined in EDK2's PrintLib.h, though our implementation
just invokes the Unicode version and then converts the buffer to ASCII.
Calling the various Print functions picked up some warnings in my
project (using GCC 4.8 and 4.9 at the moment):
warning: passing argument 1 of Print discards const qualifier from
pointer target type [enabled by default]
Signed-off-by: Nigel Croxon <noxorc@mac.com>
Signed-off-by: Justinian <justinian@users.sf.net>
compiled with MSVC: lib\print.c(1345): warning C4244:
'initializing': conversion from 'double' to 'float',
possible loss of data
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
This patch corrects the printing of leading fractional
part 0s in Print("%f").
Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
point and as far as I can tell it agrees with the UEFI spec.
The attached patch removes -mno-mmx and -mno-sse for x86_64 and adds
a new Print target, "%f", to print float and double types.
It seems to compile for ia32, although I'm not sure why - shouldn't
it be throwing errors because the new function FloatToStr() in print.c
accepts a float, yet I left -no-sse for ARCH=ia32? A better solution
might be to add -msoft-float for targets where the floating point
calling convention doesn't match the UEFI spec. As I'm not familiar
with UEFI on ia32, I didn't make any changes to it.
Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
Windows libraries, the MSVC compiler will throw the error:
gnu-efi.lib(print.obj) : error LNK2019: unresolved external symbol __allmul referenced in function _ValueToHex
Adding an explicit cast on the array index, to ensure that is not larger
than 32 bits, appears to fix the problem.
NB: This patch also removes trailing whitespaces, but the only real change
is on line 1253.
Signed-off-by: Pete Batard <pbatard@users.sf.net>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
This patch changes the behavior of Print() slightly. %d is now signed decimal,
and %u (new) is unsigned decimal. Previously, although ValueToString supports
signed decimal printing, %d always read args as UINTxx.
Old behavior:
Print(L"%d\n", -4) -> "4294967292"
New behavior:
Print(L"%d\n, -4) -> "-4"
Print(L"%u\n", -4) -> "4294967292"
If you want to keep complete backwards compatibility you could leave %d alone
and make something else (probably shouldn't be %u to avoid confusion) be
signed decimal. But this way it agrees with the usual use of %d and %u.
Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>
maxlen is the maximum string length not the buffer size.
Signed-off-by: Jeremy Compostella <jeremy.compostella@intel.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hp.com>
Date: Wed, 10 Dec 2014 21:08:34 +0000
Subject: [PATCH] fixes for MSVC compilation
These fixes are needed to address the following error and warnings when compiling the library part
using Visual Studio 2013 Community Edition (as in https://github.com/pbatard/uefi-simple):
* "lib\x86_64\math.c(49): error C4235: nonstandard extension used : '_asm' keyword not supported
on this architecture"
* "lib\print.c(98): error C2059: syntax error : '('" due to placement of EFIAPI macro
* "lib\cmdline.c(94): warning C4090: 'function' : different 'const' qualifiers"
* "lib\smbios.c(25): warning C4068: unknown pragma"
* Also update macro definitions in "inc\<arch>\efibind.h" for MSVC
Signed-off-by: Pete Batard <pete@akeo.ie>
Signed-off-by: Nigel Croxon <nigel.croxon@hp.com>
Callum Farmer