[Issue 110857] unexpected differences in application char vs basic chr functions

[bu...@apache.org]

https://bz.apache.org/ooo/show_bug.cgi?id=110857

damjan@apache.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Latest|---                         |4.2.0-dev
    Confirmation in|                            |
                 CC|                            |damjan@apache.org
         Resolution|---                         |NOT_AN_ISSUE
                 OS|Windows, all                |All
             Status|CONFIRMED                   |RESOLVED
           Hardware|Other                       |All

--- Comment #2 from damjan@apache.org ---
The CHAR function in Calc:

void ScInterpreter::ScChar()
{
    RTL_LOGFILE_CONTEXT_AUTHOR( aLogger, "sc", "er", "ScInterpreter::ScChar" );
//2do: make it full range unicode?
    double fVal = GetDouble();
    if (fVal < 0.0 || fVal >= 256.0)
        PushIllegalArgument();
    else
    {
        String aStr( '0' );
        aStr.SetChar( 0, ByteString::ConvertToUnicode( (sal_Char) fVal,
gsl_getSystemTextEncoding() ) );
        PushString( aStr );
    }
}


The Chr function in Basic:

RTLFUNC(Chr)
{
    (void)pBasic;
    (void)bWrite;

        bool bChrW = false;
        implChr( rPar, bChrW );
}

void implChr( SbxArray& rPar, bool bChrW )
{
        if ( rPar.Count() < 2 )
                StarBASIC::Error( SbERR_BAD_ARGUMENT );
        else
        {
                SbxVariableRef pArg = rPar.Get( 1 );

                String aStr;
                if( !bChrW && SbiRuntime::isVBAEnabled() )
                {
                        sal_Char c = (sal_Char)pArg->GetByte();
                        ByteString s( c );
                        aStr = String( s, gsl_getSystemTextEncoding() );
                }
                else
                {
                        sal_Unicode aCh = (sal_Unicode)pArg->GetUShort();
                        aStr = String( aCh );
                }
                rPar.Get(0)->PutString( aStr );
        }
}

So Basic uses the full unicode range, Calc uses a system text enconding.

Calc should follow ODFF for Char() which states:


--snip--
6.20.3CHAR

Summary: Return character represented by the given numeric value

Syntax: CHAR( Number N )

Returns: Text

Constraints: N <= 127; Evaluators may evaluate expressions where N >= 1, N <=
255.

Semantics:

Returns character represented by the given numeric value.

Evaluators should return an Error if N > 255.

Evaluators should implement CHAR such that CODE(CHAR(N)) returns N for any 1 <=
N <= 255.

Note 1: Beyond 127, some evaluators return a character from a system-specific
code page, while others return the [UNICODE] character. Most evaluators do not
allow values greater than 255.

Note 2: Where interoperability is a concern, expressions should use the UNICHAR
function. 6.20.25

See also CODE 6.20.5, UNICHAR 6.20.25, UNICODE 6.20.26
--snip--



We fail the case where CODE(CHAR(N)) = N for any 1 <= N <= 255, as our
CODE(CHAR(N)) returns 0 for N > 127, but it's only a *should*. We are allowed
to return a character from a system-specific code page as per Note 1. Also as
per Note 2 UNICHAR should be used when interoperability is a concern, and
UNICHAR's output matches Basic's Chr().

Resolving NOT_AN_ISSUE.

-- 
You are receiving this mail because:
You are on the CC list for the issue.
You are the assignee for the issue.