[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: FW: syncrepl.c uses strndup() (ITS#2481)
I changed strndup() to ch_strdup().
Also changed are strdup()s in config.c to ch_strdup().
Thanks.
- Jong
------------------------
Jong Hyuk Choi
IBM Thomas J. Watson Research Center - Enterprise Linux Group
P. O. Box 218, Yorktown Heights, NY 10598
email: jongchoi@us.ibm.com
(phone) 914-945-3979 (fax) 914-945-4425 TL: 862-3979
"Howard Chu" <hyc@highlandsun.com>@OpenLDAP.org on 05/02/2003 08:07:17 AM
Sent by: owner-openldap-devel@OpenLDAP.org
To: <openldap-devel@OpenLDAP.org>
cc:
Subject: FW: syncrepl.c uses strndup() (ITS#2481)
>>>
-----Original Message-----
From: owner-openldap-bugs@OpenLDAP.org
[mailto:owner-openldap-bugs@OpenLDAP.org]On Behalf Of
h.b.furuseth@usit.uio.no
Full_Name: Hallvard B. Furuseth
Version: HEAD
OS: Solaris
URL:
Submission from: (NULL) (129.240.186.42)
syncrepl.c uses the function strndup(), which does not exist.
ber_strndup(), ber_strndup_x(), LBER_STRNDUP(), LDAP_STRNDUP(),
LDAP_STRNDUPX() and SLAP_STRNDUP() exist, I don't know which
one is supposed to be used.
<<<
The LDAP_STR* macros are for libldap's internal use. Likewise the LBER_STR*
macros are only for use within liblber.
Of the func() vs func_x() variant, the plain func just calls func_x with a
NULL context to get the regular global malloc, and is provided for backward
compatibility. I've been using the _x functions directly in places, to
avoid
the extra function call, but you really only need it if you want the
allocation to come from the thread-local memory context. In this particular
case, the strndup's appear to be for values that must come from regular
malloc, so using a NULL memory context would be correct. I guess Jong
should
verify this.
-- Howard Chu
Chief Architect, Symas Corp. Director, Highland Sun
http://www.symas.com http://highlandsun.com/hyc
Symas: Premier OpenSource Development and Support