Mac OS X - compilation experiences and issues
Jeremy Allison
jra at samba.org
Thu Sep 11 16:23:27 GMT 2003
On Thu, Sep 11, 2003 at 05:15:02PM +0200, Benjamin Riefenstahl wrote:
>
> Due to the fast-path code, the first such decomposed character is not
> composed, which causes severe problems for Windows.
This is an Apple problem - no one else uses decomposed Unicode that
I am aware of.
> I think there are several solutions possible:
>
> a) Disable the fast-path code completely based on a #define/#ifdef. I
> plan to do measurements, to see how much of an effect the code has
> in the first place.
Not in the CVS code. This code was added specifically to fix
performance issues measured by cachegrind. That's why I took
all the trouble to add it.
> b) Disable the fast-path code based on a #define/#ifdef, but only in
> the few functions where that is really needed. This is based on
> the assumption that some or even most of the functions in question
> are used only internally and only some are or even only one are
> involved in the actual creation of the bytes sent out on the wire.
> This has the risk that we get a dissonance, some functions convert
> this way, and some functions convert differently. This may lead to
> bugs in code that isn't explicitly tested (I immediately think of
> wildcard expansion, but there may be other code) or it may cause
> future bugs when functions are used differently than they are now.
>
> c) Change the fast-path code to back up one character between the
> ASCII version and the non-ASCII version, possible wrapped in an
> #ifdef again, to enable this only when needed.
No, I don't think this is a good idea to add to the CVS code. It
took a little while to get it stable as-is.
> Let me know what you think, and in which direction you want to go.
I think it's a problem with the way Apple implemented Unicode,
and they will have to fix it, sorry.
Jeremy.
More information about the samba-technical
mailing list