[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