getconf outputs -1 for ULLONG_MAX (and ULONG_MAX on amd64), which seems strange. Another implementation that I checked outputs 18446744073709551615 like it should. Fix: Patch attached. It creates a couple of compiler warnings but fixes the problem, maybe there is a better way to do it. Patch attached with submission follows: How-To-Repeat: getconf ULLONG_MAX
Responsible Changed From-To: freebsd-standards->eadler I'll take a look at the affected code. We don't allow compiler warnings in our code (except for very good reason) but this could likely be fixed correctly :)
Responsible Changed From-To: eadler->freebsd-bugs I won't be dealing with this PR for some time, so give it back to the pool
Responsible Changed From-To: freebsd-bugs->freebsd-standards Canonicalize assignment.
Breaks PMDK test, would be nice to fix this after six years.
A commit references this bug: Author: wollman Date: Wed May 23 02:51:58 UTC 2018 New revision: 334070 URL: https://svnweb.freebsd.org/changeset/base/334070 Log: Move unsigned limits to a separate table/recognizer and display them using the appropriate (unsigned) format specification. This prevents integer overflow when ULLONG_MAX and (on some architectures) ULONG_MAX are used to initialize an intmax_t and then displayed as the signed value -1. (A different approach was suggested in the bug report, which I did not use.) If other limits are defined to be unsigned, they could be moved here. PR: 164049 Reported by: Marcus Reid Changes: head/usr.bin/getconf/Makefile head/usr.bin/getconf/getconf.c head/usr.bin/getconf/getconf.h head/usr.bin/getconf/limits.gperf
A commit references this bug: Author: wollman Date: Wed May 23 02:54:28 UTC 2018 New revision: 334071 URL: https://svnweb.freebsd.org/changeset/base/334071 Log: Whoops, forgot to add this file in r334070. PR: 164049 Changes: head/usr.bin/getconf/unsigned_limits.gperf
This bug affects every release that has ever had support for ULLONG_MAX in getconf(1), maybe every release ever (I haven't dug through the history enough to see).