BUG: dict.lookupOrDefault<label> throws FATAL IO Error for E-notation number dict entry, but not for the same default value
Summary
Say the following functionObject
exists with two optional
entries which accept label
types as input:
functions
{
iAmFunctionObject
{
...
aSmallInteger -1e9;
aLargeInteger 1e9;
}
The label
objects, i.e. aSmallInteger
and aLargeInteger
, are initialised in iAmFunctionObject
's constructor via:
iAmIntegerRange_
(
labelRange
(
dict.lookupOrDefault<label>("aSmallInteger", -1),
dict.lookupOrDefault<label>("aLargeInteger", 1e9)
)
),
- When these optional entries are not present under
controlDict\functions\iAmFunctionObject
: No FATAL IO ERROR occurs. - When such an optional entry is present under
controlDict\functions\iAmFunctionObject
: The following is thrown:
--> FOAM FATAL IO ERROR:
Wrong token type - expected label (int32), found on line 59: double 1000000000
Steps to reproduce
I can only provide a Minimal Working Example after the completion of the relevant functionObject, I am afraid.
What is NOT the bug?
The following does not throw an IO Error:
functions
{
iAmFunctionObject
{
...
aSmallInteger -1000000000;
aLargeInteger 1000000000;
}
What is the expected correct behavior?
- IMHO, this behaviour is inconsistent (yet might not be important as well) since one can input
1e9
aslabel
when the object is default initialised; (that isdict.lookupOrDefault<label>("aLargeInteger", 1e9)
), but not through a dictionary entry. - In addition, a user might expect for that any E-notation without a decimal point, e.g.
1e4
or-5e8
, the type deduction will belabel
rather thanscalar
. However, it is also legitimate to throw such type deduction error for E-notations with decimal points, e.g.1.0e4
or1.3e4
.
Environment information
OpenFOAM version : v1812
Operating system : openSUSE
Compiler : gcc