Catch up with all the lint warnings since exit on warning was disabled.
Disable 'missing header declaration' and 'nested extern' warnings for now.

PR lib/54053

When auto scaling, and the buffer is bigger than big enough
for the biggest possible number, don't try and calculate
the max value that will fit in the buffer - that calc
will overflow (guaranteed) and is useless, the value
we're formatting cannot possibly be bigger. So simply
use the unscaled value (the raw number).

While here, also avoid returning values that are larger
than the buffer len ... while it would be nice to be able
to find out how big the buffer should be so the data will
fit, the interface doesn't really allow that (the buffer
length passed in controls the scaling - at least when
auto scaling) and the code already does "return -1" when
it detects the buffer length is too small, even before
it works out how much would have been needed. So, rather
than returning a value > len (while truncating the result
to fit in len ... all courtesy of snprintf()) return -1
in this case as well.

Also, allow suffix==NULL (meaning "") - there's no reason
not to, and requiring users to pass in an explicit "" is
not useful.

branches: 1.17.12;
Fix out of bounds read for very large numbers (pointed out by Brooks Davis)
https://svnweb.freebsd.org/changeset/base/316766

branches: 1.16.14; 1.16.18;
PR/44097: Yamamoto Takashi: Prevent overflow.

PR/45989: Martin Husemann: lint invocation does include -w only on i386

- turn lint -w for all the platforms after fixing the lint warnings.
- add _DIAGASSERTS() for casts that would assign values to types that
would not fit.
- change types, add casts
- change into ansii prototypes
- turn on _DIAGNOSTIC for libc (during current, to be eliminated for release
builds)

approved by core@

branches: 1.14.4; 1.14.8; 1.14.24;
Remove clause 3 and 4 from TNF licenses

branches: 1.13.4;
- add dehumanize_number
- decls for humanize_number and dehumanize_number are in stdlib.h

branches: 1.12.4;
Fix a bug that humanize_number() produces "1000" where it should be "1.0G"
or "1.0M". The bug reported by Greg Troxel.

branches: 1.11.4; 1.11.6;
Use PRId64 instead of a cast to long long and %lld to print an int64_t.

compat core reorg.

A little libc namespace housekeeping exercise:
* Make vfprintf_unlocked() an internal function, c.f. __svfscanf_unlocked().
* Add internal names for arc4random(), endnetpath(), fhstatvfs(),
fstatvfs(), mkstemp(), shquote(), statvfs(), taddr2uaddr(), uaddr2taddr(),
uuid_create_nil(), uuid_is_nil(), and wcwidth().
* Include namespace.h where supposed to.

- Honor the HN_NOSPACE flag (i.e., don't put a space if specified,
and put space if not specified).
- There was a test which didn't count the suffixlen. Fix it.
- Make the code a bit easier to read.

Print 10450000 as 10M instead of 10.0M (more greater value such as
10500000 is printed as 10M).

No need to set divisor twice.

Don't ever add a ".0" to a single digit number.

XXX: Should (for example) 1024 be 1.0K or 1K when the HN_DECIMAL flag
is passed? Should there be a separate option that says "use the
HN_DECIMAL behaviour unless we are exactly equal to the suffix"?

Fix signed/unsigned comparison warnings.

SI prefixes apply to decimal multiplies only. For binary (2^n) multiplies
the most "officially looking" is IEC 60027-2, ie "Ki", "Mi", ...,
which is not too popular, and which would require more code changes.
So stick with the traditional capital "K" for (divisor==1024), and use
the SI "k" otherwise (ie (divisor==1000)).

Kilo abbreviation is a small k (PR 18408).

branches: 1.1.2;
Move humanize_number(3) from libutil to libc as per discussion on tech-misc
Revert minor number bump on libutil (with note to skip it next update), and
bump libc.

PR lib/54053

When auto scaling, and the buffer is bigger than big enough
for the biggest possible number, don't try and calculate
the max value that will fit in the buffer - that calc
will overflow (guaranteed) and is useless, the value
we're formatting cannot possibly be bigger. So simply
use the unscaled value (the raw number).

While here, also avoid returning values that are larger
than the buffer len ... while it would be nice to be able
to find out how big the buffer should be so the data will
fit, the interface doesn't really allow that (the buffer
length passed in controls the scaling - at least when
auto scaling) and the code already does "return -1" when
it detects the buffer length is too small, even before
it works out how much would have been needed. So, rather
than returning a value > len (while truncating the result
to fit in len ... all courtesy of snprintf()) return -1
in this case as well.

Also, allow suffix==NULL (meaning "") - there's no reason
not to, and requiring users to pass in an explicit "" is
not useful.

Fix out of bounds read for very large numbers (pointed out by Brooks Davis)
https://svnweb.freebsd.org/changeset/base/316766

branches: 1.16.14; 1.16.18;
PR/44097: Yamamoto Takashi: Prevent overflow.

PR/45989: Martin Husemann: lint invocation does include -w only on i386

- turn lint -w for all the platforms after fixing the lint warnings.
- add _DIAGASSERTS() for casts that would assign values to types that
would not fit.
- change types, add casts
- change into ansii prototypes
- turn on _DIAGNOSTIC for libc (during current, to be eliminated for release
builds)

approved by core@

branches: 1.14.4; 1.14.8; 1.14.24;
Remove clause 3 and 4 from TNF licenses

branches: 1.13.4;
- add dehumanize_number
- decls for humanize_number and dehumanize_number are in stdlib.h

branches: 1.12.4;
Fix a bug that humanize_number() produces "1000" where it should be "1.0G"
or "1.0M". The bug reported by Greg Troxel.

branches: 1.11.4; 1.11.6;
Use PRId64 instead of a cast to long long and %lld to print an int64_t.

compat core reorg.

A little libc namespace housekeeping exercise:
* Make vfprintf_unlocked() an internal function, c.f. __svfscanf_unlocked().
* Add internal names for arc4random(), endnetpath(), fhstatvfs(),
fstatvfs(), mkstemp(), shquote(), statvfs(), taddr2uaddr(), uaddr2taddr(),
uuid_create_nil(), uuid_is_nil(), and wcwidth().
* Include namespace.h where supposed to.

- Honor the HN_NOSPACE flag (i.e., don't put a space if specified,
and put space if not specified).
- There was a test which didn't count the suffixlen. Fix it.
- Make the code a bit easier to read.

Print 10450000 as 10M instead of 10.0M (more greater value such as
10500000 is printed as 10M).

No need to set divisor twice.

Don't ever add a ".0" to a single digit number.

XXX: Should (for example) 1024 be 1.0K or 1K when the HN_DECIMAL flag
is passed? Should there be a separate option that says "use the
HN_DECIMAL behaviour unless we are exactly equal to the suffix"?

Fix signed/unsigned comparison warnings.

SI prefixes apply to decimal multiplies only. For binary (2^n) multiplies
the most "officially looking" is IEC 60027-2, ie "Ki", "Mi", ...,
which is not too popular, and which would require more code changes.
So stick with the traditional capital "K" for (divisor==1024), and use
the SI "k" otherwise (ie (divisor==1000)).

Kilo abbreviation is a small k (PR 18408).

branches: 1.1.2;
Move humanize_number(3) from libutil to libc as per discussion on tech-misc
Revert minor number bump on libutil (with note to skip it next update), and
bump libc.

Fix out of bounds read for very large numbers (pointed out by Brooks Davis)
https://svnweb.freebsd.org/changeset/base/316766

branches: 1.16.14; 1.16.18;
PR/44097: Yamamoto Takashi: Prevent overflow.

PR/45989: Martin Husemann: lint invocation does include -w only on i386

- turn lint -w for all the platforms after fixing the lint warnings.
- add _DIAGASSERTS() for casts that would assign values to types that
would not fit.
- change types, add casts
- change into ansii prototypes
- turn on _DIAGNOSTIC for libc (during current, to be eliminated for release
builds)

approved by core@

branches: 1.14.4; 1.14.8; 1.14.24;
Remove clause 3 and 4 from TNF licenses

branches: 1.13.4;
- add dehumanize_number
- decls for humanize_number and dehumanize_number are in stdlib.h

branches: 1.12.4;
Fix a bug that humanize_number() produces "1000" where it should be "1.0G"
or "1.0M". The bug reported by Greg Troxel.

branches: 1.11.4; 1.11.6;
Use PRId64 instead of a cast to long long and %lld to print an int64_t.

compat core reorg.

A little libc namespace housekeeping exercise:
* Make vfprintf_unlocked() an internal function, c.f. __svfscanf_unlocked().
* Add internal names for arc4random(), endnetpath(), fhstatvfs(),
fstatvfs(), mkstemp(), shquote(), statvfs(), taddr2uaddr(), uaddr2taddr(),
uuid_create_nil(), uuid_is_nil(), and wcwidth().
* Include namespace.h where supposed to.

- Honor the HN_NOSPACE flag (i.e., don't put a space if specified,
and put space if not specified).
- There was a test which didn't count the suffixlen. Fix it.
- Make the code a bit easier to read.

Print 10450000 as 10M instead of 10.0M (more greater value such as
10500000 is printed as 10M).

No need to set divisor twice.

Don't ever add a ".0" to a single digit number.

XXX: Should (for example) 1024 be 1.0K or 1K when the HN_DECIMAL flag
is passed? Should there be a separate option that says "use the
HN_DECIMAL behaviour unless we are exactly equal to the suffix"?

Fix signed/unsigned comparison warnings.

SI prefixes apply to decimal multiplies only. For binary (2^n) multiplies
the most "officially looking" is IEC 60027-2, ie "Ki", "Mi", ...,
which is not too popular, and which would require more code changes.
So stick with the traditional capital "K" for (divisor==1024), and use
the SI "k" otherwise (ie (divisor==1000)).

Kilo abbreviation is a small k (PR 18408).

branches: 1.1.2;
Move humanize_number(3) from libutil to libc as per discussion on tech-misc
Revert minor number bump on libutil (with note to skip it next update), and
bump libc.