[Libburn] Patch to enable arbitrary input fd (updated 2nd submission)

[Derek Foreman]

On Sat, 11 Feb 2006, scdbackup at gmx.net wrote:

> Hi,
>
>> sizeof(off_t) on a 32 bit machine is 32 bits...
>
> Not necessarily. It is 32 bits if nobody bothers to
> enable large file support.
>
> Quoting myself from a discussion on the cdwrite list:

... snip

Ok, I didn't realize this.  I'll take it as off_t if someone writes the 
autoconf magic to properly handle it... :)

>> I'm thinking maybe we should consider C99 instead of C90, which gives us
>> int64_t in stdint.h. (I've added that #include)
>
> Type double would be a solution even for K&R C. :))

double is quite frankly repulsive for this purpose. ;)

What if I want to find out how many sectors are in the file using /?  what 
if I want to find out how far into a sector we've read using %?

> Usually i would heavily object a code transition
> which does not allow to port to many other Unix-like
> systems. But libburn is tied so close to modern Linux
> that there will be not much of a practical problem
> with that.

There appears to be another thread on the list about that very thing right 
now.

While I don't care too much about non-linux platforms, I won't go out of 
my way to break support on them.

>> What I merged was your new blocking file_read.
>>
>> Can you change the rest to use off_t?
>
> I am not sure wether i understand what you want of me.
> Is this a rethorical question to underline the problems
> introduced by a use of off_t ?

Late night typo.  I meant to ask if you'd consider using int64_t.

I have no objection to off_t anymore, as long as the right defines are set 
up in the configure stuff.  (Dana, you're playing about in the Makefiles 
still? Do you want to do this?)

> Currently  file_size()  adds an off_t to an int. That
> off_t is obtained from fstat(). If off_t is 64 bit
> (which can be caused by system settings) then you get
> into trouble with very large files.
> If off_t is 32 bit than that type itself will have
> trouble with big files and it will confuse int if
> the file size is between 2 GB and 4 GB.

Yup, that code should be considered a bug.

> Yes, i would help to identify the spots in the code
> which need mending.

Thank you.

(I'll answer the rest seperately, because I think it's spread across a few 
emails now)