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

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

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?

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