Re: [PATCH 1/3] Change _offset type from int to _off_t

[Corinna Vinschen <vinschen at redhat dot com>]

On Nov 26 10:52, Sebastian Huber wrote:
> On 11/23/2012 02:56 PM, Corinna Vinschen wrote:
> >On Nov 23 14:26, Sebastian Huber wrote:
> >>>On 11/23/2012 02:15 PM, Corinna Vinschen wrote:
> >>>> >On Nov 23 13:24, Sebastian Huber wrote:
> >>>>> >>On 11/23/2012 11:21 AM, Corinna Vinschen wrote:
> >>>>>> >>>It breaks binary compatibility.  Full stop.  And this is a problem.
> >>>>> >>
> >>>>> >>Yes, this is a problem, but not for RTEMS.
> >>>>> >>
> >>>>>> >>>
> >>>>>> >>>If we do that, we must make really sure that this isn't a problem.
> >>>>> >>
> >>>>> >>We can add a new type, which is int by default and for example _off_t on RTEMS.
> >>>> >
> >>>> >But this new type doesn't match your fseeko/ftello implementation
> >>>> >anymore.
> >>>
> >>>Yes, this is bad.
> >Note that I didn't say that the change from int to _off_t is wrong per
> >se.  It just has to be considered very carefully.
> >
> >We get no problems at all for targets where sizeof(long) == sizeof(int).
> >But we're in trouble as soon as that's not the case anymore.
> >
> >This affects 16 bit targets with typically sizeof(int) == 2 and
> >sizeof(long) == 4 as well as all LP64 targets.
> >
> >But here's another problem:  For these targets with sizeof(int) <
> >sizeof(long), the structure __sFILE was always(!) wrong, because the
> >offset member was never able to cover the whole _off_t offset range.
> >
> >So, on second thought, it might be*necessary*  to change offset from
> >int to _off_t, because that's a required bug fix.
> >
> >But then, how do we handle backward compatibility here?  I really
> >don't know.
> >
> >Any suggestions?
> 
> Lets introduce
> 
> #if defined(__rtems__) || X
>   typedef _off_t __sFile_off_t;
> #else
>   typedef int __sFile_off_t;
> #endif
> 
> somewhere.

That doesn't sound right to me.  As I outlined in my previous reply,
it seems that using int was always wrong and _off_t is the right thing
to do for all targets.

RTEMS or, FWIW, 64 bit Cygwin (which doesn't exist yet but will have the
same problem) are more or less no-brainers.  My problem, and that's what
I'd like to have input on is, how do we handle backward compatibility
for affected 16 bit or LP64 64 bit targets?


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat