[Bug 213012] Clarifying what hw.physmem returns

bugzilla-noreply at freebsd.org bugzilla-noreply at freebsd.org
Mon Sep 26 18:41:46 UTC 2016


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=213012

            Bug ID: 213012
           Summary: Clarifying what hw.physmem returns
           Product: Documentation
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Documentation
          Assignee: freebsd-doc at FreeBSD.org
          Reporter: djensen at macsales.com

Apparently at some point FreeBSD changed the variable type returned by
hw.physmem but this has not been documented.  The only documentation I found
for hw.physmem is in conjunction with the sysctl(8) where it says it returns an
integer.  However this not 100% accurate as the actual integer type that
FreeBSD returns when the following command is run:

sysctl hw.physmem

Is uint64_t (or unsigned long long int) and all the documentation I could find
that referenced hw.physmem says it should return an int32_t (signed 32 bit
integer).  Now while it is better to return the uint64_t value this is not what
appears to be the normal standard of what this variable returns.  This
undocumented inconsistency only leads to confusion should someone try to look
up the general documentation concerning the hw.physmem value.

It would be a good idea on the following page:

https://www.freebsd.org/cgi/man.cgi?sysctl(8)

To change at least the following line:

hw.physmem                               integer       no

To the following:

hw.physmem                               uint64_t      no

This would at least clarify exactly what this sysctl will be returning if the
command above is run.  I am assuming if one does not give the return value an
integer of the appropriate size that there is possibility that it would exceed
the maximum value allowable whenever RAM exceeds 2.15 GB

Personally I think all the variables listed on that page should have their
"exact" variable type listed rather than a generic variable type or at least a
reference of what variable types it may return if the return type is dynamic in
some way.

-- 
You are receiving this mail because:
You are the assignee for the bug.


More information about the freebsd-doc mailing list