jyknight added a comment.

In https://reviews.llvm.org/D42933#1090384, @jfb wrote:

> In https://reviews.llvm.org/D42933#1090286, @smeenai wrote:
>
> > I'd be fine with adding an option to relax the printf checking if the size 
> > and alignment of the specifier and the actual type match, even if the types 
> > themselves differ (`-Wformat-relaxed` or something similar), so that you'd 
> > still get warnings on cases where the specifier mismatch could cause 
> > runtime issues.
>
>
> What are the cases that you're worried about? The only ones I'm trying to 
> capture here are `NSInteger` with `%zd` and `NSUInteger` with `%zu`, are 
> there others?
>
> > I think that would be preferable to special-casing the Apple types.
>
> If there are more that should be captured and a similar point solution 
> doesn't apply, agreed. However I'd like to understand if we agree on the 
> guarantees that the platform offers for the two specific cases I'm targeting.


I also think that special casing these two specifiers doesn't make sense. The 
problem is a general issue -- and one I've often found irritating. This exact 
same situation comes up all the time in non-Darwin contexts too.

E.g. one I find particularly annoying is "%lld" vs "%ld" in printf.

Some 64-bit platforms define e.g. `int64_t` as `long long`, and others as 
`long`. Although both types are size 8, align 8, and mean exactly the same 
thing, they are still distinct. And so, users write code like `int64_t x = 0; 
printf("%ld", x);`...which then emits warnings on the platform that defines 
int64_t as a `long long`. Obviously, the code _could_ be using `PRId64` 
instead...but it often doesn't. So it'd sure be nice if you could restrict the 
warning to only warn about actual problems, and suppress these 
superficially-incompatible-but-not-really warnings.

So, +1 from me for the general-purpose `-Wformat-relaxed` flag (or whatever 
other flag name is appropriate).


Repository:
  rC Clang

https://reviews.llvm.org/D42933



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

Reply via email to