[PATCH] D103426: Clang: Extend format string checking to wprintf/wscanf

[Tom Honermann via Phabricator via cfe-commits]

tahonermann added inline comments.


================
Comment at: clang/lib/AST/Type.cpp:1962
 
+bool Type::isType(const std::string TypeName) const {
+  QualType Desugar = this->getLocallyUnqualifiedSingleStepDesugaredType();
----------------
MarcusJohnson91 wrote:
> efriedma wrote:
> > MarcusJohnson91 wrote:
> > > aaron.ballman wrote:
> > > > Oh, I see now that this is doing a name comparison against the type -- that's not a good API in general because it's *really* hard to guess at what the type will come out as textually. e.g., `class` and `struct` keywords are interchangeable in C++, C sometimes gets confused with `bool` vs `_Bool`, template arguments sometimes matter, nested name specifiers, etc. Callers of this API will have to guess at these details and the printing of the type may change over time (e.g., C may switch from `_Bool` to `bool` and then code calling `isType("_Bool")` may react poorly to the change).
> > > > 
> > > > I think we need to avoid this sort of API on `Type`.
> > > I see your point, I reverted the behavior back to doing the desugaring in just isChar16Type and isChar32Type
> > I'm not convinced we should be looking at sugar even in isChar16Type/isChar32Type/isAnyCharacterType.  That seems like a great way to end up with subtle bugs that only manifest when someone uses the wrong typedef.
> > 
> > Where is the distinction between the value `(uint32_t)1` vs. `(char32_t)1` relevant for C, anyway?
> char32_t is a typedef, not a builtin type in C.
> 
> the underlying type is uint_least32_t, which is usually another typedef to int.
> 
> in order for char32_t to be accepted in C mode, we have to know that it is a string type and not just some random array, so I'm checking the sugar to see if char32_t appears in the typedef chain.
> 
> 
You can't, in general, count on typedefs being present.  For example, `U"text"` won't have `char32_t` present in its type; the `char32_t` typedef definition won't even be present if `uchar.h` is not included.  All you can be (reasonably) assured of is that UTF-16 and UTF-32 literals will have a type that matches the underlying type of the `char16_t` and `char32_t` typedef definition (this can be violated for at least some compilers if you try hard, but that reflects an invalid configuration).


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D103426/new/

https://reviews.llvm.org/D103426