[uClibc]strptime and mktime problem
Manuel Novoa III
mjn3 at codepoet.org
Wed Jun 18 13:28:39 UTC 2003
On Tue, Jun 17, 2003 at 10:50:44PM -0700, Andrew May wrote:
> On Tue, Jun 17, 2003 at 10:00:18PM -0600, Manuel Novoa III wrote:
> > On Tue, Jun 17, 2003 at 07:05:44PM -0700, Andrew May wrote:
> > > The first problem is that strptime() seems to screw up the values of
> > > everthing in the tm struct.
> >
> > Well, as far as strptime() is concerned, your code above isn't portable.
> > Quoting from the SUSv3 application usage notes regarding strptime():
> >
> > http://www.opengroup.org/onlinepubs/007904975/functions/strptime.html
> >
> > It is unspecified whether multiple calls to strptime() using the same
> > tm structure will update the current contents of the structure or
> > overwrite all contents of the structure.
>
> The note is regarding "multiple calls to strptime". Now the test code
> does use the same struct in multiple calls, but I would argue that the
> first call has values in the structure overwritten that I did not want
> overwritten. So switch the lines strptime call and setting tm_mday to
> make it clearer.
You're picking nits. The intent of the note is that, as far as SUSv3
is concerned, there are _no_ guarantees with respect to any fields not
explicitly set via the format statement. The application notes go on
to say:
Portable applications should make a single call to strptime() with a
format and all data needed to completely specify the date and time
being converted.
I consciously decided to "trash" all unset fields in order to help detect
non-portable code.
> Like with just this code, since there is just one call to strptime I do
> not think the above note applies and the results are not same as libc.
I agree that the results are not the same as glibc, which I believe is
the libc you are talking about. Quoting from my section of the
glibc/uclibc differences file:
The intended target for all my uClibc code is ANSI/ISO C99 and SUSv3
compliance. While some glibc extensions are present, many will
eventually be configurable. Also, even when present, the glibc-like
extensions may differ slightly or be more restrictive than the native
glibc counterparts. They are primarily meant to be porting _aides_
and not necessarily drop-in replacements.
So, as I wrote in my last post, I might (and now probably will) make
the initialization of unset fields a configuration "option". But I
think it is important to find bugs (including non-portable code) early
on; especially when programming for embedded systems.
> I have also been going by the man pages on my debian machines that have
> this note.
>
> =======================================================================
> NOTES
> In principle, this function does not initialize tm but only
> stores the values specified. This means that tm should be
> initialized before the call. Details differ a bit between
> different Unix systems. The GNU libc implementation does not
> touch those fields which are not explicitly specified, except
> that it recomputes the tm_wday and tm_yday field if any of
> the year, month, or day elements changed.
> =======================================================================
The above note describes _glibc_ implementation details. Another
difference between the two implementations is that uClibc's strptime()
does not calculate the tm_wday or tm_yday fields.
> I will have to get back to you on trying the TZ setting.
Ok.
Manuel
More information about the uClibc
mailing list