On Sun, Jan 29, 2023 at 08:16:06AM -0700, Todd C. Miller wrote:
> Unfortunately we cannot use strtonum(3) here since there may be
> non-digit characters following the number. So, strtoll(3)
> it is then.
Since strptime's %s is supposed to be the inverse of strftime's %s,
which is produced with mk
Unfortunately we cannot use strtonum(3) here since there may be
non-digit characters following the number. So, strtoll(3)
it is then.
- todd
Index: lib/libc/time/strptime.c
===
RCS file: /cvs/src/lib/libc/time/strptime.c,v
;t this need to be int64_t?
> >
> > int result = 0;
>
> Yes, it does, thanks.
>
> > https://github.com/openbsd/src/blob/master/lib/libc/time/strptime.c#L613
> >
> > (i think the overflow checks are insufficient in both copies of the
> > function too, espe
//github.com/openbsd/src/blob/master/lib/libc/time/strptime.c#L613
>
> (i think the overflow checks are insufficient in both copies of the
> function too, especially around the min and max values, but this seems like
> the biggest problem with the code.)
The checks for underflow/overflow
t64_t instead of
> time_t though.
>
yeah, but that's the copy & paste-o, no? (apologies if it's just too early
for me to be looking at code yet...)
doesn't this need to be int64_t?
int result = 0;
https://github.com/openbsd/src/blob/master/lib/libc/time/strptime.c
On Thu, 26 Jan 2023 09:36:52 -0800, enh wrote:
> it's quite possible that this could use _conv_num64(), but it wasn't
> obvious to me that that function's correct? (i haven't thought too hard
> about the overflow logic, but just the fact that result is an `int` seems
> odd?)
It just returns a boo
well, the
+ if (bp == old_bp || errno == ERANGE ||
+((long) t) != n) return NULL;
bit is the "most active ingredient" here, deliberately failing (rather than
wrapping) if out of 32-bit range.
it's quite possible that this could use _conv_num64(), but it wasn't
obvious to me that that functio
Is there a reason you didn't just change the gmtime_r() in the 's'
case to localtime_r()? That seems like the simplest fix. Using
strtol() for what may be a 64-bit value on an 32-bit system looks
wrong.
- todd
i synced Android's strptime.c with openbsd's recently, getting rid of
unnecessary/accidental differences. i'm left with the following, which i
thought was interesting (the last one's probably the most interesting, so
definitely stick around even if -- as is likely -- you don&#
