This is the mail archive of the newlib@sourceware.org mailing list for the newlib project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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?

> >>>In theory you're not supposed to change struct __sFILE, rather you're
> >>>supposed to use struct __sFILE64 and the functions defined in the
> >>>libc/stdio64 subdir.  This discussion seems to have gone lost.
> >>
> >>Ok, and how can I do this.  Is this a configure option?  I don't
> >>want to use fseeko64() directly.
> >
> >Why not?  Cygwin is doing the same.  The application calls fseeko,
> >but internally Cygwin calls fseeko64 since the link lib redirects
> >the call.  fseeko64 does not exist on the application level.
> 
> Ok, the problem is that I am not a Newlib configuration guru.  How
> do I get this behaviour for RTEMS.  Is this a magic configure option
> or do I have to set some pre-processor defines somewhere?

I don't know how to do that for RTEMS.  In Cygwin we have an import
library which defines a symbol fseeko which is nothing but an assembler
jmp to fseeko64.


Corinna

-- 
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]