The OpenBSD community has a reputation (sometimes deserved, sometimes not) for getting irritable when people ask questions that are answered in the documentation. To some extent, it's because the community isn't large enough to answer all the questions that come in, but mostly, it's because the documentation really is that good. Any changes to the system have to be accompanied by a change to the relevant man page, and they are usually as clear as possible. If you want to learn to use Unix (not some specific Linux distro, but Unix in general), you could do a lot worse than just starting with "man afterboot", apropos, and the tutorials in /usr/share/doc.
Actually, the primary documentation for glibc is available in the info format (preferred by the gnu project.) You can check it out by typing "info libc" on Linux (or by googling [info libc]), and I really encourage you to do it, because you may learn new and interesting things (I know I had when I first discovered it.) Most man pages on Linux have a note saying that the documentation in man format is obsolete and the info format should be used instead.
This is not to say anything bad about OpenBSD which I have no doubt is a great system, just that the comparison is somewhat unfair.
Hah, check out that malloc page for OpenBSD for how you configure malloc globally (to e.g. enable debugging): you create a /etc/malloc.conf which is a symbolic link to a non-existant file the name of which determines options, e.g. "G<" to enable extra malloc debugging and half the cache size!
That's a feature of phkmalloc (written by Poul-Henning Kamp) that was brought forward into jemalloc (used by FreeBSD and Firefox/Windows, among others) and OpenBSD's malloc (written by Otto Moerbeek et al, borrowing from phkmalloc)
As cperciva already noted below, readlink() is one syscall, whereas reading and parsing a configuration file is many syscalls and much more code. This is malloc we're talking about here, not general purpose user-configurable software.
This debugging method seems like an ugly hack. Why not use a plain text file that could be read when the program (or the computer) starts with options written in human-readable form?
Assuming it is a short file, it would require only one block read (the block pointed to by the directory entry). The broken symlink method may be faster (one less disk read, a lot less parsing overhead) but is much less human-friendly. And the added speed would only be meaningful if the file got checked more often than at program start.
Why not use a plain text file that could be read when the program (or the computer) starts with options written in human-readable form?
Reading a symlink is one system call. Reading a file is three or more system calls. There is an overhead cost for each system call -- and if you're going to be doing something for almost every process, you might as well be as efficient as possible.
Except that if you were using a text file, you use different flags or turn it on or off on a per executable file basis checked on process start and would not have to re-parse the symlink every time you malloc something.
Then why parsing a human-readable file that could, conceivably, activate a much richer debugging option-set is such a huge overhead as to make the symlink way a better option? Is the setting system-wide or process-wide?
Sorry, but I just can't see why it would be a better option.
If you're having to debug something carefully with malloc, the readability of a list of single-letter flags is probably not a big deal. (I'm not sure why the symlink filename is used, though.)
The code is in /usr/src/lib/libc/stdlib/malloc.c . I didn't know OpenBSD's malloc was under the "beer-ware license". :)
http://www.openbsd.org/cgi-bin/man.cgi?query=strncpy
http://www.openbsd.org/cgi-bin/man.cgi?query=malloc
They don't just explain what strncpy & malloc do. They also explain how to use these functions correctly and securely. With examples.
Compare that to glibc's manuals (pretty typical of what you can find under Linux):
http://linux.die.net/man/3/malloc
http://linux.die.net/man/3/strncpy
Clearly OpenBSD folks care.