openldap-its@openldap.org wrote:
https://bugs.openldap.org/show_bug.cgi?id=9017
--- Comment #18 from kriszyp@gmail.com kriszyp@gmail.com ---
I've committed your first two patches as-is,
Thank you so much, appreciate the review and including this code. I hope it helps other Windows users leverage the awesome LMDB performance and integrity!
and taken a different approach for the off_t issue.
Unfortunately, this commit didn't work for me. LMDB no longer compiles when using LARGE_INTEGER for offsets. Perhaps ULONG would work better? I get the following compilation errors (or is there possibly something I need to define to address this?):
\dependencies\lmdb\libraries\liblmdb\mdb.c(3739): error C2440: '=': cannot convert from 'pgno_t' to 'LA RGE_INTEGER' [\build\node-lmdb.vcxproj] \dependencies\lmdb\libraries\liblmdb\mdb.c(3744): error C2088: '!=': illegal for union [C:\dev\node-lmd b\build\node-lmdb.vcxproj] \dependencies\lmdb\libraries\liblmdb\mdb.c(3767): error C2088: '&': illegal for union [ \build\node-lmdb.vcxproj]
Apparently LARGE_INTEGER isn't an integer at all, it appears to be a structure.
You ought to be able to use int64_t instead, or any other explicitly 64-bit signed integer type.
Since offsets can be forward or backward from a designated reference point, off_t and MDB_OFF_T must be a signed type. size_t is explicitly unsigned, so it is an error to use that for this purpose. It's also only 32 bits wide on a 32bit machine, so it'd be unsuitable for larger DBs.
The use of MDB_OFF_T/off_t for env->me_size is a bit bogus, since a file size should be unsigned. But we don't have address spaces large enough yet for the difference between 2^63 and 2^64 to matter. (And also, the me_size field has actually never been used. Probably should just be deleted...)
Do you still want the corresponding patch in 0.9? And can you please remind me where the 0.9 patch is? Thanks.
I could if you want, but you convinced me that using mdb.master and focusing 1.0 was the way to go, so that's what we have been using for the last few months (with my patches applied locally), and it has been working great on our servers. I don't need an 0.9 patch, but I could work on creating one if you think it is important.
No, that's fine.