From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125236 invoked by alias); 7 Jan 2019 09:26:44 -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 125211 invoked by uid 89); 7 Jan 2019 09:26:44 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-10.1 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KAM_COUK,KAM_LAZY_DOMAIN_SECURITY autolearn=ham version=3.3.2 spammy=mseborgmailcom, msebor@gmail.com, mikestumpcomcastnet X-HELO: smtp1.wavenetuk.net Received: from smtp.wavenetuk.net (HELO smtp1.wavenetuk.net) (195.26.36.10) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 07 Jan 2019 09:26:40 +0000 Received: from euterpe-sie.home (host81-138-1-83.in-addr.btopenworld.com [81.138.1.83]) by smtp1.wavenetuk.net (Postfix) with ESMTPA id 0206112017BB; Mon, 7 Jan 2019 09:26:37 +0000 (GMT) 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: <534c6815-7b42-522d-1974-23c5b1593fa2@gmail.com> Date: Mon, 07 Jan 2019 09:26:00 -0000 Cc: "gcc-patches@gcc.gnu.org" , Mike Stump Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F4803D9-451F-4DFC-AC93-CDA68F742693@comcast.net> <4E249F38-0BA6-4937-BFBC-22D4D93331A3@googlemail.com> <338aa29f-9700-26d5-909b-c7cdc2f3cdd4@gmail.com> <576B95E8-3086-426B-BFDC-EB98793713F3@googlemail.com> <534c6815-7b42-522d-1974-23c5b1593fa2@gmail.com> To: Martin Sebor X-SW-Source: 2019-01/txt/msg00280.txt.bz2 > On 6 Jan 2019, at 23:34, Martin Sebor wrote: >=20 > Attached is an updated patch with the wording change to the manual > discussed below and rebased on the top of today's trunk. Works for me as well. thanks for the patch. Iain >=20 > Martin >=20 > PS Thanks for the additional info, Iain. >=20 > On 1/5/19 10:53 AM, Iain Sandoe wrote: >>> 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= and 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 = @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 par= sed for correct syntax >>>>>> -and format argument types. However, parsing of the format string i= tself 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 supp= ort >>>>>> +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 a= nd >>>>>> +validating arguments against it in calls to such functions is curre= ntly >>>>>> +not performed. >>>>>> Additionally, @code{CFStringRefs} (defined by the @code{CoreFound= ation} headers) may >>>>>> also be used as format arguments. Note that the relevant headers a= re only likely to be >>>>>>=20 >>>> I find =E2=80=9Carchetype(s)=E2=80=9D to be an usual (and possibly unf= amiliar 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 bike= shedding 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 = meaning =E2=80=A6 however couldn=E2=80=99t think of >> 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. i= t should be able >> to contain a variety of string formats (e.g. UTF etc.). AFAIR at the t= ime 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 = (although honestly >> it=E2=80=99s been a while, I maybe mis-remember) that was the reason I d= idn=E2=80=99t try to implement the >> inspection at the time (if so, there=E2=80=99s probably a code comment t= o that 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=9Csyst= em compiler" (last edition >> apple 4.2.1) and I therefore assume it=E2=80=99s used by clang - but ac= tually 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 wi= th 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 s= upported by the CoreFoundation (C) >> classes as well as ObjectiveC .. making it possible to pass around gener= al string containers between >> the languages. >=20 >