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@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@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_...
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