The output of the two types (debugging gcc at the comparison of types):
For ARM (doesn't throw the warning):
(gdb) p debug_tree(wanted_type)
<integer_type 0x7ffff664a690 unsigned int public unsigned SI
(gdb) p debug_tree(cur_type)
<integer_type 0x7ffff664a690 unsigned int public unsigned SI
For sparc: (throws the warning)
p debug_tree(wanted_type)
<integer_type 0x7ffff760f690 unsigned int public unsigned SI
(gdb) p debug_tree(cur_type)
<integer_type 0x7ffff760f738 long int public SI
NOTE: wanted_type is the passed to the string (%lc) cur_type is the
actually passed (wc)
On Thu, Sep 18, 2014 at 11:56 AM, Marcos Díaz
<marcos.d...@tallertechnologies.com> wrote:
> Hi, I've been looking this, and I saw the following:
> This warning arise because the %lc format option is for wint_t type,
> and we are passing a wchar_t type.
> At the architectures that doesn't give the warning, those two types
> are the same (wint_t and wchar_t), and those who give the warning have
> them of different types. At the end I'll show how I could see that.
> According to the c standard there isn't an option to print one wchar_t
> character, but you can print a string of wchar_t (passing the pointer,
> and with WEOF as end of string) so, one solution could be print this
> variable as follows:
> wchar_t wc[2]= {L'a'}; (or wchar_t wc[2]= {L'a', WEOF};
> printf("%ls",wc);
>
> The other could be that gcc has wrongly defined the types for wchar_t
> and wint_t for those architectures. This should be analysed
>
> On Wed, Sep 17, 2014 at 4:55 PM, Marcos Díaz
> <marcos.d...@tallertechnologies.com> wrote:
>> Thanks, I will look into it.
>>
>> On Wed, Sep 17, 2014 at 4:02 PM, Joel Sherrill
>> <joel.sherr...@oarcorp.com> wrote:
>>>
>>> On 9/17/2014 1:38 PM, Marcos Díaz wrote:
>>>> Where can we see in which BSP's and with which tools this warning was
>>>> generated? Thanks
>>> OK. It is with the tools generated by the current RSB and
>>> the RTEMS head.
>>>
>>> I have attached a cut down and script that I used to test it
>>> on all RTEMS gcc's I have installed. It gives a summary and
>>> is easy to hack on. Plus this doesn't need RTEMS at all to
>>> investigate the warning. :)
>>>
>>> === arm-rtems4.11-gcc - no warning
>>> === avr-rtems4.11 - warning
>>> === bfin-rtems4.11-gcc - no warning
>>> === h8300-rtems4.11 - warning
>>> === i386-rtems4.11-gcc - no warning
>>> === lm32-rtems4.11-gcc - no warning
>>> === m68k-rtems4.11-gcc - warning
>>> === m32c-rtems4.11-gcc - warning
>>> === m32r-rtems4.11-gcc - no warning
>>> === mips-rtems4.11-gcc - no warning
>>> === moxie-rtems4.11-gcc - no warning
>>> === nios2-rtems4.11-gcc - no warning
>>> === or1k-rtems4.11-gcc - no warning
>>> === powerpc-rtems4.11-gcc - warning
>>> === sh-rtems4.11-gcc - warning
>>> === sparc64-rtems4.11-gcc - no warning
>>> === sparc-rtems4.11-gcc - warning
>>> === v850-rtems4.11-gcc - warning
>>>
>>> This is the list of BSPs that have this warning. Interesting that at least
>>> arm, mips, m32r, moxie, nios2, and sparc64 don't generate this.
>>>
>>> m32c-m32csim m68k-av5282 m68k-COBRA5475 m68k-csb360 m68k-gen68302
>>> m68k-gen68340 m68k-gen68360_040 m68k-gen68360 m68k-idp
>>> m68k-m5484FireEngine m68k-mcf52235 m68k-mcf5225x m68k-mcf5235
>>> m68k-mcf5329 m68k-mrm332 m68k-mvme136 m68k-mvme147 m68k-mvme147s
>>> m68k-mvme167 m68k-ods68302 m68k-pgh360 m68k-sim68000 m68k-simcpu32
>>> m68k-uC5282 powerpc-ep1a powerpc-haleakala powerpc-mbx821_001
>>> powerpc-mbx821_002b powerpc-mbx821_002 powerpc-mbx860_001b
>>> powerpc-mbx860_002 powerpc-mbx860_005b powerpc-mbx860_1b
>>> powerpc-mpc8260ads powerpc-pghplus powerpc-psim powerpc-qemuppc
>>> powerpc-ss555 powerpc-tqm8xx_stk8xx powerpc-virtex4 powerpc-virtex5
>>> powerpc-virtex sh-gensh1 sh-gensh2 sh-gensh4 sh-simsh1 sh-simsh2e
>>> sh-simsh2 sh-simsh4 sparc-erc32 sparc-leon2 sparc-leon3 sparc-ngmp
>>> sparc-sis v850-v850e1sim v850-v850e2sim v850-v850e2v3sim
>>> v850-v850esim v850-v850essim v850-v850sim
>>>
>>>
>>>> On Wed, Sep 17, 2014 at 12:40 PM, Joel Sherrill
>>>> <joel.sherr...@oarcorp.com> wrote:
>>>>> On 9/17/2014 10:23 AM, Daniel Gutson wrote:
>>>>>> Marcos and I will take a look.
>>>>> Thanks.
>>>>>> On Wed, Sep 17, 2014 at 12:19 PM, Joel Sherrill
>>>>>> <joel.sherr...@oarcorp.com> wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> I would really appreciate it if someone could look into this
>>>>>>> warning and see if we can get an explanation. It could be
>>>>>>> a source code issue or something higher in the tools.
>>>>>>> It is reported on 120 BSP build configurations:
>>>>>>>
>>>>>>> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:4:
>>>>>>> warning: format '%lc' expects argument of type 'wint_t', but argument 4
>>>>>>> has type 'wchar_t' [-Wformat=]
>>>>>>> ../../../../../../rtems/c/src/../../cpukit/libmisc/shell/hexdump-conv.c:145:4:
>>>>>>> warning: format '%lc' expects argument of type 'wint_t', but argument 4
>>>>>>> has type 'wchar_t' [-Wformat=]
>>>>>>>
>>>>>>> Thanks.
>>>>>>>
>>>>>>> --
>>>>>>> Joel Sherrill, Ph.D. Director of Research & Development
>>>>>>> joel.sherr...@oarcorp.com On-Line Applications Research
>>>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>>>>>> Support Available (256) 722-9985
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> devel mailing list
>>>>>>> devel@rtems.org
>>>>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>>>
>>>>> --
>>>>> Joel Sherrill, Ph.D. Director of Research & Development
>>>>> joel.sherr...@oarcorp.com On-Line Applications Research
>>>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>>>> Support Available (256) 722-9985
>>>>>
>>>>>
>>>>
>>>>
>>>
>>> --
>>> Joel Sherrill, Ph.D. Director of Research & Development
>>> joel.sherr...@oarcorp.com On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>> Support Available (256) 722-9985
>>>
>>
>>
>>
>> --
>> ______________________________
>>
>>
>> Marcos Díaz
>>
>> Software Engineer
>>
>>
>> San Lorenzo 47, 3rd Floor, Office 5
>>
>> Córdoba, Argentina
>>
>>
>> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>>
>> Skype: markdiaz22
>
>
>
> --
> ______________________________
>
>
> Marcos Díaz
>
> Software Engineer
>
>
> San Lorenzo 47, 3rd Floor, Office 5
>
> Córdoba, Argentina
>
>
> Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
>
> Skype: markdiaz22
--
______________________________
Marcos Díaz
Software Engineer
San Lorenzo 47, 3rd Floor, Office 5
Córdoba, Argentina
Phone: +54 351 4217888 / +54 351 4218211/ +54 351 7617452
Skype: markdiaz22
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
