[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Fwd: bug in newlib strftime

From: Eric Blake
Subject: Fwd: bug in newlib strftime
Date: Thu, 20 Jan 2005 22:02:15 -0700
User-agent: Mozilla Thunderbird 1.0 (Windows/20041206)

Hash: SHA1

Newlib strftime() has some POSIX compliance bugs; in fact, up until a
patch was applied today, the format string "%r" was unrecognized.  I have
seen the "%r" bug manifest itself in cygwin (which uses newlib) on at
least coreutils date and in autogen.  And even after today's patch, newlib
still implements "%z" by dereferencing an array using struct tm.tm_isdst
without validation, such that an arbitrary tm_isdst exceeds the array
bounds and could cause a SIGSEGV.  Should AC_FUNC_STRFTIME be updated to
look for these non-compliance/security issues before deciding to set
HAVE_STRFTIME, by using an AC_RUN_IFELSE on a variant of the program below?

- -------- Original Message --------
Subject: bug in newlib strftime
Date: Wed, 19 Jan 2005 06:37:47 -0700
From: Eric Blake <address@hidden>
To: address@hidden, address@hidden

Newlib has several POSIX compliance issues in strftime().  See
http://www.opengroup.org/onlinepubs/009695399/functions/strftime.html for
the mandated behavior.  Since newlib does not support any locales other
than "C", strftime() should be fixed to follow the mandated behavior.  The
broken behavior of strftime() leads to failures in the coreutils program
date on cygwin and any other newlib-based platform.

Should coreutils add a configure-time check that looks for broken
strftime(), or should I just wait for a new version of newlib that fixes
the compliance issues?

In newlib, strftime() treats "%r" as "", although Posix requires it to be
a synonym for "%I:%M:%S %p" in the POSIX/C locale.  Likewise, newlib
treats "%x" as "%a %b %d %Y", although Posix mandates "%m/%d/%y".
Finally, newlib does not support the %E or %O modifiers, even though Posix
mandates that they be ignored for the conversion specifiers that support
them (in other words, "%Ey", "%Oy", and "%y" are all required and should
behave identically in the "C" locale, but since "%Ea" is not required, its
behavior is undefined).  In the sample program below, the two output lines
should be identical.

$ cat foo.c
#include <time.h>
#include <stdlib.h>
#include <locale.h>

#define MAX_LEN 80

int main()
  char str[MAX_LEN];
  struct tm t;
  setlocale(LC_ALL, "C");
  memset(&t, 0, sizeof(t));
  t.tm_sec = 30;
  t.tm_min = 15;
  t.tm_hour = 1; /* 1:15:30 AM */
  t.tm_mday = 18; /* 18th */
  t.tm_mon = 0; /* Jan */
  t.tm_year = 105; /* 2005 */
  t.tm_wday = 2; /* Tue */
  strftime(str, MAX_LEN, "%r#%x#%Ey#%Oy", &t);
  strftime(str, MAX_LEN, "%I:%M:%S %p#%m/%d/%y#%y#%y", &t);
  return 0;
$ gcc -o foo foo.c
$ ./foo
#Tue Jan 18 2005#y#y
01:15:30 AM#01/18/05#05#05

Bug-coreutils mailing list

- --
Life is short - so eat dessert first!

Eric Blake             address@hidden
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


reply via email to

[Prev in Thread] Current Thread [Next in Thread]