Extraneous space in auto-width real format

When using auto-width format descriptor for real numbers a leading space is incorrectly added. This does not happen with auto-width integer format.

  real*8:: fvalue = 42.5
  integer:: ivalue = 23

  print 100, fvalue     ! expected 'f0.2=42.50', actual 'f0.2= 42.50'
  100 format('f0.2=',F0.2)

  print 200, ivalue     ! expected and actual 'I0=23'
  200 format('I0=',I0)

This is in FTN95 8.50, used to work in 7.10 but I haven't tried any intermediate releases.

I have made a note that this needs investigation.

This regression has now been fixed for the next release of the DLLs.

Never heard about 0 format.

Couple questions about format

1. What is format like this '(es13.6)' I found on the web?

2. How to read this format with commas xxx,xxx,xxx from Windows DIR

   Total Files Listed: 16 File(s) 719,806,745 bytes 2 Dir(s) 206,787,850,240 bytes free

Dan,

          16 File(s)    719,806,745 bytes
           2 Dir(s)  206,787,850,240 bytes free

To read the above in Fortran could be difficult: FTN95 treats 719,806,745 as 3 values separated by a ','

So to read this you would need to read as characters and parse the numeric value. While EN does modify scientific notation and output as multiple of 1,000 and so groups of 3 digits, it does not insert ','

In FTN95, the business format is used to include commas, but I don't think you can use the business format as an input format.

As to 'Never heard about 0 format', I0 and F0.n have been around since F90, while engineering (EN) and scientific (ES) notation were introduced in F95. G0. and E0. have been introduced since, although more complex.

My understanding is that support for comma ',' is unique to FTN95 and has not been adopted in more recent Fortran.

Thanks, John

Paul,

I've just upgraded to 8.60 - liking the VS2019 plugin but sadly this particular bug still appears to be present. Salflib dll version 12.12.29.8 dated 29/12/2019. Any suggestions on a fix?

Cheers, Alan

I will check this out to see what has gone wrong.

It turns out that the fix was only made to the 64 bit version. Almost all of the library code is common to 32 bits and 64 bits but unfortunately not in this case.

It may be necessary to wait a little while before I can send you a fix.