[cfe-commits] [patch] Added a suggestion when a std::string is passed to printf()

[Chandler Carruth]

On Mon, Jun 4, 2012 at 2:09 PM, Sam Panzer <panzer at google.com> wrote:

> Now I'm wondering how much of this behavior should be "string"-specific.
> If we're paying attention to conversion operators from non-POD types, why
> not check for all possible conversion operators? I think this is a better
> solution than checking to see if there's a conversion operator from the
> return type of a c_str() function.
>

I think conversion operators aren't really as interesting and at least
should be handled as a separate follow-on patch. I also think they're
completely uninteresting when considering the result of 'c_str()'. All of
the interesting cases actually return the character pointer we're looking
for.


>
> Not depending on std::string was the plan, and in fact how I implemented
> it :)
>
> On Mon, Jun 4, 2012 at 1:44 PM, Chandler Carruth <chandlerc at google.com>wrote:
>
>> On Mon, Jun 4, 2012 at 1:37 PM, Sam Panzer <panzer at google.com> wrote:
>>
>>> Here is one other question: With this patch, incorrectly passing an
>>> std::string to printf generates an error (can't pass non-POD member), a
>>> warning (printf format doesn't match), and a note (the c_str() suggestion).
>>> Is this the behavior we want?
>>
>>
>> I don't think so... Ideally:
>>
>> 1) If we are about to issue a an error (non-POD object passed through
>> printf), check whether the non-POD object has a 'c_str()' method that
>> returns a type which matches the format specifier. If so, use a specific
>> diagnostic message for the error, attach a fixit-hint suggesting
>> '.c_str()', and continue parsing as-if the user had done that.
>>
>> 2) If there is no error (passing a std::string* perhaps), then in the
>> warning message, give a more precise message than 'cannot convert
>> std::string* to const char*' or whatever by checking if there is a c_str()
>> method that matches the type of the printf.
>>
>>
>> One thing I would encourage you to do: don't base this on 'std::string'.
>> I actually think the error/warning should fire for any class type with a
>> c_str method that returns a viable type. That way non-standard string
>> libraries will get the same benefit if they conform the the same conceptual
>> interface as the standard string library.
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20120604/24bc7a26/attachment.html>