[bug-gnulib] nit in strftime.c

[Jim Meyering]

I found this by inspection.
Since the code checks for failure of the underlying strftime,
I presume it is possible for it to fail before writing anything
into ubuf[0].  In that case, ubuf[0] would be used uninitialized.

As far as I can see, the only way this could happen is with
bogus (longer than 1024-byte) locale data for e.g., %p, %EY, etc.

The only explanation I can imagine for the pre-patched code is an
assumption that this particular strftime call will always write
into ubuf[0].  While that is reasonable, I don't see any guarantee
of such behavior in the POSIX spec.

Comments welcome.

Here's a proposed fix:

2005-03-14  Jim Meyering  <address@hidden>

        * strftime.c (my_strftime) [HAVE_STRFTIME && ! (_NL_CURRENT
        && HAVE_STRUCT_ERA_ENTRY)]: Initialize the first byte of ubuf[]
        to be nonzero so that we (and caller) can detect the difference
        between a valid zero-length expansion and an error return, even
        when the underlying strftime fails before writing anything into
        that location.

Index: lib/strftime.c
===================================================================
RCS file: /cvsroot/gnulib/gnulib/lib/strftime.c,v
retrieving revision 1.76
diff -u -p -r1.76 strftime.c
--- lib/strftime.c      11 Nov 2004 05:58:12 -0000      1.76
+++ lib/strftime.c      14 Mar 2005 14:00:30 -0000
@@ -1,4 +1,4 @@
-/* Copyright (C) 1991-1999, 2000, 2001, 2003, 2004 Free Software
+/* Copyright (C) 1991-1999, 2000, 2001, 2003, 2004, 2005 Free Software
    Foundation, Inc.
 
    NOTE: The canonical source of this file is maintained with the GNU C 
Library.
@@ -773,6 +773,7 @@ my_strftime (CHAR_T *s, size_t maxsize, 
              *u++ = modifier;
            *u++ = format_char;
            *u = '\0';
+           ubuf[0] = '\1';
            len = strftime (ubuf, sizeof ubuf, ufmt, tp);
            if (len == 0 && ubuf[0] != '\0')
              return 0;