Manpages, the gift that keeps on giving

14 Apr, 2026

I was reading man pages the other day¹ when I stumbled upon this, and my initial reaction was how egregiously wrong it was, how did it even end up there?

fread(3)                         Library Functions Manual                        fread(3)

NAME
     fread, fwrite - binary stream input/output

LIBRARY
     Standard C library (libc, -lc)

SYNOPSIS
     #include <stdio.h>

     size_t fread(size_t size, size_t n;
                  void ptr[restrict size * n],
                  size_t size, size_t n,
                  FILE *restrict stream);
     size_t fwrite(size_t size, size_t n;
                  const void ptr[restrict size * n],
                  size_t size, size_t n,
                  FILE *restrict stream);

If you squint your eyes you might notice that both fread and fwrite have few too many arguments, and... a semicolon in the middle of them? What?

After stumbling around a little bit, trying to figure out where are my man pages coming from, I found the source - kernel man pages, which made me furrow my brow even harder!

Cloning the repo and searching for the guilty commit led me to this one:

commit d2c2db8830f8fcbb736bdea52b398257447bef6b
Author: Alejandro Colomar <alx@kernel.org>
Date:   2025-03-14 18:33:41 +0100

    man/: SYNOPSIS: Use GNU forward-declarations of parameters for sizes of array parameters

    This syntax has been proposed for standardization in N3433.

    Link: <https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3433.pdf>

So, apparently it's not a mistake, it just looks like one.

Ubuntu's man pages have a different take on it, and even if I don't expect it to compile², the knee-jerk reaction most probably wouldn't be "what in tarnation".

    size_t fread(void ptr[restrict .size * .nmemb],
                size_t size, size_t nmemb,
                FILE *restrict stream);
    size_t fwrite(const void ptr[restrict .size * .nmemb],
                size_t size, size_t nmemb,
                FILE *restrict stream);

To the untrained eye the proposed syntax might look like a mistake rather than a clarification, which begs the question, how useful is it really?

But I guess exposure to strange things over time might help with just about anything.

After all, beginner programmers might find everything odd about programming, but given some time and opportunity to grow, not even things like [2]array = 5 will faze them.

Moral of the story: temper your initial reactions, you might learn more by listening than by writing things off as foolish.