lebedev.ri added a comment.

In D66186#1631921 <https://reviews.llvm.org/D66186#1631921>, 
@Nathan-Huckleberry wrote:

> In D66186#1630427 <https://reviews.llvm.org/D66186#1630427>, @aaron.ballman 
> wrote:
>
> > There was a request in the linked bug for some code archaeology to see why 
> > this behavior exists in the first place. What were the results of that? I'm 
> > not opposed to the patch, but I would like to understand why it behaves the 
> > way it does.
>
>
> Since printf is a variadic function, integral argument types are promoted to 
> int. The warning code runs the matchesType check twice, once to check if the 
> promoted type (int) is able to be printed with the format and once to check 
> if the original type (char) is able to be printed with the format.
>
> `printf("%d", [char])` is caught by the first case
>  `printf("%hhd", [char])` is caught by the second case.
>
> `printf("%hd", [char])` is a warning because an exception has not been made 
> for that case.


That explains what the implementation does, but does not attempt to answer the 
question *why* things are the way they are.

I read https://bugs.llvm.org/show_bug.cgi?id=41467#c4 as

- any narrowing is always diagnosed
- promotion to wider than int is diagnosed
- passthrough is not diagnosed
- promotion to something smaller than int is diagnosed (the current case)

I can interpret it as: we already know that

In D66186#1631921 <https://reviews.llvm.org/D66186#1631921>, 
@Nathan-Huckleberry wrote:

> Since printf is a variadic function, integral argument types are promoted to 
> int.


therefore why are you first implicitly promoting to int and then implicitly 
truncating?
Did you mean to print the original value? Did you mean to print int?

That doesn't sound too outlandish to me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66186



_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to