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
1 year, 11 months
- 6
- 7
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
- 1
- 0
- ← Newer
- 1
- Older →