aaron.ballman added a comment. In D132266#3739542 <https://reviews.llvm.org/D132266#3739542>, @inclyc wrote:
> In D132266#3739513 <https://reviews.llvm.org/D132266#3739513>, @aaron.ballman > wrote: > >> Thanks for working on this @nickdesaulniers! I think we actually want to go >> a slightly different direction than this and disable the diagnostics >> entirely. Basically, we should be make sure the format specifier diagnostics >> are accounting for the clarifications in >> https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2562.pdf. So the `h` and >> `hh` modifiers would not even be pedantic warnings in this case. >> >> This should also have a release note associated with it and if you think >> you've completed support for N2562, the clang/www/c_status.html page should >> update the `Partial` markings. > > Sorry, I have some questions about this clarification agreement (currently > working on N2562). The length modifier `hh` says in the standard that it > should point to `signed char` or `unsigned char`, and if an `int` parameter > is passed, why shouldn't we give such a warning? (even if it's pedantic > somehow) That's for the `fscanf` functionality, which is different than the `fprintf` functionality that's being addressed here. We should be diagnosing the `fscanf` type mismatch cases, per 7.23.6.2p12: "In the following, the type of the corresponding argument for a conversion specifier shall be a pointer to a type determined by the length modifiers, if any, or specified by the conversion specifier." Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D132266/new/ https://reviews.llvm.org/D132266 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
