Bug 213012 - Clarifying what hw.physmem returns
Summary: Clarifying what hw.physmem returns
Status: New
Alias: None
Product: Documentation
Classification: Unclassified
Component: Manual Pages (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-09-26 18:41 UTC by Dennis Jensen
Modified: 2018-04-10 19:49 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dennis Jensen 2016-09-26 18:41:46 UTC
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.