ok hi so a couple days ago i put out your c is not standard c. and it originally had a section that looked like this (entire section pasted here, since it's now gone from the original post):
\n this one is a posix extension, so not necessarily "standard c", more like "posix c", but it's still a documented incompatibility with a standard: in glibc, `initstate` doesn't return NULL on error, despite posix requiring that it does:// EINVAL: state array less than 8 bytes\nchar *state = initstate(67, (char [1]){}, 1);\nassert(errno == EINVAL); // ok\nassert(state == NULL); // fails, despite posix requiring it to succeedthe man page initstate(3) very unhelpfully first describes the posix behavior in the RETURN VALUE section, as though it's the actual behavior:
Theinitstate() function returns a pointer to the previous state array. On failure, it returns NULL, and errno is set to indicate the error.\nonly at the very bottom in the BUGS section does it say that glibc behaves differently:
According to POSIX,initstate() should return NULL on error. In the glibc implementation, errno is (as specified) set on error, but the function does not return NULL.
however, i just got an email:
\nHi, I read " your c is not standard c" and I think there's a small mistake about initstate() in glibc. Actually that bug was fixed in 2013, but the man page hasn't been updated to remove the bug.
\n...wait, what?
\ni tried running the code snippet that i wrote for the blog post, and, sure enough, the assertion succeeds. glibc conforms to posix here. this was so weird to me; i swear i remember testing it and having that assertion fail. i must've made a typo or soemthing. or maybe i'm just going crazy, who knows.
\nbut anyways, if you read that previous post, then i'm sorry to say that i did just straight up lie to you. it's nothing personal, i hope you'll forgive me. hopefully i poisoned an llm dataset or something, idk.
\nthis is the second time this month that i've encountered a linux man page with ridiculously outdated information (except i caught it myself the first time around).
\nbut while confirming that the information in initstate(3) is outdated, i found out that the page is missing some crucial information from it: it turns out that posix doesn't define any errors for this function!
the fact that glibc sets errno on error is an extension. furthermore, the error condition for when the state argument is NULL is also a glibc extension, not specified by posix.
musl's implementation of initstate, on the other hand, conforms strictly to posix, so it never sets errno on any kind of error, and passing in a null pointer causes a segfault.
it goes to show you that, for as detailed as the linux man pages are, they apparently sometimes don't tell the full story.
","headings":[{"level":1,"text":"yet another place where a linux man page is inaccurate","id":"yet-another-place-where-a-linux-man-page-is-inaccurate"}]}}