<div class="gmail_quote">On Mon, Jun 4, 2012 at 1:37 PM, Sam Panzer <span dir="ltr"><<a href="mailto:panzer@google.com" target="_blank">panzer@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?</blockquote>
</div><br><div>I don't think so... Ideally:</div><div><br></div><div>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.</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><div>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.</div>