asserts and manadatory build instructions (was ITS#8240)
by Michael Ströder
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
clarify.
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.
Ciao, Michael.
2 months, 2 weeks
Please review 2.5 plan (non-development items)
by Ondřej Kuzník
Hi,
I've prepared a plan what the project wants to achieve as part of the
2.5 stream apart from core OpenLDAP development that I intend to send to
-technical for wider discussion and as a call for participation.
It has been suggested to me that people might want to comment/propose
changes to it so attaching a draft here. Please let me know what you
think or if you agree in broad terms it is fit to be circulated more
widely.
Thanks,
--
Ondřej Kuzník
Senior Software Engineer
Symas Corporation http://www.symas.com
Packaged, certified, and supported LDAP solutions powered by OpenLDAP
2 years, 4 months
STRERROR(e) vs AC_STRERROR_R(e,b,l)
by Ryan Tandy
I'm working on adding debug logging for GnuTLS errors. I'd like to add a
strerror() inside tlsg_getfile() as part of this.
First question: I found STRERROR(e) and AC_STRERROR_R(e,b,l). It looks
like AC_STRERROR_R should be preferred for new code. Is that correct?
Second question: I noticed that STRERROR(e) triggers deprecation
warnings on my system:
.../libraries/libldap/os-ip.c:248: warning: `sys_errlist' is deprecated; use `strerror' or `strerror_r' instead
.../libraries/libldap/os-ip.c:248: warning: `sys_nerr' is deprecated; use `strerror' or `strerror_r' instead
Is replacing occurrences of STRERROR with AC_STRERROR_R a worthwhile
cleanup? (cf. 62da0b673, ba749eb79, bfd09a16a)
Are there cases where AC_STRERROR_R would be inappropriate? (where the
non-threadsafe strerror() fallback would be totally unacceptable?)
Thanks.
2 years, 4 months
