History log of /DragonStub/lib/print.c (Results 1 – 17 of 17)
Revision Date Author Comments
# 4b5db35e 18-Nov-2019 Peter Jones <pjones@redhat.com>

Implement Print(L"%p", ptr);

Signed-off-by: Peter Jones <pjones@redhat.com>


# f7bf4302 18-Nov-2019 Peter Jones <pjones@redhat.com>

Semi-asciibetize _Print()'s formatters.

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 Jo

Semi-asciibetize _Print()'s formatters.

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>

show more ...


# 4ef18335 15-Jul-2021 Pete Batard <pete@akeo.ie>

Fix VS2019 Code Analysis warnings

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 overf

Fix VS2019 Code Analysis warnings

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.

show more ...


# b39be0d5 01-Mar-2021 Pete Batard <pete@akeo.ie>

Define UnicodeSPrint/UnicodeVSPrint as our main SPrint/VSPrint calls

Per https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/PrintLib.h
those are the names used by EDK2, so make the

Define UnicodeSPrint/UnicodeVSPrint as our main SPrint/VSPrint calls

Per https://github.com/tianocore/edk2/blob/master/MdePkg/Include/Library/PrintLib.h
those are the names used by EDK2, so make these our official names as well.

For compatibility with older gnu-efi versions, also keep SPrint and VSPrint defined.

show more ...


# 0247cb7c 16-Feb-2021 Pete Batard <pete@akeo.ie>

Add AsciiPrint and AsciiVSPrint

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

Add AsciiPrint and AsciiVSPrint

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.

show more ...


# 28793041 13-Mar-2018 Peter Jones <pjones@redhat.com>

Add %D to print device paths

Add %D to print device paths.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>


# 8d8a3b5d 31-May-2017 Nigel Croxon <ncroxon@redhat.com>

Add the fallthrough attribute to notify gcc7 that it's on purpose.

Signed-off-by: Gary Lin <glin@suse.com>
Signed-off-by: Nigel Croxon <ncroxon@redhat.com>


# fa1b9779 08-Jan-2017 Nigel Croxon <noxorc@mac.com>

GCC 4.8 (and others) const warnings

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 con

GCC 4.8 (and others) const warnings

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>

show more ...


# 93ef2655 08-Jul-2016 Nigel Croxon <nigel.croxon@hpe.com>

The latest gnu-efi produces the following warning when
compiled with MSVC: lib\print.c(1345): warning C4244:
'initializing': conversion from 'double' to 'float',
possible loss of data

Signed-off-by:

The latest gnu-efi produces the following warning when
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>

show more ...


# 44d9ae19 17-Jun-2016 Nigel Croxon <nigel.croxon@hpe.com>

I did not submit the right file on my last submission.
This patch corrects the printing of leading fractional
part 0s in Print("%f").

Signed-off-by: Nathan Blythe <nblythe@lgsinnovations.com>
Signed

I did not submit the right file on my last submission.
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>

show more ...


# b2c4db06 17-Jun-2016 Nigel Croxon <nigel.croxon@hpe.com>

I did a quick review of the MS x86_64 calling convention for floating
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

I did a quick review of the MS x86_64 calling convention for floating
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>

show more ...


# 38c57d52 04-Apr-2016 Nigel Croxon <nigel.croxon@hpe.com>

When compiling in x86_32|Debug mode and choosing not to link with standard
Windows libraries, the MSVC compiler will throw the error:
gnu-efi.lib(print.obj) : error LNK2019: unresolved external symbo

When compiling in x86_32|Debug mode and choosing not to link with standard
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>

show more ...


# 1acb1d9d 25-Mar-2016 Nigel Croxon <nigel.croxon@hpe.com>

%d now represents signed decimal, %u represents unsigned decimal.

This patch changes the behavior of Print() slightly. %d is now signed decimal,
and %u (new) is unsigned decimal. Previously, althoug

%d now represents signed decimal, %u represents unsigned decimal.

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>

show more ...


# ab6c6ef7 03-Mar-2016 Nigel Croxon <nigel.croxon@hpe.com>

This -Wall -Wextra thing actually caught a real bug.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hpe.com>


# dada63fd 23-Mar-2015 Nigel Croxon <nigel.croxon@hp.com>

[PATCH] _SPrint: fix NULL termination

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.cr

[PATCH] _SPrint: fix NULL termination

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>

show more ...


# 09027207 05-Jan-2015 Nigel Croxon <nigel.croxon@hp.com>

From: Pete Batard <pete@akeo.ie>
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 t

From: Pete Batard <pete@akeo.ie>
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>

show more ...


# 530d68ba 25-Nov-2014 Nigel Croxon <nigel.croxon@hp.com>

The gnu-efi-3.0 toplevel subdirectory is really annoying. Kill it.

Signed-off-by: Peter Jones <pjones@redhat.com>
Signed-off-by: Nigel Croxon <nigel.croxon@hp.com>