[omniORB] bug in CORBA::Fixed constructor

[Duncan Grisby]

On Thursday 14 December, "Luke Deller" wrote:

> In omniORB (v4.1), the CORBA::Fixed constructor skips leading and
> trailing zeros when constructing a fixed-point value from a string.
> This behaviour also affects omniORBpy:
> 
> >>> CORBA.fixed('0123d').precision() # should be 4
> 3
> >>> CORBA.fixed('12.340d').decimals() # should be 3
> 2
> 
> The code in corbaFixed.cc seems to do this quite deliberately, but I
> think it is wrong:

The thing is, that despite the name, CORBA::Fixed in C++ and CORBA.fixed
in Python are actually decimal floating point. It doesn't make any sense
to maintain leading and trailing zeros in a floating point number. How
would the precision and decimals behave during arithmetic if leading and
trailing zeros were maintained?  The supposed rules in the IDL
specification don't actually say what to do, only state the obvious
about what the maximum digits and scale values can be.

In C++, you get specific types generated for fixed declarations in IDL,
and they do maintain the digits and scale they are declared to have
(although that's optional according to the C++ mapping). The Python
mapping doesn't have equivalent generated types.

> Both the C++ and Python language mappings describe this string argument
> with the phrase "the string representation of a fixed-point literal".
> The CORBA specification (v2.6, sec 3.9.2) gives specific examples of
> fixed-point literals, illustrating that leading and trailing zeroes are
> significant.

I think that bit of the spec is inconsistent with the other parts that
describe how fixed literals get involved in arithmetic, and with the
details of the language mappings. Fixed point is generally very badly
specified in all the CORBA specs.



-- 
 -- Duncan Grisby         --
  -- duncan at grisby.org     --
   -- http://www.grisby.org --