Re: fseek() vs. fseeko()

[Eric Blake <eblake at redhat dot com>]

On 06/19/2012 07:29 AM, Sebastian Huber wrote:
> On 06/19/2012 03:11 PM, Corinna Vinschen wrote:
>> There are 64 bit capable functions available, see newlib/libc/stdio64.
>> I didn't implement that stuff, but I think the idea was that targets
>> using 64 bit off_t would use the fseeko64/ftello64/fsetpos64 functions.
>>
>> In Cygwin, for instance, off_t is 64 bit.  An application calling
>> fseeko will actually call fseeko64 by redirecting the fseeko entry
>> point to fseeko64.
> 
> Ok, then this is a bug in the RTEMS targets using 64-bit off_t.  Since
> the fseeko64() etc. are non-standard this should be invisible for the user.

Either RTEMS should expose the choice between 32-bit and 64-bit off_t
(similar to how glibc has _FILE_OFFSET_BITS and AIX has _LARGE_FILES
macros) to do a compile-time mapping of 'fseeko' to calling the
'fseeko64' function with both functions exposed as entry points, or
RTEMS should make 64-bit off_t unconditional (like Cygwin or BSD) and
always redirect to the stdio64 directory rather than the 32-bit variants
in the stdio directory to make it invisible to the user.  It still might
be worth patching newlib to make it easier to use the stdio64
implementation without forcing the *64 suffix on the entry points
(cygwin gets away with it by doing a link time rename, but I'm not sure
how RTEMS would do it).

-- 
Eric Blake   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature