Managing DNs in libads only in utf8

simo idra at
Tue Feb 27 19:18:55 GMT 2007

On Tue, 2007-02-27 at 13:09 -0600, Gerald (Jerry) Carter wrote:
> Hash: SHA1
> simo wrote:
> > On Tue, 2007-02-27 at 12:29 -0600, Gerald (Jerry) Carter wrote:
> >> Hash: SHA1
> >>
> >> simo wrote:
> >>
> >>>> Your extra code is simply not needed in this
> >>>> case. Under what case do we not tell people
> >>>> to change to "unix charset = utf8" ?
> >>> In any case they can't ?
> >>> Why do we have the option at all ?
> >> I think Jeremy is looking for a practical example
> >> to justify why the code should be changed at all.
> > 
> > The practical example is the group membership bug 
> > I posted to this thread with also a bug report
> > we have in our bugzilla.
> This does not answer the question of why we
> can't say that the fix is to set "unix charset
> = utf8".  I hate to say this because I know it
> will come back to haunt me, be we don't have
> to fix *every* bug. :-)  Or make Samba work in
> *every* environment.  That would be an infinite task.
> So we have two proposals.  One which requires code
> changes and one which does not.  Why should we
> pick the one that requires code changes?

Cause Jeremy's patch is a noop ?

> > It is obvious we can't make miracles, if you use 
> > a KOIR set of characters on disk and you are
> > sent a japanese chracter in the file name
> > we have no choice but drop it and tell to switch 
> > to utf8 to fix such problems.
> > 
> > But there are cases when we never hit the disk 
> > or any syscall, and in these cases I don't see why we
> > should be lazy and not fix an easily fixable problem.
> I think the argument would be that it is called
> maintaining the integrity of the design.  Not "being
> lazy".  Adding corner cases increase the complexity
> of the design which makes for a worse system with
> regards to maintainability.

This may be true, but I still hope we don't reason by absolutes and
decide case by case on the merit of the code.

> > The ldap DN stuff is such a thing, and 
> > using a struct to hold the string making
> > it evident it is not just another char * will
> > make it possible to use utf8 strings without 
> > easily be mistaken and mix unix charset stuff
> > with utf8 stuff.
> > 
> > I understand Jeremy may still find such patches 
> > uncomfortable, and reject them.  I'll take the
> > risk, being prudent is ok for me, being conservative
> > just for the sake of it just sucks.
> Jeremy feels stronger about this than I do.  I wouldn't
> presume to speak for him or anyone else.  Obviously
> the final vote to accept the change or not can only
> be done when there is a final patch proposed.


> So it's pretty much up to you if you want to pursue
> designing a patch that
> a) uses a struct utf8_t {} as suggested by Volker,


> (b) solves the supplementary group problem you
>     pointed out, and


> (c) Does not compromise the integrity of the wire
>     boundary design we have not for converting strings

I vote to not compromise the integrity using a strong boundary in the
code I'll propose (Volker's struct).

> Tridge may have more comments once he's up.  You just
> have to weigh all the opinions and if you feel strongly
> enough, write the code and take the chance that the
> may not be accepted in the end.  It's your call.

My call, I rather prefer to see my patch reject and being told WONTFIX
than not trying to enhance our code at all.

But if WONTFIX will be the answer I will like to raise the question of
being more radical than what we are wrt support of non utf8 charset as
pointed out in the answer to Jeremy.


Simo Sorce
Samba Team GPL Compliance Officer
email: idra at

More information about the samba-technical mailing list