On 14/06/2020 13:47, Tobias Stoeckmann wrote:
> Since -LONG_MIN results in LONG_MIN again, the operation itself is
> a signed integer overflow.
> 
> This can be observed with the following calls (best if compiled
> with -ftrapv or -fsanitize=undefined):
> 
> $ numfmt --padding=-9223372036854775808
> $ seq 1e-9223372036854775808
> 
> Technically, the change in seq "reduces" the precision, but a double
> or long double that small would be represented as 0 anyway.

Thanks for fixing those -fsanitize=undefined issues.

I can confirm with GCC 10 -fsanitize=undefined was giving:

   src/numfmt.c:1505:31: runtime error:
   negation of -9223372036854775808 cannot be represented in type 'long int'

How did you notice BTW. This wasn't exposed in existing tests.
I've updated your patch (attached) to add tests for this.

cheers,
Pádraig