[Fribidi-discuss] (Justified?) compilation warning

[Shachar Shemesh]

I am now officially confused. Sorry. Read on for details.

Behdad Esfahbod wrote:

> I wrote:

>>       3. Support all encoding lengths using the same code - The 
>>suggestion was already made. Use a preprocessor to mark the character 
>>begining and end, and have the reordering code work on a byte by byte basis.
>>    
>>
>
>I don't like the idea of having different binaries for different 
>encodings, niether I like the idea of having FriBidiChar type of 
>different sizes on unices.  So I will stick to the third 
>solution, which the same code & same binary will support all 
>Unicode encodings (say UTF-8, UTF-16, and UTF-32).
>
That option is one you brought up, where the preprocessor that also does 
the typing for characters, will also mark character endings. This way, 
the same byte level code can do the reordering, as it has out of bounds 
info on where each character ends.

>  About the 
>interface, I've found some reasonable way to implement it.  We 
>will have three different versions of each function, ending with 
>1, 2, and 4.  And a macro definition which *selects* which one 
>to call.
>
The question is not one of interface (the interface you suggest is the 
same used for Win32 Ansi vs. Unicode functions, BTW). The question is 
how many compiled versions of the code we are going to have (no way I am 
going to promote having more than one source version, BTW).

>  I've attached an example code, but it generates 
>warnings that I can't get rid of.
>
No, you didn't.

>  Any alternative solutions is 
>welcome (I'm wondering if I should use 1, 2, 4, or 8, 16, 32.)
>
Let's see the code.

>
>Another question is about fribidi types.  IMHO FriBidiChar should 
>remain 32bits.  I don't like different size of types on different 
>machines.
>
I don't think it should be machine dependant. If we are dealing with the 
types on a byte by byte basis, and having out of bounds info on 
character beginings and ends, FriBidiChar should be byte. If we have 
several versions of the compiled code, each one should have its own 
FriBidiChar type.

>  Another solution is to have FriBidiChar1, 
>FriBidiChar2, and FriBidiChar4, and define FriBidiChar to point 
>to one of them based on defined symbols, but I don't like it.
>
I don't see any way around it if you are goind to have log2vis8, 
log2vis16 and log2vis32.

>
>Ok, That's enough for now.  Let me know what you think.
>  
>

I think I'll wait for that attachment.

            Shachar