[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible

From: Thomas Schmitt
Subject: Re: [Libcdio-devel] [RFC] New API iso9660_statv2_t as API/ABI compatible way to read files >= 4 GiB
Date: Fri, 06 Jul 2018 22:54:01 +0200


Pete Batard's MinGW-w64 complained:
> iso9660_fs.c:866:37: warning: format '%lu' expects argument of type 'long
> unsigned int', but argument 2 has type 'long long unsigned int' [-Wformat=]

I should have put brackets around the computation.

> iso9660_fs.c:914:23: warning: array subscript is above array bounds 
> [-Warray-bounds]
>   p_stat->magic_number[1] = 2;

Argh. A residue from a test.

I assume that valgrind did not complain because the compiler inserted some
padding in struct iso9660_statv2_s between
  uint8_t magic_number[ISO9660_STATV2_MAGIC_SIZE];
  iso_rock_statbuf_t rr;

(My question about alignment issues got no answers or opinions yet.)

I tried to correct the flaws by commit 2d58119

Pete himself:
> So, I do feel bad about currently leaning against your proposal,

No need to do so.
I recognized the size problem early, but decided to go on in order to offer
a true choice between your proposal and mine.

Part of the changeset's complexity is the deplorable state of inner
architecture in current iso9660_fs.c and rock.c. Insofar, iso9660_statv2_t
would be a real improvement.

> code upgrade to v2 looks to be a lot more painful
> than simply being able to reuse a reworked current struct,

If it would be the way to get access to large files, then the pain would
be the price for progress.
The effort is not unbearable (i'd offer help to users) and the runtime
check should detect any incomplete transition work.

> After all, now that we have this massive effort, it would certainly feel
> like kind of a waste not to use it...

Yeah ! Accepted because of its big sad eyes ... :))

Have a nice day :)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]