abartlet at samba.org
Wed Mar 23 23:43:58 MDT 2011
On Wed, 2011-03-23 at 09:15 +0100, Volker Lendecke wrote:
> On Wed, Mar 23, 2011 at 08:22:01AM +0100, Andrew Bartlett wrote:
> > The branch, master has been updated
> > via 41051fd lib/util: Merge basic string length and comparison functions
> > via 89fd1cb s3-lib prepare Samba3 to use common codepoint based string functions
> > from d73db40 s3-safe_string: Add checked_strlcpy()
> Is this really necessary? I REALLY REALLY tried to avoid
> this non-convenient convenience stuff in S3. Can we discuss
> this in please BEFORE it goes in?
The code in lib/util/charset is the common character set handling for
all of Samba, and uses the poorly named 'get_iconv_convenience()'
internally to ensure that they have a valid iconv handle at all times.
I agree, it's not a good name - it should be named 'iconv_handle', but
regardless of it's name it avoids direct reference to possibly
un-initialised global variables in our core string handling.
Samba3's code already uses the iconv handle - that's how the core
convert_string() functions get to iconv now. The higher level code
never uses the handle-based functions directly, but all of the string
and character conversion library is based on it at one level or
The patch you saw today only appears to change source3/ code because of
your request that changes be made to the source3 code before in that as
requested, it changes source3 code to match what the common code will
be, rather than simply removing it.
The question of how far up the stack the iconv handle should be exposed
is a real one, with costs and benefits.
It is exposed in some of the NDR code because there are situations in
MAPI that negotiate the DOS charset, and so it was seen as helpful to be
able to change those on the fly there, but otherwise I agree,
application level code should not in general have to deal with the
handle, and it has been exposed too far up the stack in Samba4.
How far below that the handle should or should not be exposed is an open
question: My preference would be to have it available at the level of
strrchr_m etc as an optional _ctx function, that I could write tests
around, to confirm non-UTF8 string handling.
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Samba Developer, Cisco Inc.
More information about the samba-technical