From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/172 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: cluts - numeric test expectations Date: Fri, 15 Jul 2011 09:36:21 -0400 Message-ID: <20110715133621.GQ16618@brightrain.aerifal.cx> References: <20110715033729.GP16618@brightrain.aerifal.cx> <4E202839.8030103@gmail.com> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: dough.gmane.org 1310737551 27764 80.91.229.12 (15 Jul 2011 13:45:51 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 15 Jul 2011 13:45:51 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-256-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jul 15 15:45:47 2011 Return-path: Envelope-to: gllmg-musl@lo.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by lo.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Qhii9-0003pb-Mu for gllmg-musl@lo.gmane.org; Fri, 15 Jul 2011 15:45:45 +0200 Original-Received: (qmail 9789 invoked by uid 550); 15 Jul 2011 13:45:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 9781 invoked from network); 15 Jul 2011 13:45:45 -0000 Content-Disposition: inline In-Reply-To: <4E202839.8030103@gmail.com> User-Agent: Mutt/1.5.21 (2010-09-15) Xref: news.gmane.org gmane.linux.lib.musl.general:172 Archived-At: On Fri, Jul 15, 2011 at 01:44:57PM +0200, Luka Marčetić wrote: > In short: I think, like Rich said, absolutely all "0x" tests should > point to 'x'. Any objections? Speak now or forever hold your peace*. I think this is correct. > >Tests which expect *endptr==str after overflow (ERANGE): I believe > >this expectation is incorrect, but glibc seems to disagree. I can't > >find any language in the standard to support the behavior explicitly, > >or to allow it as an interpretation. The definition of "subject > >sequence" makes no reference to the value having to fit in a > >certain-size integer type, > > Though I did remake ERANGE tests (see "> MAX" commit) with the > endptr-nptr offset strlen of nptr, I've now reviewed the case, and I > think it should still be endptr==nptr. There is no actual conversion > in my opinion: *_MAX returned value simply means out of scope. See > "Return value" section: "Upon successful completion, these functions > shall return the converted value". The reason I say it's not a > converted value is because successful completion it is not, see > "Errors" section: "These functions shall fail if: (...) [ERANGE] The I agree that the return value may not be a "converted value", but the text about endptr says nothing about whether a conversion took place. It merely says: If the subject sequence has the expected form...A pointer to the final string shall be stored in the object pointed to by endptr, provided that endptr is not a null pointer. The part I elided was about other behavior that happens when the subject sequence has the correct form (conversion and possible negation) but there's no text that makes storage to endptr being conditional on the outcome of that converstion (or conversion attempt). > > only that it belong to a clearly-defined > >regular language, e.g. /[-+]?(0x)?[[:xdigit:]]+/ for base==16. > > Is that your regexp or an official one (if there is such a thing)? > Because I think, in light of what you've said above regarding the > first issue, it might be wrong: Wouldn't this regexp greedily match > "0x" for you, instead of the shorter [[:xdigit:]], the latter of > which is alone of the "expected form"? It's mine, not official. You could probably derive the official one from some BNF or whatever they have in the C standard. Note however that the regex I gave does not match "0x" because [[:xdigit:]] has a + after it (1 or more occurrances). Thus in the case where no xdigits follow the 0x, the regex matcher would have to take the option of (0x)? matching "" (empty string) and the [[:xdigit:]] matching the "0". Rich