From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95212 invoked by alias); 5 Jan 2019 17:39:10 -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 95199 invoked by uid 89); 5 Jan 2019 17:39:09 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=msebor@gmail.com, mseborgmailcom, mikestumpcomcastnet, mikestump@comcast.net X-HELO: mail-qt1-f194.google.com Received: from mail-qt1-f194.google.com (HELO mail-qt1-f194.google.com) (209.85.160.194) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 05 Jan 2019 17:39:07 +0000 Received: by mail-qt1-f194.google.com with SMTP id p17so43704068qtl.5 for ; Sat, 05 Jan 2019 09:39:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=wyjaEwK5Ax/xlTJzn/fCNrcBhhzlbeUU8i95/9F5o3c=; b=RayPNhX94ygAcrG0ZgM8YcRPTpOQ2XDKGWBqXy/GWW69BUUPGfHu9aFJRHEnnARnWu ts+fj4fJtbvOuB2pPkXZqDeMvFZ7Y4ONXPS6FZk7jGElEwtHfbLMDqf298NUvj0pqAa8 dJF3tpgcspv/BeWsVILezVT9aldLbOtJ+H/z72RALootZDWWO4tOfL5Pd/IAB4gDgd5y mnZNnF50Xn5AFnQkYIVRwaw5yiBZTuEHPudBfjTbgil8ZeG+wITWsSsi+cP6gMBBVeaf MDNLNkIURVVn1WhAvRxSdzWMmF8aQ1kKw+tfpG3q8b4e26Udd38PRmwmkGAozW6XZWUM cwqQ== Return-Path: Received: from [192.168.0.106] (174-16-101-177.hlrn.qwest.net. [174.16.101.177]) by smtp.gmail.com with ESMTPSA id w184sm31320501qkw.90.2019.01.05.09.39.03 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Jan 2019 09:39:04 -0800 (PST) Subject: Re: [PATCH] restore CFString handling in attribute format (PR 88638) To: Iain Sandoe Cc: "gcc-patches@gcc.gnu.org" , Mike Stump References: <7F4803D9-451F-4DFC-AC93-CDA68F742693@comcast.net> <4E249F38-0BA6-4937-BFBC-22D4D93331A3@googlemail.com> From: Martin Sebor Message-ID: <338aa29f-9700-26d5-909b-c7cdc2f3cdd4@gmail.com> Date: Sat, 05 Jan 2019 17:39:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.3.1 MIME-Version: 1.0 In-Reply-To: <4E249F38-0BA6-4937-BFBC-22D4D93331A3@googlemail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00216.txt.bz2 On 1/5/19 3:31 AM, Iain Sandoe wrote: > Hi Martin, > >> On 4 Jan 2019, at 22:30, Mike Stump wrote: >> >> On Jan 4, 2019, at 2:03 PM, Martin Sebor wrote: >>> >>> The improved handling of attribute positional arguments added >>> in r266195 introduced a regression on Darwin where attribute >>> format with the CFString archetype accepts CFString* parameter >>> types in positions where only char* would otherwise be allowed. >> >> You didn't ask Ok? I'll assume you want a review... The darwin bits and the testsuite bits look fine. > >>> >>> Index: gcc/doc/extend.texi >>> =================================================================== >>> --- gcc/doc/extend.texi (revision 267580) >>> +++ gcc/doc/extend.texi (working copy) >>> @@ -22368,10 +22368,12 @@ bit-fields. See the Solaris man page for @code{cm >>> @node Darwin Format Checks >>> @subsection Darwin Format Checks >>> >>> -Darwin targets support the @code{CFString} (or @code{__CFString__}) in the format >>> -attribute context. Declarations made with such attribution are parsed for correct syntax >>> -and format argument types. However, parsing of the format string itself is currently undefined >>> -and is not carried out by this version of the compiler. >>> +In addition to the full set of archetypes, Darwin targets also support >>> +the @code{CFString} (or @code{__CFString__}) archetype in the @code{format} >>> +attribute. Declarations with this archetype are parsed for correct syntax >>> +and argument types. However, parsing of the format string itself and >>> +validating arguments against it in calls to such functions is currently >>> +not performed. >>> >>> Additionally, @code{CFStringRefs} (defined by the @code{CoreFoundation} headers) may >>> also be used as format arguments. Note that the relevant headers are only likely to be >>> > > I find “archetype(s)” to be an usual (and possibly unfamiliar to many) word for this context. > > how about: > > s/archetype in/variant for the/ > > and then > s/with this archetype/with this variant/ > > in the following sentence. > > However, just 0.02GBP .. (fixing the fails is more important than bikeshedding the wording). Thanks for chiming in! I used archetype because that's the term used in the attribute format specification to describe the first argument. I do tend to agree that archetype alone may not be sufficiently familiar to all users. I'm happy to add text to make that clear. Would you find the following better? In addition to the full set of format archetypes (attribute format style arguments such as @code{printf}, @code{scanf}, @code{strftime}, and @code{strfmon}), Darwin targets also support the @code{CFString} (or @code{__CFString__}) archetype... FWIW, I wanted to figure out how the CFString attribute made it possible to differentiate between printf and scanf (and the other) kinds of functions, for example, so I could add new tests for it, but I couldn't tell that from the manual. So I'm trying to update the text to make it clear that although CFString is just like the sprintf and scanf format arguments/archetypes, beyond validating declarations that use it, the attribute serves no functional purpose, so the printf/scanf distinction is moot. Out of curiosity, is the attribute used for function call validation by compilers other than GCC? I couldn't find anything online. Thanks again! Martin