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

[Dave Reisner]

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:
> > 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 <allan at archlinux.org> 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