From: enh <enh@google.com>
To: linux-man <linux-man@vger.kernel.org>,
"Alejandro Colomar (man-pages)" <alx.manpages@gmail.com>
Subject: getpagesize.2
Date: Tue, 26 Mar 2024 15:55:04 -0700 [thread overview]
Message-ID: <CAJgzZorzr7u7ShTD-B=_p_rOebo3dzoSbCcuTFMQV488FVoHmA@mail.gmail.com> (raw)
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? :-)
next reply other threads:[~2024-03-26 22:55 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-03-26 22:55 enh [this message]
[not found] <CAJgzZooCY7EV5LZSom08k0wVB2SW3KAk-HL9VMsioxivQB=MeQ@mail.gmail.com>
2024-03-26 23:20 ` getpagesize.2 Alejandro Colomar
2024-03-28 0:20 ` getpagesize.2 enh
2024-03-28 9:11 ` getpagesize.2 Alejandro Colomar
2024-03-30 0:17 ` getpagesize.2 enh
2024-03-30 23:24 ` getpagesize.2 Alejandro Colomar
2024-03-31 21:35 ` getpagesize.2 Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAJgzZorzr7u7ShTD-B=_p_rOebo3dzoSbCcuTFMQV488FVoHmA@mail.gmail.com' \
--to=enh@google.com \
--cc=alx.manpages@gmail.com \
--cc=linux-man@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).