On Tue, Mar 26, 2024 at 4:20 PM Alejandro Colomar <alx@xxxxxxxxxx> wrote: > > Hi Elliott! > > On Tue, Mar 26, 2024 at 03:27:27PM -0700, enh wrote: > > 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? > > I hope not. It's dead, AFAIC. > > > 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 > > Yep, I'd appreciate that, after the current text (not replacing it). > > > 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? :-) > > Agree. > > Do you intend to send patches? Otherwise, let me know, and I'll prepare > something. i can do, but it also sounds like enough of a bikeshed that i imagine you'd only want to rewrite it again anyway :-) (i was actually surprised how many references to glibc 2.0 there are in various man pages, and even more amused by references to "ancient versions of glibc" being defined as "before glibc 2.0", as if 1997 isn't ancient :-) ) > Have a lovely night! > Alex > > -- > <https://www.alejandro-colomar.es/> > Looking for a remote C programming job at the moment.
