Is sprintf safe?

Question

is sprintf thread safe?

 //Global log buffer char logBuffer[20]; logStatus (char * status, int length) { snprintf(logBuffer, 19, status); printf ("%s\n", logBuffer); } 

The thread safety of this function is entirely dependent on the thread safety of snprintf / sprintf .

Updates: thanks for ur answers I do not mind if the actual contents of gts go bad. but want to confirm that sprintf will not lead to a memory overflow / buffer overflow that goes beyond 20 bytes in this case, when several threads try to write to logBuffer ?

Answer 1

No problem when using snprintf() in multiple threads. But here you write to a common string buffer, which, I believe, is common to threads.

Therefore, using this feature will not be thread safe.

Answer 2

You have a few problems with your code.

• Your use of snprintf very suspicious. Do not use it just to copy the string. As a rule, dynamically allocated lines with any contents in the format for any of the printf functions are not transmitted. They interpret the content, and if they have something that looks like a% format, you are doomed.
• Do not use static buffers like you. This is certainly not thread safe, not a repeat participant.
• Either use printf with the appropriate format directly, or replace the puts call.

Linux then adheres to the POSIX standard, which requires standard I / O functions to be thread safe.

Answer 3

Your question has the wrong premise. Even if sprintf itself can be safely called from multiple threads at the same time (as I hope it can), your code does not protect your global variable. The standard library cannot help you.

Answer 4

As for your update, without worrying if the content of the logBuffer gets corrupted:

I'm not sure why you want your function to not be completely thread safe using a locally allocated buffer or some kind of synchronization mechanism, but if you want to know what POSIX can say about it, here you go ( http: // pubs. opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_11 ):

Applications must ensure that access to any memory location by more than one control thread (threads or processes) is restricted so that the control thread cannot read or change the memory location, while another control thread can change it. This access is limited by functions that synchronize the execution of threads, as well as synchronize memory with respect to other threads. [then a list of functions providing synchronization]

So, POSIX says that your program must make sure that mutilple threads will not change logBuffer at the same time (or change logBuffer in one thread by reading it in another). If you do not agree with this, there are no promises that the worst that will happen is the garbled data in logBuffer . There are simply no promises about what the results will be. I don't know if Linux can document more specific behavior, but I doubt it.

Answer 5

"No problem using snprintf() in multiple threads."

Not true.

Not true, at least in the case of POSIX functions.

All the standard vararg functions vararg not mt-safe - this includes all the printf() family (1), but also any other variadic (2) function

• sprintf() for example: "MT-Safe locale | AS-Unsafe heap | AC-Unsafe mem" - which means that it can fail if the locale is set asynchronously or if asynchronous thread cancellation is used, in other words, when using Such features in the MT environment should be given special attention.

• va_arg not safe mt: | MT-Safe race: ap | AS-Safe | AC-Unsafe corrupt | - which means that an interlock is required.

In addition, which should be obvious, even a fully mt-safe function can be used in an unsafe way - what happens, for example, if two or more threads work with the same data / memory areas.

Answer 6

This is not thread safe, as the buffer in which you sprintf is shared between all threads.

Answer 7

"Do you have a link that says they are not thread safe? When I google it seems like they are"

My previous answer to this question was deleted / deleted (why?), So I will try again using a different approach:

• AC (asynchronous shutdown of threads): this is obviously the case when almost all of the "explicitly MT-safe" code may fail, simply because the stream is interrupted at an arbitrary point in time, so no synchronization methods are guaranteed to work correctly (i.e. any form of mutex cannot really be guaranteed to work properly)

• Themes can use the same malloc () arena, which means that if one of the threads fails (i.e. it will damage the malloc arena), then all consecutive calls to malloc () will / can cause critical errors - this, Of course, it depends on the system configuration, but it also means that no one should assume that improper memory allocations (de) are safe.

Since all systems provide the ability to use different local settings, it is obvious that async. changing the "locale" settings may cause errors ...

Sincerely.