Re: [PATCH] restore CFString handling in attribute format (PR 88638)

[Martin Sebor <msebor@gmail.com>]

On 1/5/19 3:31 AM, Iain Sandoe wrote:
> Hi Martin,
> 
>> On 4 Jan 2019, at 22:30, Mike Stump <mikestump@comcast.net> wrote:
>>
>> On Jan 4, 2019, at 2:03 PM, Martin Sebor <msebor@gmail.com> 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