diff options
| author | Nick Mathewson <nickm@torproject.org> | 2010-12-07 14:37:50 -0500 |
|---|---|---|
| committer | Nick Mathewson <nickm@torproject.org> | 2011-04-28 17:12:54 -0400 |
| commit | 51e551d3837990b7c4491253a88bedd2513fe1de (patch) | |
| tree | 7cf7c7166e57fa8882d8c38caca7226d1c0e1b49 /changes | |
| parent | 3055acbdbe914c31ca4825ed60b4cce6676bd61e (diff) | |
| download | tor-51e551d3837990b7c4491253a88bedd2513fe1de.tar tor-51e551d3837990b7c4491253a88bedd2513fe1de.tar.gz | |
Detect and handle NULL returns from (gm/local)time_r
These functions can return NULL for otherwise-valid values of
time_t. Notably, the glibc gmtime manpage says it can return NULL
if the year if greater than INT_MAX, and the windows MSDN gmtime
page says it can return NULL for negative time_t values.
Also, our formatting code is not guaranteed to correctly handle
years after 9999 CE.
This patch tries to correct this by detecting NULL values from
gmtime/localtime_r, and trying to clip them to a reasonable end of
the scale. If they are in the middle of the scale, we call it a
downright error.
Arguably, it's a bug to get out-of-bounds dates like this to begin
with. But we've had bugs of this kind in the past, and warning when
we see a bug is much kinder than doing a NULL-pointer dereference.
Boboper found this one too.
Diffstat (limited to 'changes')
| -rw-r--r-- | changes/gmtime_null | 6 |
1 files changed, 6 insertions, 0 deletions
diff --git a/changes/gmtime_null b/changes/gmtime_null new file mode 100644 index 000000000..16a25408b --- /dev/null +++ b/changes/gmtime_null @@ -0,0 +1,6 @@ + o Minor bugfixes + - On some platforms, gmtime and localtime can return NULL under + certain circumstances even for well-defined values of time_t. + Try to detect and make up for this deficiency. Possible fix for + bug 2077. Bugfix on all versions of Tor. Found by boboper. + |