[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