1

In (g)libc, for example in time and date functions like localtime, the manual says:

The return value points to a statically allocated string which might be overwritten by subsequent calls to any of the date and time functions.

As far as I know, my program is single-threaded. Is it safe for me to use the "MT-Unsafe" functions like asctime or localtime?

Even if there is only 1 (g)libc library instance in the memory? (I.e. as a dynamic library.)

Does "static" mean "static to my program" (for each program instance a new buffer instance is allocated..), "static to the process" (one buffer instance per process -- this suggests), or static to the (libc) library (as many buffer instances as library (-fragment) instances)?

(I know about question #8694365 but mine a bit differs.)

Community
  • 1
  • 1
  • 1
    There's no such thing as "library instance". If the C standard says you can use `localtime`, and your program adheres to the standard (i.e. doesn't uses things like threads), then you can use `localtime`. That's what the standard is for. – n. m. could be an AI Mar 06 '17 at 14:45
  • Can't emphasize this enough: **There's no such thing as "library instance".** – R.. GitHub STOP HELPING ICE Mar 06 '17 at 15:16
  • @R - this is compiler dependent. gnu has a thread unsafe version of localtime, while [Visual Studio local time](http://msdn.microsoft.com/en-us/library/bf12f0hc.aspx) appears to always be thread safe. DLL libraries could be considered as "one instance per system" libraries. Static libraries could be considered as "one instance per process". Windows has a per thread data area, for thread safe libraries to use as needed. I don't know how Posix systems implement this. – rcgldr Mar 06 '17 at 17:23
  • @R..: there can only be one instance of a shared object file in a process, but nothing stops me from loading the same library (or a lbrary with the same external definitions) from two different files. Or from both statically linking and dynamically linking the "same" library. In both of those cases it will be observed that the statically-allocated object belongs to the library object and not the process as a whole, often leading to grief. – rici Mar 06 '17 at 17:39
  • @rici: In that case your program has UB (duplicate definitions) and what happens is outside the scope of the C language. – R.. GitHub STOP HELPING ICE Mar 06 '17 at 22:58
  • @rcgldr: No, MSVC is just non-conforming. C specifies static storage; if it uses thread-local storage, the behavior would be observably wrong when you read the object after the thread the function was called in has exited. (E.g. `pthread_exit(localtime(t));`) – R.. GitHub STOP HELPING ICE Mar 06 '17 at 23:00
  • @R - It's the combination of MSVC and Windows. Windows has a per thread data area that exists outside "normal" thread local storage. For example, the seed for rand() is one of the variables kept in the per thread data area. Windows kernel manages the per thread data in a different way than it manages thread local storage. FS (or GS?) may be used to access per thread data or to map the per thread data into a process virtual address space. – rcgldr Mar 06 '17 at 23:10

1 Answers1

0

The global (defined outside a function) and static (defined inside a function) are allocated once for each program. Otherwise, asctime would be totally unusable, as you cannot be sure there isn't another program calling that exact function at the same time yours does.

laarmen
  • 73
  • 4