Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Feb 2018 18:07:38 +0100
From: Dennis W├Âlfing <>
Subject: Bugs in strftime


I recently wrote a test for strftime and ran it on multiple
implementations. The source code of the test is available at [1]. The
test results (also for other implementations) are available at [2].

On musl my test currently reports 8 failures. These are caused by two bugs:

1. For the + flag, musl does currently only prefix the output by a plus
when the number without padding consumes more the 4 bytes (2 for %C).
However according to the POSIX standard, there should be a leading plus
when "the field being produced consumes more than four bytes" (2 for
%C). The padding is part of the field being produced.
So for example %+3C should always have a leading plus for any
non-negative years because the field then always has a width of at least
3 bytes. (There is also an example in the POSIX standard where "%+5Y"
produces "+0270" for the year 270.)

This bug is causing these failures:
> "%+3C": expected "+20", got "020"
> "%+11F": expected "+2016-01-03", got "02016-01-03"
> "%+5G": expected "+2015", got "02015"
> "%+5Y": expected "+2016", got "02016"
> "%+5Y": expected "+0000", got "00000"

2. %F produces incorrect results for the year 0 when a field width is
specified. It seems like in this case strftime does not output the year
and applies the padding to the month.

This bug is causing these failures:
> "%01F": expected "0-02-23", got "2-23"
> "%06F": expected "0-02-23", got "002-23"
> "%010F": expected "0000-02-23", got "0000002-23"

The tests were run on musl 1.1.18 on Alpine Linux.



Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.