Re: What is the right way to print a UINTN?

["Kinney, Michael D" <michael.d.kinney@intel.com>]

Andrew,

Yes.  Using fixed with base types instead of natural width base types is clearer
and very portable.

We do use UINTN in UEFI/PI spec APIs on purpose when the range of the argument 
does need vary for different CPU widths.  Using UINTN in function args 
and local variables also generates smaller code in most cases because UINTN
usually matches the stack and register width.  So there are good reasons to 
use UINTN/INTN.

I did find the commit where the use of 'int' was added to pull arguments from the 
var arg list.  Dated 6/3/2006.

  SHA-1: 1d580c14473896b5b593a7f60a21f532008265d0

  * 1) Add support for %p to print pointers
  2) Fix %d,%x,%X to pull values off the vararg stack using (int) and (unsigned int) 
     types to resolve compatibility issues with X64

Best regards,

Mike

> -----Original Message-----
> From: afish@apple.com [mailto:afish@apple.com]
> Sent: Tuesday, September 27, 2016 10:47 AM
> To: Kinney, Michael D <michael.d.kinney@intel.com>
> Cc: Eugene Cohen <eugene@hp.com>; Alexei Fedorov <Alexei.Fedorov@arm.com>; edk2-
> devel@lists.01.org <edk2-devel@ml01.01.org>; Laszlo Ersek <lersek@redhat.com>
> Subject: Re: [edk2] What is the right way to print a UINTN?
> 
> 
> > On Sep 27, 2016, at 10:27 AM, Kinney, Michael D <michael.d.kinney@intel.com> wrote:
> >
> > Andrew,
> >
> > Here is the comment in current code that explains some of the why.
> >
> >      case 'd':
> >        if ((Flags & LONG_TYPE) == 0) {
> >          //
> >          // 'd', 'u', 'x', and 'X' that are not preceded by 'l' or 'L' are assumed to
> be type "int".
> >          // This assumption is made so the format string definition is compatible
> with the ANSI C
> >          // Specification for formatted strings.  It is recommended that the Base
> Types be used
> >          // everywhere, but in this one case, compliance with ANSI C is more
> important, and
> >          // provides an implementation that is compatible with that largest possible
> set of CPU
> >          // architectures.  This is why the type "int" is used in this one case.
> >          //
> >
> > If code uses type UINTN or INTN, then the max value that can be used
> > for portable sources is max value for the CPU arch with the smallest
> > UINTN width.  For the CPU archs in UEFI/PI specs today, the smallest UINTN
> > width is 32-bits.
> >
> > Portable sources that use type UINTN must never use values larger than
> > 32-bits.  Same for type INTN.  Only use values in signed 32-bit range.
> >
> > It is possible for 64-bit specific sources to use type UINTN with values
> > larger than 32-bits, but those sources would not be portable and would
> > need to be changed to UINT64 to be portable.  Is this the case that are
> > really discussing here?
> >
> 
> If you have a UINTN that can only represent 32-bits is that not a UINT32 :).
> 
> Thanks,
> 
> Andrew Fish
> 
> > Thanks,
> >
> > Mike
> >
> >
> >> -----Original Message-----
> >> From: afish@apple.com [mailto:afish@apple.com]
> >> Sent: Tuesday, September 27, 2016 9:47 AM
> >> To: Eugene Cohen <eugene@hp.com>
> >> Cc: Laszlo Ersek <lersek@redhat.com>; Kinney, Michael D
> <michael.d.kinney@intel.com>;
> >> Alexei Fedorov <Alexei.Fedorov@arm.com>; edk2-devel@lists.01.org <edk2-
> >> devel@ml01.01.org>
> >> Subject: Re: [edk2] What is the right way to print a UINTN?
> >>
> >>
> >>> On Sep 27, 2016, at 9:03 AM, Cohen, Eugene <eugene@hp.com> wrote:
> >>>
> >>>> Printing UINTN with %x *or* with %d are equally bugs.
> >>>>
> >>>> For X64 / AARCH64 / IA64 builds, they are actual bugs (that happen to
> >>>> work most of the time).
> >>>
> >>> Feel free to file a Bugzilla on the extensive usage of this in edk2 [ducking and
> >> running].  :)
> >>>
> >>>>> I'm envisioning having to create a slide in the future for UEFI
> >>>>> training about the proper use of UINTNs and describing "If you think
> >>>>> it may exceed 2^32-1 then upcast to UINT64, otherwise don't worry
> >>>>> about it" and it makes me squirm.
> >>>>
> >>>> It makes me squirm too. I think the slide should recommend the
> >>>> casting
> >>>> that I proposed. ;) "There is no conversion specifier dedicated to
> >>>> UINTN; the portable way to print it is to cast it to UINT64, then print
> >>>> it with %Lx."
> >>>
> >>> This is reasonable although I expect to get asked why a lot of the other code
> doesn't
> >> adhere to this recommendation.
> >>>
> >>
> >> I think this is a historical artifact. The older version of %x in the EDK (and early
> >> edk2) implied UINTN. We hit an issue with C integer math resulting in an int and
> that
> >> seemed to bork some toolchains. That is when things changed from UINTN to int. I
> guess
> >> the cleanup was practical vs. pedantic.
> >>
> >> Thanks,
> >>
> >> Andrew Fish
> >>
> >>> Thanks,
> >>>
> >>> Eugene
> >>> _______________________________________________
> >>> edk2-devel mailing list
> >>> edk2-devel@lists.01.org
> >>> https://lists.01.org/mailman/listinfo/edk2-devel
> >
> > _______________________________________________
> > edk2-devel mailing list
> > edk2-devel@lists.01.org
> > https://lists.01.org/mailman/listinfo/edk2-devel