Re: [patch] PR93727 Fortran 2018: EX edit descriptor

Hi Jerry!

On 2/2/26 22:42, Jerry D wrote:
> On 2/2/26 12:28 PM, Harald Anlauf wrote:
>> Hi Jerry!
>>
> --- snip ---
>> Let's see:
>>
>> 13.7.2.3.6 EX editing
>>
>> The EXw.d and EXw.dEe edit descriptors indicate that the external field
>> occupies w positions, except when w is zero in which case the processor
>> selects the field width. The fractional part of the field contains d
>> hexadecimal digits, except when d is zero in which case the processor
>> selects the number of hexadecimal digits to be the minimum required so
>> that the output field is equal to the internal value; ...
>>
>> But -0XF.FFFFFP+124 is shorter than -0X1.FFFFFEP+127, so I think
>> you should recheck.  Sorry for the extra work ;-)
>>
>>>
> 
> I am very aware of this. My interpretation is "in which case the processor
> selects" the number of hexadecimal digits to be what ever minimum it 
> chooses
> to produce. Keep in mind this is using the built-in C functions to generate
> the hex string so we do not have a bit string to deal with. The value is 
> correct and it is the minimum the processor produces.
> 
> Anyone else one to way in on this? I sure don't want to create custom 
> code bit shift this.

Not sure if C is really a good reference.
printf takes a double when one wants to pass a float.
With 53 bits for a double with the leading one implicitly set
one could be biased towards a leading 1 before the decimal point.

#include <stdio.h>
#include <values.h>

int
main()
{
   printf ("%A\n", -FLT_MAX);
   printf ("%A\n",-0X1.FFFFFEP+127);
   printf ("%A\n", -0XF.FFFFFP+124);
}

-0X1.FFFFFEP+127
-0X1.FFFFFEP+127
-0X1.FFFFFEP+127

And Fortran does it better (shorter)... ;-)

Harald