[Libburn] List of possible int-off_t interactions in libburn
scdbackup at gmx.net
scdbackup at gmx.net
Thu Feb 16 04:02:53 PST 2006
Hi,
i scanned the source files in directory libburn for the
key words
int long unsigned
and tried to find out wether a file size is meant.
The items in the following list are sorted by ambiguity.
The clearest cases first. The most remote ones last.
If anybody has proposals for other search expressions
to find variables or return values which possibly represent
fat byte counts - please give me a hint.
There are two items in the list which surely need mending
and for which i felt qualified to propose the attached patch:
1, 2
The patch is tested with this morning's CVS version by
a test burn with test/burniso which i expect to have
touched the changed code.
Derek: two items need your own analysis.
Hopefully they are not affected and thus need no action:
4, 5
If these items are done, i believe libburn is ready for
64 bit off_t and for the media to come during the next
ten years.
--------------------------------------------------------------------
Besides the problem with byte counts of 2 GB or more
there is a future problem with sector counts of 2 billion
or more. This corresponds to a byte count of 4 TB.
(Items 8 and 9)
DVD+RW is a factor 1000 away from 4 TB.
Moore's law predicts about 17 years for this.
Floppy was at 1440 kB about 20 years ago. A factor of 3190.
A floppy did cost about 5 Mark = 3 dollar. I now pay 1 Euro
per DVD+RW (1.20 dollar). Disk was 50 MB then (= 35 floppies)
and 200 GB now (= 42 DVD+RW). They are comparable.
Moore is right.
So this depends much on your time horizon.
If you plan for 15 to 20 years, then a 4 TB CD successor
is to be expected. (CD is already quite outdated.)
I therefore logged all spots where sectors are counted
by int. Just in case you want to do something about it
resp. take advantage of my offer at the end of the list.
--------------------------------------------------------------------
Item 1
Surely affected. Change needed:
structure.c
There is now an off_t return value from burn_source.get_size()
involved in computations of sector counts.
Thus
int size;
has to become
off_t size;
in
int burn_track_get_sectors(struct burn_track *t)
int burn_track_get_shortage(struct burn_track *t)
--------------------------------------------------------------------
Item 2
Surely affected. Change needed:
structure.h
Although it is unlikely that somebody really orders >= 2 GB
of padding, these are clearly fat byte counts and should
therefore become off_t.
struct burn_track
{
...
/** number of 0 bytes to write before data */
int offset;
/** how much offset has been used */
int offsetcount;
/** Number of zeros to write after data */
int tail;
/** how much tail has been used */
int tailcount;
...
This implies a change of parameter types with
void burn_track_define_data(struct burn_track *t, int offset, int tail,
int pad, int mode)
to
void burn_track_define_data(struct burn_track *t, off_t offset, off_t
tail,
int pad, int mode)
and within
sector.c
static void get_bytes(...)
{
...
valid = track->offset - track->offsetcount;
if (valid > count)
valid = count;
...
valid = track->tail - track->tailcount;
if (valid > count - curr)
valid = count - curr;
...
needs to become
static void get_bytes(...)
{
off_t valid_bytes;
...
valid_bytes = track->offset - track->offsetcount;
if ( valid_bytes > count)
valid = count;
else
valid = valid_bytes;
...
valid_bytes = track->tail - track->tailcount;
if ( valid_bytes > count - curr)
valid = count - curr;
else
valid = valid_bytes;
write.c
This seems to be an unused evaluation of burn_track.offset
int burn_write_session(...)
{
...
i = t->offset;
...
at least i cannot recognize any further usage of variable i.
One should clarify this in the one or other way.
--------------------------------------------------------------------
Item 3
Possible program flaws:
mmc.[ch]
Can it be we have an unused variable of the 4 TB class here ? :)
mmc_read_lead_in(...) {
int len;
...
len = buf->sectors;
...
I cannot see any further use of len.
Is it ensured that ( << 24) does not set bit 31 ?
Maybe type (unsigned int) would be better.
void mmc_get_configuration(...) {
int len;
...
len = (c.page->data[0] << 24)
--------------------------------------------------------------------
Item 4
Potentially affected. Review requested:
crc.[ch]
Might the parameters len be a full file size ? (Or is this
only applied to single sectors ?)
unsigned short crc_ccitt(unsigned char *q, int len)
unsigned int crc_32(unsigned char *data, int len)
mmc.[ch]
I should try to learn what an nwa is. Nevertheless, my libburn
reports it as "ignored nwa: 1690367392" so it might be worth to
consider wether it could hit the 2 GB limit.
int mmc_get_nwa(struct burn_drive *d)
read.[ch]
I flatly don't understand what this function does and wether it
is active or will become active. It seems to deal with sector
counts and might belong to the 4 TB problem.
Better have a look at it.
void burn_disc_read(struct burn_drive *d, const struct burn_read_opts
*o)
sector.[ch]
Same stupor in front of this one:
void subcode_user(...)
--------------------------------------------------------------------
Item 5
Potentially affected. Review requested:
transport.h
Is count in struct cue_sheet potentially a fat byte count ?
struct cue_sheet
{
int count;
--------------------------------------------------------------------
Item 6
Not really affected but change advised for clarity:
transport.h
buffer.bytes should be made off_t because that is straight.
struct buffer
{
...
int bytes;
};
The reason for off_t bytes might be in
sector.c
static unsigned char *get_sector(...)
{
...
out->bytes += seclen;
which itself needs no change, though.
I see that
if (out->bytes + (seclen) >= BUFFER_SIZE) {
leads to
out->bytes = 0;
So we will be safe from negative consequences until the
DVD standard is UVC light with 16 layers or so ... :))
--------------------------------------------------------------------
Item 7
Not really affected but noteworthy for once:
file.[ch]
The read functions are useable only up to buffers of 2 GB. :))
I don't know what fleas we import if we change to the official
man page types ssize_t and size_t . (int) is ok for me.
--------------------------------------------------------------------
Item 8
Not really affected but noteworthy for once:
Future media problem case:
2 billion sectors = 4 TB.
It would be neat to be prepared for such media :))
drive.[ch]
int burn_msf_to_sectors(int m, int s, int f)
void burn_sectors_to_msf(int sectors, int *m, int *s, int *f)
libburn.h
Would this need to be signed ?
struct burn_progress {
...
/** The starting logical block address */
int start_sector;
/** The number of sector */
int sectors;
/** The current sector being processed */
int sector;
...
structure.c
Eventually the numbers of a whole media full of sectors:
int burn_track_get_sectors(struct burn_track *t)
int burn_session_get_sectors(struct burn_session *s);
int burn_disc_get_sectors(struct burn_disc *d)
transport.h
struct buffer
{
...
int sectors;
...
Sectors get counted in
sector.c
static unsigned char *get_sector(...)
{
...
out->sectors++;
and copied into
transport.h
struct burn_drive
{
...
int nwa; /* next writeable address */
write.c
int burn_write_track(...)
{
...
int i, ...;
...
sectors = burn_track_get_sectors(t);
...
for (; i < sectors; i++) {
--------------------------------------------------------------------
Item 9
Potentially not really affected but noteworthy for once.
Review requested:
I found indications that lba is counted in sector units.
So this is also prone to the 4 TB problem.
sector.[ch]
int burn_msf_to_lba(int m, int s, int f)
void burn_lba_to_msf(int lba, int *m, int *s, int *f)
structure.h
struct burn_track
{
...
/* lba address of the index */
unsigned int index[99];
...
toc.c
void toc_find_modes(struct burn_drive *d)
{
int lba;
transport.h
struct burn_drive
{
...
int alba; /* absolute lba */
int rlba; /* relative lba in section */
int start_lba;
int end_lba;
...
write.c
Eventually parameter lba needs adjustment
static void add_cue(struct cue_sheet *sheet, unsigned char ctladr,
unsigned char tno, unsigned char indx,
unsigned char form, unsigned char scms, int lba)
--------------------------------------------------------------------
Item 10
Not really affected but noteworthy for once:
Somewhat similar but even more unrealistic:
A drive buffer of 2 TB would be nice, wouldn't it ?
/** The size of the drive's buffer (in kilobytes) */
int buffer_size;
--------------------------------------------------------------------
Unaffected seem to be:
async.[ch]
debug.[ch]
error.h
init.[ch]
lec.[ch]
message.[ch]
null.[ch]
options.[ch]
sbc.[ch]
sg.[ch]
source.[ch]
spc.[ch]
util.[ch]
--------------------------------------------------------------------
If you want, i take care of any of the items
1, 2, 3, 6, 8, 9
Just order by number and i'll develop patch proposals.
The following items would need your close attention
4, 5,
and with two (less important ones) i could need some
explanations before i would start to work on them:
3, 9
Items which need no further attention at all:
7, 10
I am not really sure wether the list is 100% complete yet.
Well, i now lack of more ideas, at least.
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.16.113717.burn_cvs_A60216_df
Type: application/octet-stream
Size: 3547 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/libburn/attachments/20060216/c08a46c4/2006.02.16.113717-0001.obj
More information about the libburn
mailing list