> On 16. Jun 2020, at 22:30, Joerg Jung <m...@umaxx.net> wrote:
>
>
>> On 16. Jun 2020, at 20:53, Mattias Andrée <maand...@kth.se> wrote:
>>
>> I'm assuming temp.value i an `int`, as %d is used. The problem was
>> probably that `1E6` is actually a `double` rather than an `int`,
>> as the whole expression is promoted to `double`, because `bprintf` is
>> (I assume) variadic, and the compiler does not know to change the
>> cast the expression back to `int` because only the type of the first
>> argument is specified in its declaration.
>
> Yes, you are likely right and with the %d "rounding” one even seems to
> loose the precision.
> That’s why %.1f for example would probably a better choice here
...or one could just use the same “calculation” as for FreeBSD a few lines
below.
> , as there is a subtle difference between 94.1 and 94.9 degree one may
> want to know.
>
>> On Tue, 16 Jun 2020 20:42:08 +0200
>> Laslo Hunhold <d...@frign.de> wrote:
>>
>>> On Tue, 16 Jun 2020 17:55:03 +0000
>>> messw1thdbest <messw1thdb...@protonmail.ch> wrote:
>>>
>>> Dear messw1thdbest,
>>>
>>>> < return bprintf("%d", (temp.value - 273150000) / 1E6);
>>>> ---
>>>>> return bprintf("%d", (temp.value - 273150000)/1000000);
>>>
>>> I'm really intrigued by that; thanks for sending in this patch! What is
>>> the origin of this problem? Does this have something to do with
>>> guaranteed constant-sizes in Posix?
>>>
>>> With best regards
>>>
>>> Laslo Hunhold
>>>
>>
>>
>
