From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21758 invoked by alias); 15 Jun 2017 09:05:16 -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 21744 invoked by uid 89); 15 Jun 2017 09:05:16 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=3.8 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,T_RP_MATCHES_RCVD,UNSUBSCRIBE_BODY autolearn=no version=3.3.2 spammy=Silviu, UD:dr1261.cc, _DTOA_R, 4402.cc X-HELO: foss.arm.com Received: from foss.arm.com (HELO foss.arm.com) (217.140.101.70) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 15 Jun 2017 09:05:14 +0000 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 1B3B780D for ; Thu, 15 Jun 2017 02:05:18 -0700 (PDT) Received: from [10.2.207.43] (e104453-lin.cambridge.arm.com [10.2.207.43]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id 985403F581; Thu, 15 Jun 2017 02:05:17 -0700 (PDT) Subject: Re: Fix modification of string literal by swprintf To: Thomas Preudhomme , newlib@sourceware.org References: <20170609133236.GA26770@calimero.vinschen.de> <59411888.2040202@arm.com> <2db7a6fb-4f43-da35-6f63-db52aa1bece8@foss.arm.com> From: Renlin Li Message-ID: <59424DCC.9000902@foss.arm.com> Date: Thu, 15 Jun 2017 09:05:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <2db7a6fb-4f43-da35-6f63-db52aa1bece8@foss.arm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017/txt/msg00429.txt.bz2 Yes, in my configuration, we enable the newlib-mb feature. And the executing path to handle the trailing '0' is not consistent with how the digits is handled. Thanks, Renlin On 15/06/17 09:00, Thomas Preudhomme wrote: > Hi Renlin, > > Here's Silviu's answer: > > "This happens when --enable-newlib-mb is used (which wasn't in my test configuration). > > Unfortunately this complicates thing a lot and I have no easy fix for it. > The best action at the moment would be a revert." > > Corinna, could you revert the patch for now? > > Sorry for the trouble. Best regards, > > Thomas > > On 14/06/17 12:05, Renlin Li wrote: >> Hi there, >> >> It seems this patch cause few regressions on arm/aarch64 baremetal targets. >> >> libstdc++-v3: >> FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/dr1261.cc execution test >> FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stof.cc execution test >> FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/to_wstring.cc >> execution test >> FAIL: 27_io/basic_ostream/inserters_arithmetic/wchar_t/4402.cc execution test >> >> newlib: >> FAIL: newlib.stdio/swprintf.c execution >> >> Regards, >> Renlin >> >> On 09/06/17 14:32, Corinna Vinschen wrote: >>> On Jun 8 13:15, Thomas Preudhomme wrote: >>>> Please find his updated patch attached. >>>> >>>> Best regards, >>>> >>>> Thomas >>> >>>> >From ee96a273969b0bccd308b81bcdf37a6fdefa06f6 Mon Sep 17 00:00:00 2001 >>>> From: Silviu Baranga >>>> Date: Mon, 5 Jun 2017 09:54:42 +0100 >>>> Subject: [PATCH] Don't overread or write memory returned by _DTOA_R >>>> >>>> Don't over-read memory returned by _DTOA_R, and never write to it >>>> since the result might be a string literal. >>>> >>>> For example, when doing: >>>> swprintf(tt, 20, L"%.*f", 6, 0.0); >>>> >>>> we will get back "0". >>>> >>>> Instead, write the result returned by _DTOA_R to the output buffer. >>>> After this, write the 0 chars directly to the the output buffer >>>> (if there are any). This also has the (marginal) advantage that >>>> we read/write less memory overall. >>> >>> Pushed. >>> >>> >>> Thanks, >>> Corinna >>>