RTEMS patch sweep 3

Jeff Johnston jjohnstn@redhat.com
Thu Dec 17 19:19:00 GMT 2009


On 16/12/09 10:42 PM, Ralf Corsepius wrote:
> On 12/16/2009 07:45 PM, Jeff Johnston wrote:
>> On 16/12/09 12:53 PM, Ralf Corsepius wrote:
>>> On 12/16/2009 06:50 PM, Ralf Corsepius wrote:
>>>> Hi,
>>>>
>>>> ... and another one.
>>>>
>>>> This patch aims at making some parts of newlib more posix compliant.
>>>>
>>>> One part is #ifdef'ed __rtems__, because it relies on (POSIX) types
>>>> which (AFAICT) newlib currently are only supplies for RTEMS (blksize_t,
>>>> blkcnt_t) and because we haven't tested it in other configurations but
>>>> in RTEMS configurations.
>>>>
>>>> Ralf
>>>
>>> Oops, fingers faster than brains - The attachment containing the patch
>>> was missing ;)
>>>
>>> Ralf
>>
>> Shouldn't the added #endif be after the long st_spare4[]? Otherwise, you
>> are changing the struct for the #if before it which normally wouldn't
>> have included this field.
>
> I am not sure. It would depend upon which purpose st_spare4 was intended
> to be used for, IMO.
>
> Probably it was only "having 2 longs in reserve" to void breaking
> backward compatibility, in case should one want to extend "struct stat".
>
>
> As we consider newlib-version upgrades to be "not ABI/API-preserving"
> and utilize newlib-version upgrades to deliberately break API/ABIs, this
> point is not of much importance to us.
>
> The only effect keeping st_spare4 should have on RTEMS would be "wasting
> 2 longs" on "struct stat" and keeping this field available should newlib
> start using it internally.
>
> That said, I don't have a problem with moving the #endif, such that
> st_spare4 stays also preserved on RTEMS.
>
> Below is an updated patch, now with st_spare4 kept for RTEMS.
>
> Ralf

Actually, I am referring to the fact that the

#if defined(__svr4__) && !defined(__PPC__) && !defined(__sun__)

did not previously get the spare fields prior to your change.  Now they 
do.  I believe that both #endifs belong after the spare fields.

-- Jeff J.



More information about the Newlib mailing list