Refactoring glibc APIs from foo to foo_r

Of course, today, with MT applications being the de facto reality, what do we do? The glibc maintainers understand these issues, and have used precisely the refactoring techniques passing additional parameters to avoid the usage of global and/or static variables (like we did previous with our ch16/mt_iobuf_rfct.c code), including using parameters as return values—to refactor standard glibc functions to become thread-safe. The glibc naming convention is if the older function is named foo, the refactored, usually reentrant- and thread-safe, version is named foo_r.

To help lend clarity to this discussion, let's take an example of a glibc API that has both the older foo and the newer foo_r functionality. ...

Get Hands-On System Programming with Linux now with the O’Reilly learning platform.

O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.