This is the mail archive of the
guile@sources.redhat.com
mailing list for the Guile project.
Re: Guile bug: strftime
- To: David Barts <n5jrn at ricochet dot net>
- Subject: Re: Guile bug: strftime
- From: Marius Vollmer <mvo at zagadka dot ping dot de>
- Date: 23 Jul 2000 13:24:56 +0200
- Cc: guile at sourceware dot cygnus dot com
- References: <20000722190045.A20007@subversion.org>
[ Please post bugs to bug-guile@gnu.org ]
David Barts <n5jrn@ricochet.net> writes:
> On both Intel Red Hat 6.2 and Sparc Solaris 2.6, the strftime primitive
> has a bug: if the string it would have otherwise produced would have
> been greater than 50 characters in length, a null string is returned.
Thanks! I'll fix this.
I like to discuss the patch for minute, tho. That strftime now
returns 0 on buffer overflow seems to be mandated by various
standards, so I think it's OK to treat it as the `normal' case.
However, I am worried that there are systems out there that return the
buffer length in that case.
What about this to handle both cases in one go
while ((len = strftime (tbuf, size, myfmt, &t)) == 0 || len == size)
Returning 0 from strftime is indeed the wrong thing, but they did it,
so we must cope. Your solution is very solid, but also expensive,
because it does an extra malloc and copies the string. This extra
cost is probably negligible compared to what strftime does, however.
What do you think? Could we use alloca?
The GNU Libc manual recommends to use something like this for getting
around the 'zero-length' problem:
buf[0] = '\1';
len = strftime (buf, bufsize, format, tp);
if (len == 0 && buf[0] != '\0')
{
/* Something went wrong in the strftime call. */
...
}
This avoids mallocing but relies on strftime modifying BUF before
returning. Can we rely on this?
[ I just love those Unix APIs. ]