i'm not sure a lot of the text in getpagesize.2 is very helpful? for example:
Portable applications should employ sysconf(_SC_PAGESIZE) instead
of getpagesize():
#include <unistd.h>
long sz = sysconf(_SC_PAGESIZE);
(Most systems allow the synonym _SC_PAGE_SIZE for _SC_PAGESIZE.)
is this a good recommendation _unless_ you've found yourself on a
system that doesn't have getpagesize()? on Android i'm advising
getpagesize() because it's (a) attribute const and (b) inherently
cheaper than sysconf(). (though obviously, "if it really matters,
stick it in a static".)
afaict the only motivation for the "portable applications" advice is
that HP-UX removed getpagesize() at some point? but given that HP-UX
has been kept "alive" in an artificial coma since 2007... does anyone
writing code in 2024 need to worry about that enough for this to be
good advice?
getpagesize() is available on Android, *BSD, iOS/macOS, glibc/musl,
and even mingw!
Whether getpagesize() is present as a Linux system call depends
on the architecture. If it is, it returns the kernel symbol
PAGE_SIZE, whose value depends on the architecture and machine
model. Generally, one uses binaries that are dependent on the
architecture but not on the machine model, in order to have a
single binary distribution per architecture. This means that a
user program should not find PAGE_SIZE at compile time from a
header file, but use an actual system call, at least for those
architectures (like sun4) where this dependency exists.
should this just say alpha, sparc32, and sparc64 instead of being
vague? (i suspect anyone who doesn't default to searching the kernel
source would turn to the man pages to answer the "which
architectures?" question :-) though i'm not sure why anyone who
doesn't read the kernel source would care whether getpagesize() should
really be in man2 or man3...)
glibc 2.0 fails because its getpagesize() returns a statically
derived value, and does not use a system call. Things are OK in
glibc 2.1.
1997 called, and wondered whether we're helping anyone by documenting
a bug that's been fixed longer than several folks on my team have been
alive? :-)
