This supposed to be a "minimal" fix of #546 , in that it fixes the printing of literals > 2^31-1 in fortran modes by adding the float suffix. It does not change the C mode, nor introduce any user-configurable parameter to choose a value.
There are two more differences w.r.t master, so in some sense it is not an entirely "minimal" fix. Maybe someone has some comments:
In fortran90 mode, the master branch adds a "." unconditionally, also to integers < 2^31-1. This PR doesn't do this, it prints them in the same way as fortran mode.
The (undocumented) pfortran mode does not work properly in the master branch: it doesn't print the ((one*integer)/integer) format in all cases ("test32" in the test case, for eg).
Additionally, note that in 32bit FORM, the master branch starts adding floating suffixes at 2^15-1 (and this PR at 2^16-1).
coverage: 50.323% (+0.1%) from 50.227%
when pulling f3a730f140c2ad71f9861f196316663e9449d26f on jodavies:issue-546
into 0289435fc48b3ae379c4c1fc8058de7f844dd08a on vermaseren:master.
This supposed to be a "minimal" fix of #546 , in that it fixes the printing of literals
> 2^31-1
in fortran modes by adding the float suffix. It does not change the C mode, nor introduce any user-configurable parameter to choose a value.There are two more differences w.r.t master, so in some sense it is not an entirely "minimal" fix. Maybe someone has some comments:
fortran90
mode, the master branch adds a "." unconditionally, also to integers< 2^31-1
. This PR doesn't do this, it prints them in the same way asfortran
mode.pfortran
mode does not work properly in the master branch: it doesn't print the((one*integer)/integer)
format in all cases ("test32" in the test case, for eg).Additionally, note that in 32bit FORM, the master branch starts adding floating suffixes at
2^15-1
(and this PR at2^16-1
).