This is the mail archive of the guile@sources.redhat.com mailing list for the Guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Guile bug: strftime


[ 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. ]

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]