From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53342 invoked by alias); 25 Jul 2017 20:13:58 -0000 Mailing-List: contact newlib-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: newlib-owner@sourceware.org Received: (qmail 53022 invoked by uid 89); 25 Jul 2017 20:13:57 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=Our X-HELO: smtp-out-so.shaw.ca Received: from smtp-out-so.shaw.ca (HELO smtp-out-so.shaw.ca) (64.59.136.139) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 25 Jul 2017 20:13:56 +0000 Received: from [192.168.1.100] ([24.64.240.204]) by shaw.ca with SMTP id a6DJd9uPMMaqMa6DKd2nSi; Tue, 25 Jul 2017 14:13:54 -0600 X-Authority-Analysis: v=2.2 cv=Qc8WhoTv c=1 sm=1 tr=0 a=MVEHjbUiAHxQW0jfcDq5EA==:117 a=MVEHjbUiAHxQW0jfcDq5EA==:17 a=IkcTkHD0fZMA:10 a=fP3qfBknkE27JhSe5aoA:9 a=ixiDbKdcmYeiBjj8:21 a=uabGJuItzm7tX34z:21 a=QEXdDO2ut3YA:10 Reply-To: Brian.Inglis@SystematicSw.ab.ca Subject: Re: Cygwin strptime() is missing "%s" which strftime() has To: newlib@sourceware.org References: <851e9a02-f7c2-25c4-f37d-64d17d5c6d54@SystematicSw.ab.ca> <20170725091613.GB14419@calimero.vinschen.de> <20170725185206.GE14419@calimero.vinschen.de> From: Brian Inglis Message-ID: <9c38bcee-fbb0-9a30-0c28-58629f54aa0e@SystematicSw.ab.ca> Date: Tue, 25 Jul 2017 20:13:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 In-Reply-To: <20170725185206.GE14419@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfHvMWPnAGwrt9RHYPLBOWbrtzeYGZV6btzzqblTR7ixLgbo71Ds3mrpuR0UIi0YBXxvHJvoVOrj9YX59AsgvGMwJ6kV/J7Al8Xld9cp8VRdCQzP++/3j bOPb/2cH2MJhqlptbb8E/NHJ+LEmtNUezoGX/ujQACgxrcywlmQpgLPqZfbwE4WhNuqKb/GMiA5ZYA== X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00645.txt.bz2 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: >>> On Jul 24 14:41, Brian Inglis wrote: >>>> On Mon, 24 Jul 2017 02:32:14 -0700, Corinna Vinschen wrote:> On Jul 23 22:07, >>>>> In this case I have a nit, but this should be discussed on the right >>>>> mailing list so all affected parties can chime in. Hint: strtoimax is >>>>> not available on all platforms yet (patches still in limbo)... >>>> >>>> Figured there would need to be some tweaks for newlib platforms, compilers, and >>>> style, so made some changes, attached another diff for discussion, before >>>> submitting a patch. >>>> Let me know if you want conditionals or declarations changed, hoisted to >>>> function start, case braces removed, other issues? >>> [...] >>>> + case 's' : { >>>> +#if defined(INTMAX_MAX) >>>> +# define BIG_T intmax_t >>>> +# define STRTOBIG strtoimax >>>> +#elif defined(LLONG_MAX) >>>> +# define BIG_T long long >>>> +# define STRTOBIG strtoll >>>> +#else >>>> +# define BIG_T long >>>> +# define STRTOBIG strtol >>>> +#endif >>> >>> 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? >> Can't we just use errno, as shouldn't that be mapped to _REENT->_errno >> in this context if required, or can it/does it need to be explicit? >> These are locale-dependent ..._l functions not reentrant ..._r >> functions, and there is no "#include "? > > No, I was just trying to be thorough. errno is fine, just include > errno.h. > >> Don't we need to save and zero errno to distinguish a new error, and >> restore if it stays zero, rather than just pick up the current value, >> and assume if it is/was ERANGE it's bad? > > Right, I forget that when I typed the above. > >>> Shouldn't this be gmtime_r? >>> >>> %s The number of seconds since the Epoch, 1970-01-01 00:00:00 +0000 >>> (UTC). Leap seconds are not counted unless leap second support >>> is available. >> >> The input is seconds since the epoch, but the interpretation in struct >> tm depends on the locale, so we use localtime_r(3). The timezone may >> be set in the environment or locale, and may be UTC. If you want >> gmtime/UTC you set TZ=UTC0, TZ=Etc/UTC, which should override/change >> locale LC_TIME, as would setting %z with value +0000 or %Z with values >> UTC or Z, where that is supported by strptime_l(3) (i.e. not here). > > Hmm, yes, ok, that makes sense. K will change and check and format-patch. Trying to build standalone or combined STC for this with changed strptime.c ld/collect2 fails to resolve ...global_locale. Of course STC alone builds and fails properly with current release. Is there anything I can include or add somewhere to get this to build - recent dev snapshot maybe? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada