[pacman-dev] Bug in libalpm: sizeof(off_t)

[Jeremy Heiner]

On Mon, Nov 25, 2013 at 10:27 AM, Dave Reisner <d at falconindy.com> 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 <allan at archlinux.org> 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