Hacker News Reader

Comment by throwaway76543 | Hacker News Reader

Ah yes, I was thinking about the system call interfaces but if we start looking at libc damn near nothing was reentrant until relatively recently (the late 90s and early 00s count as recent right? ... right?)

Just take a gander at all those _r functions where an extra parameter needed to be added for reentrancy.

View on HN

Some of them turned out to be hyper-corrective duds, like readdir_r. No need for that one, since the buffer it needs can be allocated in the DIR object. You'd never want multiple threads concurrently doing readdir_r from the same DIR stream; there is no credible use case for it. (Or, maybe, optimization? Since it can store the dirent-s directly into some space designated by the caller, eliminating a copy operation from a program that wants to retain all those dirent-s.)

Is this because, as I recall, a DIR object is opaque while a FILE is not? Allowing the former to be expanded without breaking the API?

edit: Nevermind, that shouldn't matter should it? The important thing is that they're both by reference.

FILE can be opaque. Some implementations made the (arguable) mistake of implementing e.g. fileno() as a macro that accesses FILE internals, and this means they can't change that layout without breaking libc ABI of existing programs. But you can implement all POSIX stdio FILE APIs with an opaque FILE.

Reply on news.ycombinator.com