Mfcttrf

char* asctime (const struct tm * timeptr);
char* ctime (const time_t * timer);

I found that many functions inside of time.h return pointers to static variables, which could be altered by any subsequent call to those functions. That means I have to copy the data I just got as a result and it's an extra operation I have to execute and that makes those functions thread-unsafe.

Why was it implemented that way? Wouldn't these signatures be better?

void asctime (char * out, const struct tm * timeptr);
void ctime (char * out, const time_t * timer);

We always have to take decisions during development. I'm just asking why they chose to return a static pointer instead of taking an "out variable" as a parameter.

By the way (this is another question), why don't they allocate their result on the heap? Is it to allow the use of anything instead of malloc or just for efficiency?

The specification of the ctime and asctime functions goes back to C89, and things were done a bit different back in those days, mainly because multi-processor systems weren't very common and thus using a static buffer wouldn't cause a big problem.

Most likely, they didn't return dynamically allocated memory because it took extra time, and in those days CPU cycles were harder to come by.

If you're on a POSIX system like Linux, you have two other functions available which are basically what you described as an alternative:

 char *asctime_r(const struct tm *tm, char *buf);
 char *ctime_r(const time_t *timep, char *buf);

These function take a pointer to a buffer that can receive the output (and they return a pointer to that same buffer). The _r suffix means "reentrant", meaning it can safely be called either in a multithreaded program or more than once without a sequence point in between.

That means I have to copy the data I just got as result

Why do you need to copy it?

Note that even if you copy the data as soon as you get it, you will still be open to races.

Why was it implemented that way?

Because when they were standardized (1989), multi-core/SMT did not exist (they started to appear between 2001 and 2006), so most software wasn't multi-threaded. Therefore, it did not matter much. For reference, even POSIX threads were standardized years later (1996) than these functions.

If you needed something else, you could always use a system-specific function.

why don't they allocate their result on the heap?

Allocating is very expensive.

Is it to allow the use of anything instead of malloc or just for efficiency?

Not sure what you mean by that. The proper way to do this is to pass a pointer to the destination buffer, so that the user chooses what allocation method to use.

You are (almost) describing the _s variants that were added in C11

errno_t ctime_s(char *buffer, rsize_t bufsz, const time_t *time);
errno_t asctime_s(char *buf, rsize_t bufsz, const struct tm *time_ptr);

These write to the specified location, provided it is big enough, and report the error otherwise.

You don't need to malloc the buffers for these calls, as you know char buf[26]; is exactly what is needed.

C is a product of the early 1970s, and that legacy shows in things like this. strtok also uses a static buffer and is neither thread-safe nor re-entrant.

I've not seen a definitive explanation for why those functions were implemented that way. It may have been to save stack space (128 kB was a lot of very expensive memory at the time), it may have been to avoid runtime checks on the size or validity of the target buffer, etc. C was originally designed for systems programming, so if time calculations were being done a lot, I can see this approach saving a significant number of cycles over the course of the day.

Unfortunately, that's speculation on my part. I agree that passing the target buffer is the better solution, and that should be the path forward.