Mac OS X - compilation experiences and issues

[Jeremy Allison]

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.