Mail Archives: cygwin/2005/06/24/16:08:28
Eric Blake wrote:
> Not necessarily. According to POSIX, a strptime implementation is allowed
> (but not necessarily recommended) to set all fields of try, even the ones
> not related to what was parsed:
>
> "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. Conforming applications should make a
> single call to strptime() with a format and all data needed to completely
> specify the date and time being converted." -
> http://www.opengroup.org/susv3xsh/strptime.html
I guess that could explain why it works on linux then. Obviously, it's
not portable to rely on that behavior though.
> initialized properly. And pre-initializing to all 0s (as in struct tm try = {0,};)
> does not work, either, since the rules of <time.h> state that tm_month
> must be 1 - 12. In short, struct tm is a nightmare to use, but we are
> stuck with it for standardized backwards compatibility.
Actually tm_mon must be in the range [0,11]. You might have been
thinking of tm_mday which unlike all the others is 1-based, [1,31]. In
this particular example though it's probably sufficient to initialize tm
with { 0 } since both tm_mday and tm_mon should be filled in by strptime
on success. However, to truly be correct you'd have to check not only
that strptime didn't return NULL, but that it parsed the entire format
string and stopped at the expected point rather than failing early.
Brian
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
- Raw text -