From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mimir.eigenstate.org ([206.124.132.107]) by ewsd; Sat May 9 18:14:03 EDT 2020 Received: from abbatoir.fios-router.home (pool-162-83-132-245.nycmny.fios.verizon.net [162.83.132.245]) by mimir.eigenstate.org (OpenSMTPD) with ESMTPSA id 9c694f33 (TLSv1.2:ECDHE-RSA-AES256-SHA:256:NO); Sat, 9 May 2020 15:13:45 -0700 (PDT) Message-ID: To: telephil9@gmail.com, ori@eigenstate.org, 9front@9front.org Subject: Re: [9front] Re: [PATCH] fix APE sscanf [ specifier Date: Sat, 9 May 2020 15:13:44 -0700 From: ori@eigenstate.org In-Reply-To: <234E94F01BC6BF327EF85739F792DF2B@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit List-ID: <9front.9front.org> List-Help: X-Glyph: ➈ X-Bullshit: non-blocking configuration configuration high-performance optimizer > Hi, > > Thank you for the feedback Ori. > >> Looks good to me -- will commit. Note, this still isn't fully up to >> spec, since it should in theory handle length modifiers for unicode, >> but I think it covers everything we're likely to see. > > Regarding unicode you are right, but you surely have noted that our versions of vfscanf are not unicode aware at all. At least, this is document in the manual (see BUGS in sscanf(2)). > > Below is a new version of the patch that includes a fix for an additionnal issue found with %n directive this time. > vfscanf is returning as soon as it reaches the end of the input stream which will prevent any trailing %n directives from being processed. > This bug can be observed in the following call: > sscanf("z", " %1[Zz] %n ", s, &n); > Here n will not be set as the %n directive is never reached. > Committed, thanks!