[newlib] print formats for FAST and LEAST types

[Andre Vieira]

On 17/07/15 18:46, Corinna Vinschen wrote:
> On Jul 15 15:02, Andre Vieira wrote:
>> On 14/07/15 15:57, Corinna Vinschen wrote:
>>>    [...]
>>>    #undef signed
>>>    #undef int
>>>    #undef long
>>>    #define signed +0
>>>    #define int +0
>>>    #define long +1
>>>    [...]
>>>    #if __INT32_TYPE__ == 1
>>>    #define _INT32_EQ_LONG
>>>    #elif __INT32_TYPE__ == 0
>>>    /* Nothing to define because int32_t is safe to print as an int. */
>>>    #else
>>>    #error "Unable to determine type definition of int32_t"
>>>    #endif
>>>    #undef long
>>>    #undef int
>>>    #undef signed
>>>    [...]
>>>
>>> __INT32_TYPE__ is defined by GCC as well.  If __INT_FAST32_TYPE__ is
>>> int, then why is __INT32_TYPE__ long?  And if that's the right thing to
>>> do, we need a patch to sys/_intsup.h to apply the same check to
>>> __INT_FAST32_TYPE__ and use that to define __PRI32fast and __SCN32fast
>>> macros.
>>>
>>>
>>> Corinna
>>>
>> Hi Corinna,
>>
>> Thank you for your quick replies!
>>
>> I don’t know whether the current behavior of assigning INT32_TYPE and
>> INT_FAST32_TYPE the types "long" and "int" respectively  given INT_TYPE_SIZE
>> = LONG_TYPE_SIZE = 32, is the right thing to do. Might be worth bringing it
>> up with someone, maybe the gcc mailing list?
>
> Yes.  Using different base types for types of the same size sounds
> fishy to me.
>
>> However, as is, _intsup.h and inttypes.h don’t reflect these discrepancies
>> and we could use the same approach as was used with _INT32_EQ_LONG to mend
>> that.
>
> Not sure on that specific account, but in theory, yes, as I outlined
> above.
>
>> Also Kevin brought to our attention that inttypes.h is riddled with the
>> assumption that intNN_t == int_fastNN_t == int_leastNN_t.
>
> Yes, that could be rectified by defining matching __PRI<X>fast,
> __SCN<X>least macros.
>>
>> For instance, on my system SCNdFAST8 will yield 'hhd' whereas INT_FAST8_TYPE
>> is 'int'. All other PRIdFAST8, PRId8 and PRIdLEAST8 will be 'd'. Not
>> entirely sure this is expected behaviour or not. What is your opinion on
>> this?
>> Might be also good to point out that printf only seems to warn against using
>> formats that may represent larger integers than the ones passed as
>> arguments.
>
> Please feel free to send patches.
>
>
> Thanks,
> Corinna
>
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  <andre.simoesdiasvieira@arm.com>

   * 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-PRI-and-SCN-formats-fix.patch
Type: text/x-patch
Size: 14674 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/newlib/attachments/20150723/fd75af01/attachment.bin>