On Jul 26 11:27, Brian Inglis wrote:
> On 2017-07-26 04:49, Corinna Vinschen wrote:
> > On Jul 25 14:13, Brian Inglis wrote:
> >> On 2017-07-25 12:52, Corinna Vinschen wrote:
> >>> On Jul 25 10:47, Brian Inglis wrote:
> >>>> On 2017-07-25 03:16, Corinna Vinschen wrote:
> >>>>> [...]
> >>>>> I don't think we need to use intmax_t at all here.  Checking for
> >>>>> LLONG_MAX should be sufficient.  However, this is strptime_l.  so you
> >>>>> should use strtoll_l/strtol_l, just like the rest of the function.
> >>>>>
> >>>>> On second thought, do we have to do this at all?  Our time_t is always
> >>>>> long anyway so using just strtol_l and checking for ERANGE should be
> >>>>> sufficient:
> >>>>>
> >>>>>   int old_errno = _REENT->_errno;
> >>>>>   sec = strtol_l (buf, &s, 10);
> >>>>>   int new_errno = _REENT->_errno;
> >>>>>   _REENT->_errno = old_errno;
> >>>>>   if (s == buf || new_errno == ERANGE || etc...
> >>>>>
> >>>>>> +		    BIG_T sec;
> >>>>>> +		    time_t t;
> >>>>>> +
> >>>>>> +		    sec = STRTOBIG (buf, &s, 10);
> >>>>>> +		    t = (time_t)sec;
> >>>>>> +		    if (s == buf
> >>>>>> +			|| (BIG_T)t != sec
> >>>>>> +			|| localtime_r (&t, timeptr) != timeptr)
> >>>>
> >>>> Is time_t always long on all newlib platforms, or could it be long
> >>>> long in some environments/memory models e.g. Windows 64 VS/MinGW
> >>>> LLP64/IL32P64 vs Cygwin/Unix LP64/I32LP64?  Could/should we keep the
> >>>> strtol[l] options and use the ..._l variants?
> >>>
> >>> Well... on *third* thought, targets may redefine time_t via redefining
> >>> _TIME_T_.  Targets not doing that will get long, so yeah, you're right.
> >>> Maybe it is safer to use always strtoll_l and just break this down to
> >>> time_t on the way.
> >>
> >> My concern has always been do all newlib RTEMS targets support long
> >> long, even if same as long, and stroll_l?
> > 
> > Yes.  The long long functions are not excluded like we do with long
> > double stuff.
> > 
> >> Trying to build standalone or combined STC for this with changed strptime.c
> >> ld/collect2 fails to resolve ...global_locale.
> > 
> > Yeah, it's an internal function to newlib.  You need to include
> > libc/locale/setlocale.h somehow to accomplish that.  STC from Cygwin
> > userspace will do.
> 
> Not doing it for me: that's why I asked if there were undistributed locale
> changes in the tree, and maybe in a dev snapshot?

No, it's an *internal* function, it doesn't get exported.  There's no
(easy) way to build strptime.c outside the newlib tree as part of the
lib.  That's why I said a userspace STC is enough.  Don't try to build
strptime.c as standalone.  Just build it as part of newlib/Cygwin and
test it from userspace by calling it.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat