diff options
| author | Stewart Smith <stewart@linux.vnet.ibm.com> | 2017-08-23 15:14:01 +1000 |
|---|---|---|
| committer | Stewart Smith <stewart@linux.vnet.ibm.com> | 2017-08-24 12:59:15 +1000 |
| commit | a6c668d5d53b3d66df0015b04582187e592f67e9 (patch) | |
| tree | f3d91879dc7e4d0cc6984c6e4006642be4d32cca /libc | |
| parent | c426e9f608f22e3f6daa98d7c15f606e201f70e7 (diff) | |
| download | talos-skiboot-a6c668d5d53b3d66df0015b04582187e592f67e9.tar.gz talos-skiboot-a6c668d5d53b3d66df0015b04582187e592f67e9.zip | |
mktime: fix off-by-one error calling days_in_month
From auditing all the mktime() users, there seems to be only a *very*
small window around new years day where we could possibly return
incorrect data to the OS, and even then, there would have to be FSP
reset/reload on FSP machines. I don't *think* there's an opportunity
on other machines.
Signed-off-by: Stewart Smith <stewart@linux.vnet.ibm.com>
Diffstat (limited to 'libc')
| -rw-r--r-- | libc/time.c | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/libc/time.c b/libc/time.c index 6a510869..71bbdff6 100644 --- a/libc/time.c +++ b/libc/time.c @@ -121,7 +121,7 @@ time_t mktime(struct tm *tm) for (d = days_in_month(month, year); mday > d; d = days_in_month(month, year)) { month++; - if (month > 12) { + if (month > 11) { month = 0; year++; } |
