[PATCH] D132266: [Clang][SemaChecking] move %hh and %h -Wformat warnings to -Wformat-pedantic

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D132266#3740168 <https://reviews.llvm.org/D132266#3740168>, @inclyc wrote:

>> format specifies type 'short' but the argument has type 'double' (promoted from 'float')
>
> I'm not sure about this. I'm curious about we just consider any integer with width less than or equal to `int` may be specified by `%hhd` ? (Because of default argument promotions). For example, we may expect `%hhd` could accept `int` `short` and `char`.

I would expect those to *not* be diagnosed now. The goal of N2562 was to clarify that the default argument promotions happen and what causes UB is when there's a type mismatch after that promotion has taken place which would cause the value of the argument to be misinterpreted.  e.g., if you say it's a `char` and you pass an `int` or any integer type of less width than `int`, that's fine because `char` promotes to `int` anyway. But if you say it's a `char` and you pass it a `float`, that's UB.

> And give diagnostics like
>
>   format specifies integers with width less than or equal to 'int', but the argument has type 'double' (promoted from 'float')
>   
>   note: {info about why %hhd consumes argument like this}

I guess I'm not really picturing what you have in mind here.

>> fwprintf shall behave as if it uses va_arg with a type argument naming the type resulting from
>> applying the default argument promotions to the type corresponding to the conversion specification and
>> then converting the result of the va_arg expansion to the type corresponding to the conversion
>> specification.
>
>
>
> ---------
>
> OpenCL seems to defined a series of length modifiers for vectors, Is it more reasonable to consider `hh` as fixed length (char) only? Because vectors are passed without argument promotions.

I have not put a lot of thought into what should happen when passing a vector type. The standard is obviously silent on this situation since it doesn't admit vector types are a thing, what really matters is what common C standard library implementations do when given a vector type. If they do bad things (e.g., glibc works fine but MSVC CRT prints garbage) then we'll likely want to diagnose depending on the situation and the language options enabled.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D132266