Re: [Libcdio-devel] udf_read_sectors cannot handle offsets past 2 GB

[Pete Batard]

On 2012.01.25 03:47, Rocky Bernstein wrote:
> I don't think believe anyone has ever tried to customize or create a
> cdio_stream. And even so, the code is painted in a corner now. So I think
> it okay for the next version to be a little incompatible.

I hope so, though I think this is the only area where existing platforms 
should see some change, but they can still use the same API if needed. 
If they want to continue using fseek, all they need to ensure is that 
off_t is defined as long and make sure HAVE_FSEEKO is undefined.

Platforms where off_t is not defined as long, and that still want to use 
fseek should also not see any change, as long as they stick to images 
that are less than 2 GB in size (and at least now, we do alert them 
otherwise)

The only place I can see of disturbance is if a platform as a long 
that's defined as 64 bit, with a matching 64 bit fseek, though, if such 
a platform actually exists, the patching I did makes me think they'd 
probably experience issues with LFS with the current libcdio, as I 
believe there were 32 bit values used here and there. Also, such a 
platform would have major portability headaches...

> Rereading the above, I have probably painted to gloomy a picture. If I
> understand things correctly, even with the proposed change, one can set
> preprocessor symbols to do the same things as we currently do.

I may have painted a gloomy picture too when presenting the issue, as 
fseek/fseeko should be interchangeable for the cases that are of concern 
to us, and therefore the changes should be fairly transparent for 
existing libcdio users.

> And so I did want to say that ultimately there should be configure flags
> that allow people to more directly enable or disable fseeko and largefile
> support.

I'll answer that in the next e-mail.

Regards,

/Pete