Re: add v850 to rtems types

[Ralf Corsepius <ralf dot corsepius at rtems dot org>]

On 09/06/2012 03:09 PM, Eric Blake wrote:
> On 09/05/2012 10:59 PM, Ralf Corsepius wrote:
> > On 09/06/2012 12:38 AM, Joel Sherrill wrote:
> > > Is the attached patch OK to apply?
> >
> >
> > No.
> >
> > The v850 is already covered by
> >
> >
> > 2012-07-13  Ralf CorsÃpius  <ralf.corsepius@rtems.org>
> >
> >          * libc/sys/rtems/machine/_types.h (_ssize_t): Add __ARM_EABI__,
> >          __v850__, __v851__.
> >
> >
> > The non-POSIX compliant __v850 define is redundant to the
> > POSIX-compliant __v850__ and __v851__
>
> Huh?  How is __v850 non-POSIX compliant?

It's GCC convention to use __XXXX___ for compiler internal, 
"posix-compliant" defines.

> POSIX mirrors the C99 rules
> (and C11 keeps those rules) that all identifiers starting with __ are
> reserved for the implementation; hence __v850 and __v850__ are both
> implementation-reserved names, and neither one violates POSIX.

If you say so. All I can say is, this does not match GCC conventions.

Whether the claim of __XXX defines not being strictly POSIX compliant is 
true, I don't know. I however, recall a larger campaign in GCC to 
replace __XXX defines with __XXX__ defines and to consider __XXX defines 
obsolete and deprecated.

 GCC even uses special cpp macros/functions in gcc/config to automate 
this behavior (Using these macros "gcc --posix" even supporess some 
__XXX macros and only emits __XXX macros)

 This never was enforced, because some targets __XXX defines cannot 
easily be removed for historical reasons. (One such case was "__linux" 
vs. "__linux__").

In any case using __v850 is redundant to __v850__ || __v851__, with 
__v851__ and __v850__ having a subtily different meaning than __v850.

Ralf