From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18720 invoked by alias); 23 Aug 2016 03:25:24 -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 18653 invoked by uid 89); 23 Aug 2016 03:25:11 -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,SPF_PASS autolearn=ham version=3.3.2 spammy=overcome, on-demand, ondemand, Beyond X-HELO: mail-yw0-f181.google.com Received: from mail-yw0-f181.google.com (HELO mail-yw0-f181.google.com) (209.85.161.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 23 Aug 2016 03:25:10 +0000 Received: by mail-yw0-f181.google.com with SMTP id z8so65107107ywa.1 for ; Mon, 22 Aug 2016 20:25:10 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=RzE8cR82noNwAeL4pIo+lgqiDYCRL7lgvH6fUJtuUeY=; b=DRd+MiHPj02n/dcHG7gJRwt3voXiudSzwWctu3gQgRSNIlvaIiOzj0G1noxauL27DB ofp9LD1rIEmiN/qCj/waAdfM30yh9j3YnfZUXJd0aWPXqoGLzpDiOQ7IxKYHPT2RS0Dc T9nNU+aTQPHyPCFgL+Oxt7l0RsRXqnW9A6GvxdAMos/IjSapeJG81tWFNsT54c5UEy5P 29KPXPyAqGn/soff4H/tzjsSg7FRmCIQbFFzOClZ5abOb64Ygjoc2D0Q2jn6xgFUXuE9 51DFetq6Pk7HHNW25Su9URpuC5R7MEuqz2rbDsVfILUlp7KdCdiK/+8hj8FmO+hHPWj+ BZ9Q== X-Gm-Message-State: AEkoouussF+dCRE5vZX7NXO8yxAgWO9chHWwndbM8e8k6+96XN0iFnnV6iJ3WHqqoXA1nA== X-Received: by 10.13.211.2 with SMTP id v2mr19049849ywd.230.1471922708782; Mon, 22 Aug 2016 20:25:08 -0700 (PDT) Received: from [192.168.0.26] (97-122-170-38.hlrn.qwest.net. [97.122.170.38]) by smtp.gmail.com with ESMTPSA id n18sm699788ywn.36.2016.08.22.20.25.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 22 Aug 2016 20:25:08 -0700 (PDT) Subject: Re: [PATCH] RFC: On-demand locations within string-literals To: David Malcolm , gcc-patches@gcc.gnu.org References: <1468014566-40305-1-git-send-email-dmalcolm@redhat.com> <5793E33F.2090305@gmail.com> <1469320654.29375.36.camel@redhat.com> From: Martin Sebor Message-ID: <57BBC213.2040006@gmail.com> Date: Tue, 23 Aug 2016 03:25:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: <1469320654.29375.36.camel@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01598.txt.bz2 >> Beyond that, the range normally works fine, except when macros >> are involved like they are in my tests. You can see the effect >> in the range.out file. (This works without your patch but it >> could very well be because I didn't set it up right.) > > Sadly I can't figure out what's going wrong - but the code's changed a > lot at my end since then. Sorry. I have integrated the latest (already committed) version of your patch into my -Wformat-length patch. Everything (well almost) works and I get nice ranges for the format string and for (some) arguments. I was surprised at how long it took me to switch from the previous implementation (also copied from c-format.c) to this new API. As before, I had to copy bits and pieces of code from other parts of the compiler to get it to work. I was also surprised at how complex making use of it is. It added 130 lines of code to the pass, which is 40 more than what I had before. It seems that the format_warning_at_substring function from c-format.c (perhaps generalized and with some reasonable defaults hardcoded) should be defined where other parts of GCC (including the middle end) can reuse it. I ran into a few minor glitches while testing it and I raised the following bugs for two of them: 77328 - incorrect caret location in -Wformat calling printf via a macro (this was pre-existing) 77331 - incorrect range location in -Wformat with a concatenated format literal (this is new) The third issue seems like a limitation that I should be able to overcome but I couldn't figure out how using the new API. The problem is that there doesn't seem to be a way to point the caret at the closing quote of a string, like for example in the following test. Even though by default the whole string is underlined (and the caret points to the opening quote), there doesn't seem to be a way to specify a range where the caret points to the other quote. It's no big deal and I only noticed it because one of my tests started failing, but it seems like it should be possible. $ cat t.c && /build/gcc-49905/gcc/xgcc -B /build/gcc-49905/gcc -S -Wformat t.c char d [2]; void f (void) { __builtin_sprintf (d, "%sX", "1"); } t.c: In function ‘f’: t.c:5:25: warning: writing a terminating nul past the end of the destination [-Wformat-length=] __builtin_sprintf (d, "%sX", "1"); ^~~~~ What I would like to see is similar to what I get when one of the format string characters is written past the end: t.c:5:30: warning: writing format character ‘Z’ at offset 4 past the end of the destination [-Wformat-length=] __builtin_sprintf (d, "%sXYZ", ""); ^ Martin