From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112300 invoked by alias); 5 Jan 2019 17:54:07 -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 112285 invoked by uid 89); 5 Jan 2019 17:54:06 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: =?ISO-8859-1?Q?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=haven, haven=e2, mold, didn?= X-HELO: mail-wr1-f67.google.com Received: from mail-wr1-f67.google.com (HELO mail-wr1-f67.google.com) (209.85.221.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 05 Jan 2019 17:54:04 +0000 Received: by mail-wr1-f67.google.com with SMTP id t6so39256801wrr.12 for ; Sat, 05 Jan 2019 09:54:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=m1YkT92rNH7GvSf970E1+AsMIozQsGKh/WRlYz/+DeU=; b=qqqXGjuJWyBjt0xJ7jxka6AJmtXBm+YgBnrQTFLOqifVuHRW7xrY9OKItyk4UNtLjv RY5UjLGd3jG6m/xtg1vi3TrExMUmZvDUzQY5t0DtmgRXOcedYMTD7GMoAYN5vYanEUrV gIIVvu5EN9oxNAaSAoihe3zsoLusnHIue9D6IGMgfKjKe1MqiYT657gQUczz8bzD5ufY MpuLkqFwqMhizhxbUlRv1bMJZqTMeFpBt5oVHN3UuRlsg3QMnrZLroQdRD63Jbl6/IcW UBol10KolZv5618O1RWJQXDu6ugisYDexsYmujPTIfXif3l0EmTFPOQL6jLs4B8S8TEF N/+g== Return-Path: Received: from euterpe-sie.home (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id t4sm53932934wrm.6.2019.01.05.09.54.00 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 05 Jan 2019 09:54:01 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) Subject: Re: [PATCH] restore CFString handling in attribute format (PR 88638) From: Iain Sandoe In-Reply-To: <338aa29f-9700-26d5-909b-c7cdc2f3cdd4@gmail.com> Date: Sat, 05 Jan 2019 17:54:00 -0000 Cc: "gcc-patches@gcc.gnu.org" , Mike Stump Content-Transfer-Encoding: quoted-printable Message-Id: <576B95E8-3086-426B-BFDC-EB98793713F3@googlemail.com> References: <7F4803D9-451F-4DFC-AC93-CDA68F742693@comcast.net> <4E249F38-0BA6-4937-BFBC-22D4D93331A3@googlemail.com> <338aa29f-9700-26d5-909b-c7cdc2f3cdd4@gmail.com> To: Martin Sebor X-SW-Source: 2019-01/txt/msg00219.txt.bz2 > On 5 Jan 2019, at 17:39, Martin Sebor wrote: >=20 > On 1/5/19 3:31 AM, Iain Sandoe wrote: >> Hi Martin, >>> On 4 Jan 2019, at 22:30, Mike Stump wrote: >>>=20 >>> On Jan 4, 2019, at 2:03 PM, Martin Sebor wrote: >>>>=20 >>>> 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. >>>=20 >>> You didn't ask Ok? I'll assume you want a review... The darwin bits a= nd the testsuite bits look fine. >>>>=20 >>>> Index: gcc/doc/extend.texi >>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D >>>> --- gcc/doc/extend.texi (revision 267580) >>>> +++ gcc/doc/extend.texi (working copy) >>>> @@ -22368,10 +22368,12 @@ bit-fields. See the Solaris man page for @c= ode{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 parse= d for correct syntax >>>> -and format argument types. However, parsing of the format string its= elf 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{f= ormat} >>>> +attribute. Declarations with this archetype are parsed for correct s= yntax >>>> +and argument types. However, parsing of the format string itself and >>>> +validating arguments against it in calls to such functions is current= ly >>>> +not performed. >>>> Additionally, @code{CFStringRefs} (defined by the @code{CoreFoundat= ion} headers) may >>>> also be used as format arguments. Note that the relevant headers are= only likely to be >>>>=20 >> I find =E2=80=9Carchetype(s)=E2=80=9D to be an usual (and possibly unfam= iliar 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 bikesh= edding the wording). >=20 > 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? >=20 > 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=E2=80=A6 Yes, that makes is clearer (as an aside, I think that to many people the meaning of archetype - as =E2= =80=98generic=E2=80=99 or =E2=80=98root example=E2=80=99 etc tends to come to mind before the =E2=80=98template/mold=E2=80=99 mea= ning =E2=80=A6 however couldn=E2=80=99t think of=20 a better term that=E2=80=99s not already overloaded). > 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. The CFString container** is more general than our implementation, e.g. it s= hould be able to contain a variety of string formats (e.g. UTF etc.). AFAIR at the time= I implemented it for FSF GCC (it was originally in the Apple Local branch), we didn=E2=80= =99t have sufficient parsing support for such things (and the support in the Apple-local branch didn=E2= =80=99t look applicable). If we do more sophisitcated checks, we probably need to take cognisance of = the fact that a fully-implemented CFString impl can have non-ascii payload. I suspect (al= though honestly it=E2=80=99s been a while, I maybe mis-remember) that was the reason I didn= =E2=80=99t try to implement the inspection at the time (if so, there=E2=80=99s probably a code comment to t= hat effect). > Out of curiosity, is the attribute used for function call > validation by compilers other than GCC? I couldn't find > anything online. It used to be used for the platform GCC, when that was the =E2=80=9Csystem = compiler" (last edition apple 4.2.1) and I therefore assume it=E2=80=99s used by clang - but actua= lly haven=E2=80=99t double-checked at the time we added it - it was relevant. Let=E2=80=99s revisit this in 10, and see if we can=E2=80=99t sync up with = the platform expectations from the clang impl. thanks for taking care of this, Iain ** it=E2=80=99s actually a simple ObjectiveC object that happens to be supp= orted by the CoreFoundation (C)=20 classes as well as ObjectiveC .. making it possible to pass around general = string containers between the languages.