This URL is LOOOOONNNGG. Maybe we can think of ways to shorten it in the config files. (We don't need to do that in this PR). But IIRC the URL is slightly error prone because folks might accidentally link to older POSIX standards. (They might have to for some things that were REMOVED from POSIX; not sure what, but I heard that's the case. I will research that more). But I do see a convention like our "functions" have `/functions/` in the URL. Hmm...yeah, let's worry about that in a follow up (not this PR).

Hmm...the current wording makes me think "what C standard or POSIX standard was this first defined in" which is how the man pages project documents these, but NOT what we're doing for docgen. Let's discuss (in this comment thread, before you post changes to wording) some different ways we can make that clearer. Perhaps: - C23 Standard Section - POSIX Docs Would make our intent clearer? Got any other ideas?

So this would trigger if someone adds documentation for foo.h but there's no libc/src/foo/ ? I think that should be ok and we should not diagnose that. That way, documentation can proceed orthogonal to implementation.

I don't see the `src` dir going away any time soon. If this is simply checking for the existence of `libc/src`, consider omitting this check so that we have less code to maintain in docgen.