[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