rename issue

[Ralf Corsepius]

Chris Johns wrote:
> Joel Sherrill wrote:
>   
>> Ralf Corsepius wrote:
>>     
>>> Joel Sherrill wrote:
>>>   
>>>       
>>>> Looks like we are heading for a new spin of the 4.10 tools
>>>> soon.
>>>>   
>>>>     
>>>>         
>>> Yep, .... I am going to address these issues sequentially.
>>>   
>>>       
>>>>   + drop - DMISSING_SYSCALL_NAMES from configure.host
>>>>   
>>>>     
>>>>         
>>> Having cross-checked your proposal, I leaned to agree with your proposal 
>>> and am about to launch a toolchain spin.
>>>
>>> Please test this toolchain! Though this patch is a one-liner, this step 
>>> is quite intrusive, and is not unlikely to have (so far) unconsidered 
>>> side-effects.
>>>
>>>   
>>>       
>> Yeah!  This one worried me.  It could easily turn up a LOT of
>> stuff.
>>     
>
> What should we be looking for ?
>   
Symbol clashes/conflicts related to "_"-prefixed function symbols and
bogus/redundant <function>_r vs. <function> calls.

>   
>>>>   + inttypes.h warning
>>>>   
>>>>     
>>>>         
>>> WIP on my part, but no patch available so far.
>>>   
>>>       
>> OK.  Chris and I were on a warning hunt and these showed up
>> in cpukit.  They will disappear again when you get the patch.
>>
>>     
>
> Which warnings will this fix ?
>   

Joel's test case had been this:

../../../../../../rtems/c/src/../../cpukit/libmisc/shell/main_mwdump.c:65:
>> warning: format '%08llX' expects type 'long long unsigned int', but
>> argument
>> 2 has type 'uintptr_t'


It shows with newlib-1.17.0 based toolchains (rtems-4.10) and can be reproduced with this test case:


#include <inttypes.h>
#include <stdio.h>

extern uintptr_t x;

void doit( void ) { 
  printf("0x%08" PRIXPTR " ",addr);
}

The origin of this warning is PRIXPTR being defined to "llX" on some 
targets, while uintptr_t is a (32bit) "long".

The warning had been introduced by an upstream newlib patch, which was 
supposed to provide better c99/POSIX compliance. However,  with this 
patch applied, gcc now complains about it.

So, the question, I don't know the anser to, is: Whose fault is this 
warning? Is GCC not sufficently c99/POSIX compliant or is newlib bugged?

newlib-1.16.0 (rtems-4.9 toolchains) don't have the patch in question 
applied, and are not subject to this issue.

Ralf