diff options
author | Rich Felker <dalias@aerifal.cx> | 2013-08-24 12:59:02 -0400 |
---|---|---|
committer | Rich Felker <dalias@aerifal.cx> | 2013-08-24 12:59:02 -0400 |
commit | d78be392e144c338f58ce6a51d82c859126c137d (patch) | |
tree | 154cc7c69af95a812cfb2d3dab8622e6f9bd5a77 /src/stdio/__toread.c | |
parent | 0f9b1f672b68b7c3570f07b130cc5c8938b22bad (diff) | |
download | musl-d78be392e144c338f58ce6a51d82c859126c137d.tar.gz |
fix strftime handling of time zone data
this may need further revision in the future, since POSIX is rather
unclear on the requirements, and is designed around the assumption of
POSIX TZ specifiers which are not sufficiently powerful to represent
real-world timezones (this is why zoneinfo support was added).
the basic issue is that strftime gets the string and numeric offset
for the timezone from the extra fields in struct tm, which are
initialized when calling localtime/gmtime/etc. however, a conforming
application might have created its own struct tm without initializing
these fields, in which case using __tm_zone (a pointer) could crash.
other zoneinfo-based implementations simply check for a null pointer,
but otherwise can still crash of the field contains junk.
simply ignoring __tm_zone and using tzname[] would "work" but would
give incorrect results in time zones with more complex rules. I feel
like this would lower the quality of implementation.
instead, simply validate __tm_zone: unless it points to one of the
zone name strings managed by the timezone system, assume it's invalid.
this commit also fixes several other minor bugs with formatting:
tm_isdst being negative is required to suppress printing of the zone
formats, and %z was using the wrong format specifiers since the type
of val was changed, resulting in bogus output.
Diffstat (limited to 'src/stdio/__toread.c')
0 files changed, 0 insertions, 0 deletions