Attention to bug 170444

[Thomas Bushnell BSG]

Thomas Bushnell BSG <tb at becket.net> writes:

> Attention please to http://bugzilla.gnome.org/show_bug.cgi?id=170444
> (Debian bug http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=312109).
>
> I believe I have the fix.  The problem is that many locales have date
> string formats longer than eleven characters.  Eleven was fine for
> "%d/%m/%Y" but not for anything longer.  Then when printDate is
> called, it overruns the provided buffer if we are using a
> locale-provided date string.

Lol.  This is stunning.  The bug is freakier than I thought at first.
It is a bug that gnucash only allows 11 character long dates (and
should be fixed, at least in the gnome-2 branch, if it hasn't been
already).  And there is the chaos I mentioned.

But gnucash correctly fills in "11" for the MAX argument to strftime,
and never passes it a buffer shorter than that.  Upping
MAX_DATE_LENGTH doesn't fix anything.  The problem indeed has nothing
to do with buffer lengths.

Indeed, the following program generates a segv with glibc:

-------------- next part --------------
A non-text attachment was scrubbed...
Name: foo.c
Type: text/x-csrc
Size: 333 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20050828/1e89a905/foo.bin
-------------- next part --------------

Isn't that impressive?!

Now, glibc is really casual in its use of strftime, and assumes that
the date will always fit.  Once the glibc bug is fixed, there will now
be bugs in using strftime when the locale's date string is too big to
fit in the buffer.  What glibc does in that case (when it isn't
blowing chunks) is to leave an *undefined* buffer, not necessarily
even null terminated.  Every call to strftime with any
locale-dependent format, should check the return value to avoid
overflows.