[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