From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 47731 invoked by alias); 28 Jul 2017 20:50:59 -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 47617 invoked by uid 89); 28 Jul 2017 20:50:58 -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=strtol, strtol_l, Our, personal X-HELO: smtp-out-no.shaw.ca Received: from smtp-out-no.shaw.ca (HELO smtp-out-no.shaw.ca) (64.59.134.9) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Jul 2017 20:50:57 +0000 Received: from [192.168.1.100] ([24.64.240.204]) by shaw.ca with SMTP id bCDmd2fchI8mCbCDndznbe; Fri, 28 Jul 2017 14:50:55 -0600 X-Authority-Analysis: v=2.2 cv=HahkdmM8 c=1 sm=1 tr=0 a=MVEHjbUiAHxQW0jfcDq5EA==:117 a=MVEHjbUiAHxQW0jfcDq5EA==:17 a=IkcTkHD0fZMA:10 a=B2Xa_oYSFZbDXVt5QqoA:9 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> <9c38bcee-fbb0-9a30-0c28-58629f54aa0e@SystematicSw.ab.ca> <20170726104918.GF14419@calimero.vinschen.de> <6ae417fd-e109-4549-f005-5cfa7b6fdb62@SystematicSw.ab.ca> <20170726193443.GD30367@calimero.vinschen.de> From: Brian Inglis Message-ID: Date: Fri, 28 Jul 2017 20:50: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: <20170726193443.GD30367@calimero.vinschen.de> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-CMAE-Envelope: MS4wfKOJciDkr/d8/ynGIrSVbuWx2MZiciGf3fUpIKxsykFtbRPP142jLJvzvl9McnrcYYZYnSwHftSXeGmAnUY2Oiz5/8GzCJlMQenUgtQHsOoQJ648iBmQ uE+DKxsajpFGUePYNWO0AGZqcavE7j5g3JPw3xP4W1YbnnuC2sf+c/294IB6BwRkxBvPjdVdjSdqIg== X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00695.txt.bz2 On 2017-07-26 13:34, Corinna Vinschen wrote: > 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. Finally got all the prereqs installed and a clean build. My configure uses the default prefix /usr/local, which is at the head of my personal path. Is that enough for a test build, and how do I do that, or do I have to replace the current release, with configure --prefix=/, make install into /bin/? -- Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada