Can time(NULL) ever return failure?

Question

Can the time_t time(time_t *t) function ever return failure if the argument passed is always NULL?

If the call is time(NULL), do we still need to check for the return value?

The only documented error code is EFAULT, which relates to the pointer being invalid.

@user3159253 It could return EFAULT in the case of `time((time_t*)junk)`, for some junk value. Although at the point of being able to return EFAULT, I'd already consider the programs behavior forfeit. — user2864740, Dec 16 '15 at 03:45
For *some* junk. The question seems moot, but .. meh, let the lawyers feed. — user2864740, Dec 16 '15 at 03:47
@user3159253 Nothing to do with being well known (although that made it a very practical choice among other implications); it could have been any value (**), had it been codified into the function contract. — user2864740, Dec 16 '15 at 03:49
For a given platform? No, for a given platform NULL pointer is determined completely. But sure, it could be != 0 — user3159253, Dec 16 '15 at 03:51
Well, there's no EFAULT at all. Neither in [Linux-specific time() implementation in GLIBC](https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/time.c;h=a20efb43639d8ad81981a778e9f35a016265d555;hb=HEAD) nor in FreeBSD [gettimeofday](https://github.com/freebsd/freebsd/blob/master/lib/libc/sys/gettimeofday.c) — user3159253, Dec 16 '15 at 04:17
On some commercial \*NIX `time(NULL)` was crashing. Don't remember the details though. On the relevant project, the style was always `time(&timvar);` without any further error checking. On all modern *relevant* \*NIX-y systems `time(NULL)` doesn't fail. (What's more, on Linux and BSD the syscall is optimized such, that it can't even detect errors.) YMMV — Dummy00001, Dec 16 '15 at 08:22
depends on what's being tested. And the function after the outcome — Patrick Mutwiri, Dec 16 '15 at 13:14

score 22 · Accepted Answer · answered Dec 16 '15 at 04:41

22

Yes. time has a documented may fail case:

The time() function may fail if:

[EOVERFLOW] The number of seconds since the Epoch will not fit in an object of type time_t.

Source: http://pubs.opengroup.org/onlinepubs/9699919799/functions/time.html

Expect this to happen in practice in about 22 years, no sooner, and not on 64-bit systems or 32-bit ones that utilize a 64-bit time_t.

Also, the presence of any shall fail or may fail cases also allows for implementation-defined errors, though their existence would be a serious quality-of-implementation flaw.

EFAULT is a non-issue/non-existent because it only happens when your program has undefined behavior.

So despite all this, in the real world, time is not actually going to fail.

answered Dec 16 '15 at 04:41

R.. GitHub STOP HELPING ICE

208,859
35
376
711

That's fine for posix, but the specifics documented are not standard C. – Peter Dec 16 '15 at 05:46
4

@Peter: The question is tagged posix. – R.. GitHub STOP HELPING ICE Dec 16 '15 at 05:49
1

And C, R. It is applicable to one but not the other. Hence my comment. – Peter Dec 16 '15 at 06:43
2

"no sooner"... if you assume the machine's clock is correct ;) – Eevee Dec 16 '15 at 11:49

score 5 · Answer 2 · answered Dec 16 '15 at 05:58

5

Can time(NULL) ever return failure?

No. C standard says that

C11: 7.27.2.4:

The time function returns the implementation’s best approximation to the current calendar time. The value (time_t)(-1) is returned if the calendar time is not available.

answered Dec 16 '15 at 05:58

haccks

104,019
25
176
264

5

I guess `(time_t)(-1)` is in some sense a "best approximation" if time information cannot be retrieved... although it is debatable how useful this approximation is in practice if not treated as an error condition. – Thomas Dec 16 '15 at 07:41

score 4 · Answer 3 · answered Dec 16 '15 at 05:19

I've checked on RHEL, SLES and UBTU; the man 2 page yields the same (relevant) thing:

  time() returns the time since the Epoch (00:00:00 UTC, January 1, 1970), measured in seconds.

   If t is non-NULL, the return value is also stored in the memory pointed to by t.

Anyway, going back to the original questions

Q0: Can the time_t time(time_t *t) function ever return failure if the argument passed is always NULL?
- A/R0: Yes, if some very special events occurred (memory full, and so on, ...)
Q1: If the call is time(NULL), do we still need to check for the return value?
- A/R1: The actual answer is "NO", you don't have to; the fact that the func could return something relevant, is a different story. After all, why calling a func ,if there's no need of doing so?
Q2: The only documented error code is EFAULT, which relates to the pointer being invalid.
- You don't have anything to do with the invalid codes; as you said you're passing NULL, so there's no problem.

Peter · Answer 4 · 2015-12-16T06:44:53.140

4

In the C standard, time() can return (time_t)(-1) if "the calendar time is not available". In the 1999 standard, for example, that is in Section 7.23.2.4, para 3.

Although that wording is less than specific, I would suggest it represents an error condition. Presumably an implementation can return (time_t)(-1) if it can't access the system clock, can't sensibly interpret the data it gets, etc.

R's answer describes what is the case for the posix spec.

edited Dec 16 '15 at 06:44

answered Dec 16 '15 at 05:46

Peter

35,646
4
32
74

Long ago, on VMS, the system clock was in local time. Until much later, when the OS gained timezone support, time() always returned -1. – richardb Dec 16 '15 at 17:11

score 3 · Answer 5 · answered Dec 16 '15 at 04:56

(Not consider POSIX degraded mode functionality)

If the underlying real-time clock sub-system had a hardware fault like loss of clock integrity (battery) when the unit was off on an independent system, the return value of time() could certainly be (time_t) -1. In that case, it make no difference what the passed in time_t* was.

Can time(NULL) ever return failure?

5 Answers5