On Mon, Nov 25, 2013 at 09:30:01AM -0500, Jeremy Heiner wrote: > On Mon, Nov 25, 2013 at 9:12 AM, Allan McRae <[email protected]> wrote: > > On 25/11/13 23:43, Andrew Gregory wrote: > >> On 11/25/13 at 09:08pm, Allan McRae wrote: > >>> On 22/11/13 22:37, Jeremy Heiner wrote: > >>>> On Thu, Nov 21, 2013 at 3:52 PM, Allan McRae <[email protected]> wrote: > >>>>> Nope - documenting is the only real way to deal with this. For example: > >>>>> > >>>>> http://www.gnupg.org/documentation/manuals/gpgme/Largefile-Support-_0028LFS_0029.html > >>>> > >>>> How about the approach outlined in the attachment? It passes 'make > >>>> check' and performs correctly when a libalpm client app goofs up. > >>>> > >>> > >>> Please send patches inline so we can easily comment. > >>> > >>> I was quite surprised this worked: > >>> > >>> +#define alpm_initialize(root,dbpath,err) \ > >>> + alpm_initialize_check_largefile(root, dbpath, err, sizeof(off_t)) > >>> > >>> The sizeof(off_t) gets evaluated before the #define? That can't be > >>> right... So must be optimised out? I'm either missing something here > >>> or this is prone to breakage. > >> > >> If I'm not mistaken, sizeof is evaluated at compile time. This works > >> because the sizeof(off_t) in the #define is evaluated when the calling > >> program is compiled and the sizeof(off_t) inside > >> alpm_initialize_check_largefile is evaluated when alpm is compiled. > >> > > > > Ah - compile time evaluation... I understand what this is doing now. > > However, I don't like that this is a runtime check. > > > > From searching around, we are definitely not the first people to run > > into this issue, but seem to be the only ones who are trying to code around. > > > > Allan > > > > I think the reason is that most libraries that face this issue have > more exposure to it than libalpm does. For example GPGME passes file > descriptors across its API, and that is a much bigger can of worms. > It's not surprising that they choose to avoid that mess. But the > libalpm API only passes off_t across. All the file stuff is completely > encapsulated, so most of the largefile problems are simply not > problems for libalpm. > Jeremy
A cursory examination of alpm.h shows that this is definitely not the case -- it isn't only the "file stuff", and even that API isn't abstracted away since we publicly expose off_t in some of our structs. And, we have callbacks which pass off_t as well. At best, you read a corrupt value. At worst, you crash after wrongly calculating offsets of other struct members. This isn't a new problem for alpm or anyone else dealing with large files. It's simply a trait of the target system which has to be adhered to. I propose we do nothing. d
