I get the same 'nan' on three SL 7.9 computers, but it works ok on a 
CentOS 7.9 machine.  Here is an excerpt from 'rpm -qi coreutils' on 
CentOS 7.9:

Source RPM  : coreutils-8.22-24.el7_9.2.src.rpm
Build Date  : Mon 16 Nov 2020 02:24:59 PM PST
Build Host  : x86-01.bsys.centos.org

and here is the same from SL 7.9:

Source RPM  : coreutils-8.22-24.el7_9.2.src.rpm
Build Date  : Tue 10 Nov 2020 09:07:17 AM PST
Build Host  : sl7.fnal.gov


Steven Yellin

On Wed, 10 Feb 2021, ~Stack~ wrote:

> Greetings,
>
> Curious if anyone else can replicate this. I initially saw this in a certain 
> upstream vendor 7.9, but I'm having issues replicating it and it's only in a 
> certain environment (virtual and I've done strange and awful things to that 
> as I've been trying to understand an unrelated project). However, I was 
> trying to figure out if it was other places as well. Sure enough, I can 
> replicate it on every single one of my SL 7.9 instances that I've tested.
>
> The short, numfmt should not return 'nan' when passed a zero.
>
> $ echo 0 | numfmt
> nan
> $ rpm -q coreutils
> coreutils-8.22-24.el7_9.2.x86_64
>
> If I try on any other distro (Ubuntu/Debian/CentOS 8), it returns 0 as it 
> should.
>
> $ echo 0 | numfmt
> 0
> $ rpm -q coreutils
> coreutils-8.30-8.el8.x86_64
>
> I may not be able to replicate it as reliably as I would prefer on upstream 
> vendor, but every single SL 7.9 system I've tried has had 
> coreutils-8.22-24.el7_9.2.x86_64 and incorrectly returns 'nan'.
>
> I'm hoping the devs can confirm and/or offer suggestions.
>
> Thanks!
> ~Stack~
>