RTEMS patch sweep 3

[Ralf Corsepius]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: newlib-rtems-libc-include-2.diff
URL: <http://sourceware.org/pipermail/newlib/attachments/20091217/06a37357/attachment.ksh>