From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 87109 invoked by alias); 1 Mar 2017 23:48:34 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 87031 invoked by uid 89); 1 Mar 2017 23:48:26 -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,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM,SPF_PASS autolearn=no version=3.3.2 spammy=deliberate X-HELO: mail-qk0-f178.google.com Received: from mail-qk0-f178.google.com (HELO mail-qk0-f178.google.com) (209.85.220.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 01 Mar 2017 23:48:21 +0000 Received: by mail-qk0-f178.google.com with SMTP id n186so95312982qkb.3 for ; Wed, 01 Mar 2017 15:48:10 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=QVITgpXarQpE8KuNho7Mt4N0vqYSw5YS/bShiCV/SDQ=; b=Us6EIUk2QxA0YBEQw08VOXroF7HV4JmAUiuqOWu/aLfIJ8+fkqYVaYgSexH02UizXW 4VXRps+s5MUWWvCSm+aM5hQzxGFfdFgd+mtm8JLG6qsvqc30JEIbseYfkXq68zd2wxOw oJjJaYzlCgDlCeG/mpzQPHQwm5QUCdnU7+E/2sly8xqKKCD2l/2d8qVtJBYwH0LTlZ2u 50MoWPt9kWzqGjceoQF1EqTZuXkwkifUt3hcwmxNZjNXR4naP6PQBbLSiL9w2u1NFOcf prHcmnGRtZqJoME9zuz+Wv4KcorPx36nwIKTIORPjsEFBehFX3yQwxPBrIfjGvCf4aAh XapQ== X-Gm-Message-State: AMke39k7+/f3YOF4XUJ+wliNBPtETDYpD3nq2Da9nFrxaHWCK4QPZaScwBho//u4pbA/Fw== X-Received: by 10.200.53.237 with SMTP id l42mr13485467qtb.264.1488412088916; Wed, 01 Mar 2017 15:48:08 -0800 (PST) Received: from [192.168.0.3] (75-166-126-106.hlrn.qwest.net. [75.166.126.106]) by smtp.gmail.com with ESMTPSA id f126sm4203210qkc.47.2017.03.01.15.48.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 01 Mar 2017 15:48:08 -0800 (PST) From: Martin Sebor Subject: Re: [PATCH] avoid using upper bound of width and precision in -Wformat-overlow (PR 79692) To: Jeff Law , Gcc Patch List References: <6ced17e1-aa9d-d7cd-92f7-debabe7c6050@gmail.com> <623e38f3-8d0f-0866-87ce-d005ad0613f8@redhat.com> Message-ID: <8c32721d-1d60-4d4c-e71f-260705f85977@gmail.com> Date: Wed, 01 Mar 2017 23:48:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0 MIME-Version: 1.0 In-Reply-To: <623e38f3-8d0f-0866-87ce-d005ad0613f8@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2017-03/txt/msg00060.txt.bz2 > So in some cases you use > > + /* For an indeterminate precision the lower bound must be assumed > + to be zero. */ > + if (prec[0] < 0 && prec[1] >= 0) > > Note prec[1] >= 0 > > In other cases you have: > > + /* The minimum output with unknown precision is a single byte > + (e.g., "0") but the more likely output is 3 bytes ("0.0"). */ > + if (dir.prec[0] < 0 && dir.prec[1] > 0) > > Note dir.prec[1] > 0 > > Shouldn't one of those be changed to be consistent with the other? Thanks for the careful review! The two tests determine two different things so I'm not sure they need to be consistent. But considering your question made me realize that the first conditional isn't completely correct: + /* For an indeterminate precision the lower bound must be assumed + to be zero. */ + if (prec[0] < 0 && prec[1] >= 0) + prec[0] = 0; Precisions in a negative-positive range with an upper bound of less than 6 must be assumed to have an upper bound of 6 because that's the default when precision is negative. E.g., given snprintf (0, 0, "%*f", p, 1.23456789) where p is in [-1, 0] results either in: 1.234568 when (p == -1) holds, or in: 1 when (p == 0) holds. So while the lower bound in the if statement above must be set to zero, the upper bound may need to be adjusted as well. The patch I just committed in r245822 fixes that (and also changes the conditional so that consistency is no longer an issue). However, while reviewing the rest of the floating point handling code it became clear that this is a bug that affects both floating point formatting functions (i.e., the one that handles constants as well as the non-constant one). I also noticed some other minor glitches in this area that should be fixed. I'm testing another patch that resolves those problem as well. > Similarly in known_width_and_precision. Please review the patch to > ensure that we're as consistent as possible for these tests. In known_width_and_precision the different inequalities are deliberate. Because the actual width is an absolute value of the specified argument the range of unknown width is [0, INT_MAX + 1] (printf("%*i", INT_MIN, i) specifies a width of -INT_MIN, or INT_MAX + 1 (without overflow). But because negative precisions are ignored, the largest upper bound is INT_MAX. Martin