hyc(a)symas.com wrote in ITS#8240:
> Our patch response was too hasty. There is no OpenLDAP bug here, the real
> issue is production binaries being built with asserts enabled instead of
> compiling with -DNDEBUG. That's an issue for packagers and distros to resolve.
> Closing this ITS, not an OpenLDAP bug.
Maybe I missed something. But this is the first time I've heard about -DNDEBUG
being mandatory when compiling binary packages for production use. Does it
have other effects?
And what are general rules for assert statements in OpenLDAP code?
In my own (Python) code assert statements are supposed to be only triggered if
something goes wrong *internally* (type issues etc.). If somebody manages to
trigger an assert statement with invalid input from "outside" I always
consider this to be a serious bug revealing insufficient error handling even
though e.g. web2ldap just logs the exception but won't crash. YMMV, but please
I also wonder whether there are more mandatory rules for building packages and
where I can find them.
Please don't get me wrong: My inquiry is in good faith to avoid unnecessary
ITS based on misunderstanding.
On 21/12/15 03:39, openldap-commit2devel(a)OpenLDAP.org wrote:
> commit 209b56fead1afe8273db6c714c0a74a9c09b9cf6
> Author: Howard Chu <hyc(a)openldap.org>
> Date: Mon Dec 21 02:36:20 2015 +0000
> ITS#8324 fix for WRITEMAP
> We called FlushViewOfFile with (map,mapsize) which worked fine
> when we had allocated the entire map already. Now we have to make
> sure to only flush as much as was actually written. Add a numpgs
> argument to tell how much to flush in env_sync0().
Do env_sync() and commit() survive the test program from ITS#7886?
It creates a datafile which ends before mm_last_pg+1.