[llvm-bugs] [Bug 44995] New: %ll should not trigger -Wformat with int64_t on 64-bit Linux

[via llvm-bugs]

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: unassignedclangbugs at nondot.org
          Reporter: husseydevin at gmail.com
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20200222/76129ad1/attachment.html>