[PATCH 04/10] system_data_types.7: Add float_t

[Alejandro Colomar]

Hi Michael,

On 2020-09-25 10:13, Michael Kerrisk (man-pages) wrote:
> Hi Alex,
> 
> A few comments here that also apply for the double_t patch.
> Could you revise please?
> 
> On 9/25/20 9:31 AM, Alejandro Colomar wrote:
>> +The implementation's most efficient floating type at least as wide as
>> +.IR float .
> 
> The C standard is rather terse here. Perhaps we could make the
> reader's life a little easier. How about something like:
> 
> [[
> This a type that is intended to be the implementation's
> most efficient floating type that is at least as wide as
> .IR float .
> ]]

I removed the "intended" part to simplify it a bit. Do you prefer to 
keep it?

> 
>> +Its type depends on the value of the macro
>> +.BR FLT_EVAL_METHOD :
>> +.RS
>> +.IP *
>> +0;
>> +.I float_t
>> +is
>> +.IR float .
>> +.IP *
>> +1;
>> +.I float_t
>> +is
>> +.IR double .
>> +.IP *
>> +2;
>> +.I float_t
>> +is
>> +.IR "long double" .
>> +.IP *
>> +Other implementation-defined values.
>> +.RE
> 
> I think we can format this better as a hanging list.
> Something like this:
> 
> [[
> .TP
> 0
> .I float_t
> is
> .IR float .
> .TP
> 1
> .I float_t
> is
> .IR double .
> .TP
> 2
> .I float_t
> is
> .IR "long double" .
> .IP
> For other values of
> .BR FLT_EVAL_METHOD ,
> the type of
> .I float_t
> is implementation-defined.
> ]
Yes, I wasn't convinced by my formatting.  Thanks!

I'll fix this patch, and the srcfix that depends on this too.

BTW, I'll also add a note that FLT_EVAL_METHOD is defined in <float.h>
Would you add that to "Notes", or as part of the description?

> 
>> +.IP
>> +Conforming to: C99 and later; POSIX.1-2001 and later.
>> +.IP
>> +See also the
>> +.I double_t
>> +type in this page.
>>   .\"------------------------------------- gid_t ------------------------/
>>   .TP
>>   .I gid_t
> 
> Thanks,
> 
> Michael
> 
> 
Thanks,

Alex