[uClibc] Re: ppc gcc bug/time.c bug? (was: wrong time/date when creating files?)

Matthias Brukner M.Brukner at trajet.de
Wed Jun 11 17:00:28 UTC 2003


Hello list,

Friday, June 6, 2003, 11:46:27 AM, I wrote:

> I'm encountering strange behaviour when creating files with uClibc
> 0.9.19 (PowerPC based) on a fat/fat32 filesystem (firewire or pcmcia
> hd): creation time/date are off by about 3 months when reading the
> media on a glibc based linux system or a windows 2000 system.

Ok, I tracked down the problem. In uClibc time.c the variable
_time_tzinfo[0].gmt_offset isn't initialized correctly. This seems to
be a compiler problem though, I tried with gcc 2.95 and 3.23 and got
the same behaviour:

We've got a global array of rule_struct:

typedef struct {
        long gmt_offset;
        long dst_offset;
        short day;                                      /* for J or normal */
        short week;
        short month;
        short rule_type;                        /* J, M, \0 */
        char tzname[TZNAME_MAX+1];
} rule_struct;

[..]

rule_struct _time_tzinfo[2];

This gets initialized in tzset() if the environment variable TZ isn't
initialized like this (~line 1613):

        ILLEGAL:                  /* TODO: Clean up the following... */
                s = _time_tzinfo[0].tzname;
                *s = 'U';
                *++s = 'T';
                *++s = 'C';
                *++s =
                *_time_tzinfo[1].tzname = 0;
                _time_tzinfo[0].gmt_offset = 0;
                goto DONE;
        }

Problem is: s doesn't point to _time_tzinfo[0].tzname but to
_time_tzinfo. I tried letting it point to any variable in the struct
but it _always_ keeps pointing to the beginning. Doh!.
But there's more to it. The initialization of gmt_offset works as if
it was a char, which in result leaves the first bytes of _time_tzinfo
like this:
0x00 0x54 0x43 0x00

By the calling function (mktime) gmt_offset is interpreted
"correctly", so it adds a whole lot of seconds to the real time,
ending up in early August :|

What strikes me is that this essential stuff (dereferencing a struct
variable) doesnt seem to work.

matt



More information about the uClibc mailing list