Floating point fractions must have leading zero, or wrong answer

Bugzilla Link	1196
Created on	Jun 26, 2017 15:49
Version	svn
OS	Linux
Architecture	PC
Attachments	0001-Fixes-1196.patch

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).