https://bugs.llvm.org/show_bug.cgi?id=44995
Bug ID: 44995
Summary: %ll should not trigger -Wformat with int64_t on 64-bit
Linux
Product: clang
Version: 9.0
Hardware: Other
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Driver
Assignee: unassignedclangb...@nondot.org
Reporter: husseyde...@gmail.com
CC: llvm-bugs@lists.llvm.org, neeil...@live.com,
richard-l...@metafoo.co.uk
On Linux 64-bit, int64_t is defined as "long" to fit the ABI, and is a 64-bit
integer.
This is fine, as otherwise it would be bug 4192. int64_t is always 64 bits.
For printf, %ll is a common idiom to print a 64-bit long long int, and on all
current platforms, long long int is 64 bits.
#include <stdio.h>
#include <stdint.h>
int main(void)
{
int64_t x = 0x1234848943922;
printf("%016llx\n", x);
}
test.c:7:25: warning: format specifies type 'long long' but the argument has
type 'int64_t' (aka 'long') [-Wformat]
printf("%016llx\n", x);
~~~~~~~ ^
%016lx
1 warning generated.
Naturally, this code will always work on every major ABI unless someone decides
to break decades of working code with a weird RISCV128 ABI (which the ABI
proposal suggesting that it will not).
Is this REALLY worth a warning?
The diagnostic clearly knows the name of the typedef, so a special case could
be made (pseudocode, not going to look up the LLVM API because I will get lost
:P)
if (type.isTypedef() && type.typedefName().contains("int64") &&
type.sizeInBits() == longLongType.sizeInBits())
doNotWarn();
--
You are receiving this mail because:
You are on the CC list for the bug._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
