https://bugs.openldap.org/show_bug.cgi?id=9017
--- Comment #19 from Howard Chu <[email protected]> --- [email protected] wrote: > https://bugs.openldap.org/show_bug.cgi?id=9017 > > --- Comment #18 from [email protected] <[email protected]> --- >> 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. -- You are receiving this mail because: You are on the CC list for the bug.
