From owner-freebsd-hackers@freebsd.org Tue Jan 23 08:41:38 2018 Return-Path: Delivered-To: freebsd-hackers@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 093F0EBE8F9 for ; Tue, 23 Jan 2018 08:41:38 +0000 (UTC) (envelope-from yuripv@icloud.com) Received: from pv33p00im-asmtp003.me.com (pv33p00im-asmtp003.me.com [17.142.194.252]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id CBE346CF61 for ; Tue, 23 Jan 2018 08:41:37 +0000 (UTC) (envelope-from yuripv@icloud.com) Received: from process-dkim-sign-daemon.pv33p00im-asmtp003.me.com by pv33p00im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) id <0P2Z00L00SKL7K00@pv33p00im-asmtp003.me.com> for freebsd-hackers@freebsd.org; Tue, 23 Jan 2018 05:37:08 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=icloud.com; s=04042017; t=1516685828; bh=IDp+F9eUOuPodPWkEJKNExLxzE4w3VnNYHrWUDBF8L0=; h=Subject:From:To:Message-id:Date:MIME-version:Content-type; b=E8039XoqL6oXR5klmKcg9YotJVrNaL0hDagjQl6hYF86IRFRbq9zWIHlF2Lfuk5OY 4eZjXwpxbZWw3CzWNqXnSXg5CAbSazfmX7XENXJgzUyKWrElS9SCkG9ypAR7hhFcoo VRJg0t7FWGazKQo1fPWGBQG7pY0j5iqcMrNzv0hNmego2wMKbYgB/8WB+9GpVAT5F8 wILamBg+k5y93T4335nBk5GWf5XEHRtdyFod1nCMwd3liIC8BB9pgbuIBP1Qvj68ON M48tv/UL67vDKqmBaAuHOexFwg69QN0SH2hsHWHBWg+1xgTedCl79zAJ8EdkFc+VoR cn3Ud3xBIa/AQ== Received: from icloud.com ([127.0.0.1]) by pv33p00im-asmtp003.me.com (Oracle Communications Messaging Server 8.0.1.2.20170607 64bit (built Jun 7 2017)) with ESMTPSA id <0P2Z00DBIU9OLM20@pv33p00im-asmtp003.me.com> for freebsd-hackers@freebsd.org; Tue, 23 Jan 2018 05:37:07 +0000 (GMT) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:,, definitions=2018-01-23_02:,, signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 clxscore=1015 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1707230000 definitions=main-1801230078 Subject: Re: libc/regex: r302824 added invalid check breaking collating ranges From: Yuri Pankov To: freebsd-hackers References: Message-id: Date: Tue, 23 Jan 2018 08:36:59 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-version: 1.0 In-reply-to: Content-type: text/plain; charset=utf-8; format=flowed Content-language: en-US Content-transfer-encoding: 7bit X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Jan 2018 08:41:38 -0000 On Tue, Jan 23, 2018 at 03:53:19AM +0300, Yuri Pankov wrote: > (CCing Kyle as he's working on regex at the moment and not because he > broke something) > > Hi, > > r302284 added an invalid check which breaks collating ranges: > > -if (table->__collate_load_error) { > - (void)REQUIRE((uch)start <= (uch)finish, REG_ERANGE); > +if (table->__collate_load_error || MB_CUR_MAX > 1) { > + (void)REQUIRE(start <= finish, REG_ERANGE); > > The "MB_CUR_MAX > 1" is wrong, we should be doing proper comparison > according to current locale's collation and not simply comparing the > wchar_t values. After re-reading the specification I now see that what looked like a bug is actually an implementation choice, though the one that needs to be documentated. I'll update the man page if anyone is willing to review (and commit) the changes.