[Libburn] Re: 64 bit off_t

scdbackup at gmx.net scdbackup at gmx.net
Mon Feb 20 12:26:35 PST 2006


Hi,

> checking for special C compiler options needed for large files... no
> [...]
> checking for fseeko... yes

Same output with my SuSE 9.0.

> I have also commited a change in libburn.h that will make sure
> _FILE_OFFSET_BITS is 64 in order to compile anything against libburn.

Snaps nicely:
 libburn/libburn.h:30:2: #error "Incompatible file offset size.
 _FILE_OFFSET_BITS must be 64."

With -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE=1 it compiles.


> My only concern is the future, if someday 64 is not what is meant by
> largefile, and if _FILE_OFFSET_BITS will even be set by configure on a
> 64bit architechture. I could do weird stuff to make it dynamic to
> whatever off_t size libburn was built with, but it wouldn't be very
> pretty in the tree, and I am not sure if it is really necessary.

There would also be the problem that applications have to follow
any move of libburn's off_t.
So a change of _FILE_OFFSET_BITS would make necessary a change
in the API documentation anyway. Is the build system able to
adjust that automatically ?


-----------------------------------------------------------------------

We have some obsolete misleading comments left now:

In libburn.h there is still Derek's sentence:
   XXX we should enforce 64-bitness for off_t

In file.c there is an oxymoronic cooperation between Derek and me:
     Possibly libburn/file.c is not the right storage location for this.
     To make it ready for a move, this function is not declared static.
  */
  static int read_full_buffer(int fd, unsigned char *buffer, int size)

and this rather harmless but inappropriate text:
  /* ------ provisory location for the new source subclass fd --------- */

I propose to remove those sentences.

-----------------------------------------------------------------------

You should also consider to introduce item 1 from my most recent
patch proposal 
  http://lists.freedesktop.org/archives/libburn/attachments/20060216/c08a46c4/2006.02.16.113717-0001.obj
the two type changes to
  off_t size;
in
  int burn_track_get_sectors(struct burn_track *t)
  int burn_track_get_shortage(struct burn_track *t)

One may dispute item 2 (off_t for offset and padding) but this
item 1 is flatly necessary to avoid rollover effects of type int.

-----------------------------------------------------------------------


Have a nice day :)

Thomas



More information about the libburn mailing list