![]() |
|
Date: Fri, 2 Feb 2018 18:07:38 +0100 From: Dennis Wölfing <denniswoelfing@....de> To: musl@...ts.openwall.com Subject: Bugs in strftime Hi, 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. [1] https://github.com/dennis95/dennix/blob/master/libc/test/test-strftime.c [2] https://gist.github.com/dennis95/b4869b5cbb3c21e15e409afb827354a5#file-musl-1-1-18-alpine-linux-x86_64
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.