Floating point fractions must have leading zero, or wrong answer
Extended Description
The difference in behavior between these two examples seems
very wrong to me.
If it's a bug, it should be fixed. If it's part of the language
definition, the definition is wrong and should be fixed.
cat bugparser.sac
int main()
{
y = 0.0012;
StdIO::print(y);
y = .0012;
StdIO::print(y);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/pwlf$ sac2c bugparser.sac -v1
sac@rattler:~/sac/testsuite/optimizations/pwlf$ a.out; echo $?
Dimension: 0
Shape : < >
0.0012
Dimension: 0
Shape : < >
0
0
sac2c -V
sac2c 1.2-beta-BlackForest-542-g022cd
build-type: DEBUG
built-by: "sac" at 2017-06-25T17:37:57
I think it's a parser bug:
cat bugparser.sac
int main()
{
x = 0.0012;
StdIO::print(x);
y = .0012;
StdIO::print(y);
z = _sub_SxS_( x, y);
StdIO::print(z);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/pwlf$ sac2c bugparser.sac -v1
./bugparser.sac 1 error: All instances of "main" contain type errors
error: line 10 in file ./bugparser.sac:
error: Element types of argument #1 and argument #2 of "_sub_SxS_" should be
error: identical; types found: double{0.0...} and int{0}
compilation failed while Running type inference system, 1 error(s).