> 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, 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
>>
>
>
