I want a minimal o-damn-malloc-just-failed handler, which writes some info to a file (probably just standard error). I would prefer to use fprintf() rather than write(), but this will fail badly if fprintf() itself tries to malloc().
Is there some guarantee, either in the C standard, or even just in glibc that fprintf won't do this?
No, there's no guarantee that it won't. However, most implementations I've seen tend to use a fixed size buffer for creating the formatted output string (a).
In terms of glibc (source here), there are calls to malloc within stdio-common/vfprintf.c, which a lot of the printf family use at the lower end, so I wouldn't rely on it if I were you. Even the string-buffer output calls like sprintf, which you may think wouldn't need it, seem to resolve down to that call, after setting up some tricky FILE-like string handles - see libio/iovsprintf.c.
My advice is to then write your own code for doing the output so as to ensure no memory allocations are done under the hood (and hope, of course, that write itself doesn't do this (unlikelier than *printf doing it)). Since you're probably not going to be outputting much converted stuff anyway (probably just "Dang, I done run outta memory!"), the need for formatted output should be questionable anyway.
(a) The C99 environmental considerations gives an indication that (at least) some early implementations had a buffering limit. From my memory of the Turbo C stuff, I thought 4K was about the limit and indeed, C99 states (in 7.19.6.1 fprintf):
The number of characters that can be produced by any single conversion shall be at least 4095.
(the mandate for C89 was to codify existing practice, not create a new language, and that's one reason why some of these mimimum maxima were put in the standard - they were carried forward to later iterations of the standard).
printf() functions. (I've done it without, so I know what I'm talking about.) But the hint that one doesn't need much conversion here is a good one: Check if puts() does the trick for you.
printf() using recursion, without any buffer.
intmax_t and one pointer on the stack for every digit in the integer. That is a buffer. Hiding it with recursion does not make the buffer go away. (And really, for integers greater than two digits, a plain char buffer would have used less space)
Commented
Jul 20, 2011 at 16:18
The C standard doesn't guarantee that fprintf won't call malloc under the hood. Indeed, it doesn't guarantee anything about what happens when you override malloc. You should refer to the documentation for your specific C library, or simply write your own fprintf-like function which makes direct syscalls, avoiding any possibility of heap allocation.
The only functions you can be reasonably sure will not call malloc are those marked async-signal-safe by POSIX. Since malloc is not required to be async-signal-safe (and since it's essentially impossible to make it async-signal-safe without making it unusably inefficient), async-signal-safe functions normally cannot call it.
With that said, I'm nearly sure glibc's printf functions (including fprintf and even snprintf) can and will use malloc for some (all?) format strings.
malloc is always illegal (UB), of course... :-)
Commented
Jul 19, 2011 at 15:57
malloc(), when the allocation fails, I want that function to print a log message.malloc()failed? I guess the only way for you to continue is to print a predefined message in a text and send it usingwrite(). Generally, allocation failures in today software are rather qualifying as "callabort()on allocation failure". If this is for debugging/diagnostics, the coredump will tell you much more than any error message (unless you have demolished the stack, of course).printf()for that, whether I have to stick withwrite().printf()is likely to call malloc().