On Tue, 06 Oct 2009, Bisz István wrote:
Hi,
> I found a quite strange behavior in some CP settings necessary in my
> project.
> See the following sample:
> CODE
> proc main()
> set alternate to uperr.txt additive
> set alternate on
> REQUEST HB_CODEPAGE_TR857
> HB_SETCODEPAGE( "TR857" )
> ? "diag=diag", UPPER("diag=diag")
> ? "diag", UPPER("diag")
> return
> ENDCODE
> generating the wrong output:
> diag=diag DAG=DAG
> diag DIAG
It's Clipper compatible behavior in UPPER() optimization.
Clipper optimize UPPER( <cConst> ) at compile time if <cConst>
contains only characters like [A-Za-z0-9 ] and as result if
gives <cUpperConst> where characters like [a-z] are converted
to [A-Z]. During compilation CP is unknown so only such strings
are translated and only pure Latin letters.
In Harbour Clipper behavior is fully replicated because
some code which initialize static variables needs it, i.e.:
static s := upper( "diag" )
Unfortunately it creates problems for Turkish CPs where upper("i")
is not "I" but due to compile time optimization it's wrongly
translated to "I".
In your example first string contains "=" character what disables
compile time UPPER() optimization so it's correctly translated at
runtime but the second string is fully optimized.
The only one solution I can give you is not using UPPER() with
string constant values containing Turkish strings. Maybe in the
future I'll add new -k? switch to disable UPPER() optimization
but I cannot make it in default builds due to compatibility with
existing code. If it's critical for you now then you can disable
UPPER() optimization in Harbour compiler code and recompile your
custom Harbour version.
best regards,
Przemek
_______________________________________________
Harbour mailing list
Harbour@harbour-project.org
http://lists.harbour-project.org/mailman/listinfo/harbour
