[Libburn] Derek: Patch proposal after your recent decisions
scdbackup at gmx.net
scdbackup at gmx.net
Wed Feb 15 03:19:53 PST 2006
Hi,
attached is my implementation proposal concerning
your recent decisions about off_t, burn_source_file
and burn_source_fd.
It has been tested via test/burniso for regular file
input as well as for piped stdin.
Notes:
- #include <sys/types.h> is back in libburn.h
I removed <stdint.h> because i believe you introduced it only
for the sake of the now dismissed int64_t.
If this is an error, i apologize. :)
- The new class burn_source_fd is implemented in the source files
files.[ch]. That is because i feel unable to bring new files
into the binary build system of libburn.
Please split file.[ch] according to your style preferences.
- Both read methods of burn_source_file and of burn_source_fd
are now based on a generic wrapper function around read(2):
read_full_buffer()
Since this is neither a method of burn_source_file nor of
burn_source_fd it should probably be in a more neutral
source file.
Please move it as appropriate.
- off_t is currently rather 32 bit on conventional systems.
I feel unable to introduce external macro settings into the
binary build system of libburn. There seems to be no libburn
include file which is really included by all libburn sources.
It is not urgent to augment off_t to 64 bit unless you want
to introduce it quickly for clarity reasons. The code
proposal will work for CD sizes even with 32 bit off_t.
(My statement that one would need 64 bit to recognize files
>= 4GB was wrong. 32 bit fstat() returns -1 in such a case.
This suffices for now.)
Please remember to eventually announce the need for 64-bit
macros in the API documentation at an exposed place.
- The get_size() methods for now restrict their return value to
2 GB minus 800 MB.
This shall ensure that no return value is issued which leads
to an integer rollover after any reasonable CD size computation
is applied to it. (2GB-1 might roll over if you add 150 sectors)
I assume that 1.2 GB is larger than any valid CD image and that
no CD size computation adds more than 800 MB.
As soon as libburn is checked for off_t safety, this restriction
might get lifted. For now it seems better that way.
I considered to set an assert() on the file size. But if libburn
uses abort() as a regular means of communication with the calling
application then it would need to offer appropriate signal handling.
(I could contribute some.)
Whatever, the new get_size() implementation is in any case better
than the old one. I advise you to accept it for now, even if you
think that it is not optimal. (I think so myself, but will first
have to scan for the real int-off_t problems.)
Have a nice day :)
Thomas
--
DSL-Aktion wegen großer Nachfrage bis 28.2.2006 verlängert:
GMX DSL-Flatrate 1 Jahr kostenlos* http://www.gmx.net/de/go/dsl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 2006.02.15.104411.burn_cvs_A60215_df
Type: application/octet-stream
Size: 8806 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/libburn/attachments/20060215/b6f1ec0d/2006.02.15.104411-0001.obj
More information about the libburn
mailing list