On Mon, Nov 25, 2013 at 10:27 AM, Dave Reisner <[email protected]> wrote: > 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: >> > 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
Hi, Dave. Thanks for your reply, but I am a bit confused. I said that the only exposure the libalpm API has to the largefile problems is that it passes off_t across. You seem to be saying there is greater exposure than that, but all the examples you pointed to are where off_t is being passed across the API. I did look carefully through the API for any other largefile issues and found zero. Of course I am only human. So if, as you said, that "is definitely not the case", then could you please point me to where the exposure (other than off_t) is in the libalpm API? Jeremy
