Force E in output specifiers when writing |exp|>99 numbers

[zerothi]

Currently the standard says that any value writing with exponents |exp|>99 shall be written:

(sec. 10.6.1.2.2 of Fortran 03 standard)

99 < |exp| < 1000 +-z1z2z3

This is just horrible.

Basically all parsers of fortran output needs to have a check whether the exponent (currently D or E) are in the field, or whether there is a +- between numbers to figure out if it is an exponent.

I would propose that exponent specifiers are always written.

Note Gfortran is currently standard conforming and will not write the exponent when |exp| > 99... :(

For readers, the only work-around for consistent writing of E is a format like this:

?w.dE3

with w=d+8 for full details. This has the side-effect of writing lots of zeros for small numbers, but at least you'll consistently get an easy parseable number...

This was also pointed out in #226:

...
While you're at this, consider also deprecating or deleting 0.10+009 (with no E or D) as a conforming option for the output of (Ew.d) (no Ee). I can't find an implementation that emits it, and it may be an truly dead aspect of the language.

Originally posted by @klausler in #226 (comment)

For reference, here is a test code:

program test

  integer, parameter :: dp = 8
  real(dp) :: v = 1.23456789123456789123456789e-123_dp

  write(*,'("|",G24.16,"|")') v
  write(*,'("|",E24.16,"|")') v
  write(*,'("|",G24.16E3,"|")') v
  write(*,'("|",E24.16E3,"|")') v
  write(*,'("|",G24.16,"|")') -v
  write(*,'("|",E24.16,"|")') -v
  write(*,'("|",G24.16E3,"|")') -v
  write(*,'("|",E24.16E3,"|")') -v

end program

Gfortran 12.3 gives this output:

|  0.1234567891234568-122|
|  0.1234567891234568-122|
| 0.1234567891234568E-122|
| 0.1234567891234568E-122|
| -0.1234567891234568-122|
| -0.1234567891234568-122|
|-0.1234567891234568E-122|
|-0.1234567891234568E-122|

[certik]

@zerothi it seems we should fix this and always print E in there. Does anyone know the historical motivation for this behavior?

[zerothi]

Yes, this would be really great to fix, implementing parsers for this numbering is horrible for basically any language...

The only historical meaning I could see is the saving of a letter in output. So a size thing...