[newlib] print formats for FAST and LEAST types

[Corinna Vinschen]

On Aug 27 10:57, Andre Vieira wrote:
> On 24/07/15 11:49, Corinna Vinschen wrote:
> >On Jul 24 11:21, Andre Vieira wrote:
> >>On 23/07/15 20:43, Corinna Vinschen wrote:
> >>>Hi Andre,
> >>>
> >>>On Jul 23 11:28, Andre Vieira wrote:
> >>>>The PRI and SCN macro's were producing formats that did not match their
> >>>>target types set by GCC. This patch uses the types defined for
> >>>>__INTxx_TYPE__, __INT_FASTxx_TYPE__ and __INT_LEASTxx_TYPE__ to define their
> >>>>corresponding macros.
> >>>>
> >>>>newlib/ChangeLog:
> >>>>2015-07-23  Andre Vieira  <...>
> >>>>
> >>>>   * libc/include/sys/_intsup.h: Defined new __INTxx, __FASTxx and
> >>>>   _LEASTxx macro's to hold information regarding the respective types
> >>>>   print and scan formats.
> >>>>   * libc/include/inttypes.h: Defined LEAST and FAST specific PRI and SCN
> >>>>   macro's as these are not always the same as the INT variants. Used
> >>>>   the new
> >>>>   __INTxx, __FASTxx and __LEASTxx macro's in their corresponding PRI
> >>>>   and SCN macros.
> >>>
> >>>I gave your patch a quick glance and it looks basically ok to me.
> >>>I'll review it more thorougly tomorrow (I hope), but I have a question:
> >>>
> >>>How did you test your patch?
> >>>
> >>>
> >>>Thanks,
> >>>Corinna
> >>>
> >>Hi Corinna,
> >>
> >>That is a very good question. To be honest with you I ran gcc and newlib
> >>regression tests and did a manual test on one machine. As I was about to
> >>send you the manual patch I noticed I forgot to change the SCN16(x) define.
> >>So I'll respin this patch for you and I'll also give testing a bit more
> >>thinking.
> >>
> >>There is no straightforward way of testing this I think. Though I will try
> >>to create a sensible sscanf/sprintf test and get back to you. Suggestions
> >>are welcome.
> >
> >Some simple testcase which allows easy manual inspection of the results
> >would do, I guess.  You know, output in rows, kind of like
> >
> >   typename      basetype    printf macro    scanf macro
> >   int32_t       int         "d"             "d"
> >   int16fast_t   long        "ld"            "ld"
> >
> >If you have a chance to test on, say, 2 platforms, I'd add inspection on
> >32 and 64 bit Cygwin.  That should allow to be reasonable sure that the
> >patch doesn't break any platform.
> >
> >
> >Thanks,
> >Corinna
> >
> 
> Sorry for the delay.
> 
> As Kevin reported on Launchpad
> (https://answers.launchpad.net/gcc-arm-embedded/+question/269083), the PRI
> and SCN macro's were producing formats that did not match their target types
> set by GCC. This patch uses the types defined for __INTxx_TYPE__,
> __INT_FASTxx_TYPE__ and __INT_LEASTxx_TYPE__ to define their corresponding
> macros. Attached you can find the file used for manual testing and the
> results of running this test for compiled versions for arm-none-eabi(32 bit)
> and aarch64-none-elf(64 bit), named arm.run and aarch64.run respectively.

Thanks a lot!  I tested the patch successfully on both supported Cygwin
platforms, i686 and x86_64.  Patch applied.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20150901/83ac6c66/attachment.sig>