This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: wchar_t printf() format warning
- From: Joel Sherrill <joel dot sherrill at oarcorp dot com>
- To: Jonathan Roelofs <jonathan at codesourcery dot com>, "newlib at sourceware dot org" <newlib at sourceware dot org>
- Date: Thu, 19 Mar 2015 10:50:59 -0500
- Subject: Re: wchar_t printf() format warning
- Authentication-results: sourceware.org; auth=none
- References: <5509EE56 dot 8090307 at oarcorp dot com> <5509F232 dot 9070501 at codesourcery dot com> <550ADFF7 dot 9060904 at oarcorp dot com> <550AEF55 dot 4010004 at codesourcery dot com>
On 3/19/2015 10:46 AM, Jonathan Roelofs wrote:
>
> On 3/19/15 8:40 AM, Joel Sherrill wrote:
>>
>> On 3/18/2015 4:46 PM, Jonathan Roelofs wrote:
>>> On 3/18/15 3:29 PM, Joel Sherrill wrote:
>>>> Hi
>>>>
>>>> I am returning to this issue. This appears to be similar to the
>>>> intptr_t issue but with wchar_t. We get a printf() warning on
>>>> targets where wchar_t is defined is defined as "long int" and
>>>> not on targets where it is "int". This appears to be because
>>>> of a conflict in the definition of __WINT_TYPE__ and
>>>> __WCHAR_TYPE__ by gcc. I am open to suggestions on how
>>>> to resolve this.
>>>>
>>>> $ sparc-rtems4.11-gcc -dM -E - </dev/null | grep WCHAR_TYPE
>>>> #define __WCHAR_TYPE__ long int
>>>> $ i386-rtems4.11-gcc -dM -E - </dev/null | grep WCHAR_TYPE
>>>> #define __WCHAR_TYPE__ int
>>>> $ sparc-rtems4.11-gcc -dM -E - </dev/null | grep WINT_TYPE
>>>> #define __WINT_TYPE__ unsigned int
>>>> $ i386-rtems4.11-gcc -dM -E - </dev/null | grep WINT_TYPE
>>>> #define __WINT_TYPE__ unsigned int
>>>>
>>>>
>>>> sparc generates this warning but i386 does not:
>>>>
>>>> $ sparc-rtems4.11-gcc -Wall -c wc.c
>>>> wc.c: In function 'f':
>>>> wc.c:10:3: warning: format '%lc' expects argument of type 'wint_t', but
>>>> argument 4 has type 'wchar_t' [-Wformat=]
>>>> (void)printf("%*s%lc\n", pad, "", wc);
>>>> ^
>>>> wc.c:10:3: warning: format '%lc' expects argument of type 'wint_t', but
>>>> argument 4 has type 'wchar_t' [-Wformat=]
>>>>
>>>>
>>>> This is the test case:
>>>>
>>>> =================
>>>> #include <stdio.h>
>>>> #include <wchar.h>
>>>>
>>>> void f(void)
>>>> {
>>>>
>>>> int pad = 10;
>>>> wchar_t wc = 'a';
>>>>
>>>> (void)printf("%*s%lc\n", pad, "", wc);
>>> Â7.19.6.1 7:
>>>
>>> "l (ell)
>>> Specifies that a following d, i, o, u, x, or X conversion specifier
>>> applies to a long int or unsigned long int argument; that a following n
>>> conversion specifier applies to a pointer to a long int argument; that a
>>> following c conversion specifier applies to a wint_t argument; that a
>>> following s conversion specifier applies to a pointer to a wchar_t
>>> argument; or has no effect on a following a, A, e, E, f, F, g, or G
>>> conversion specifier."
>>>
>>> You need a cast for the last argument: (wint_t)wc
>>>
>> I left out the disclaimer that this a cut down of code ported to RTEMS from
>> FreeBSD.
>>
>> I am adding a cast and moving along. I do wonder if gcc should be more
>> consistent in how these types are defined but that would be harder to
> That's a platform decision, not a gcc decision. AFAIK, there is no
> language requirement that wint_t and wchar_t be the same type.
Sometimes I question how conscious those decisions were. Cut and paste
often propagates things with no thought and after years, it is hard to know
if there was a good reason for something or not.
>> justify, fix, and test than it is probably worth.
> Yes, definitely. It would be an ABI-breaking change for that platform.
Actually at least 1/2 of the 18 RTEMS targets based on the warning.
Best to add a cast and move along. I don't want to turn this warning into
some Don Quixote type quest. :)
>> Thanks.
>>> Cheers,
>>>
>>> Jon
>>>
>>>> }
>>>> =================
>>>>
--
Joel Sherrill, Ph.D. Director of Research & Development
joel.sherrill@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985