mirror of
https://github.com/capstone-engine/llvm-capstone.git
synced 2025-04-18 06:10:37 +00:00
7525edc890
A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
11 lines
520 B
C
11 lines
520 B
C
// RUN: %clang_cc1 -x c -emit-llvm %s -o - -triple=i386-pc-win32 | FileCheck %s
|
|
// RUN: %clang_cc1 -x c -emit-llvm %s -o - -triple=x86_64-pc-win32 | FileCheck %s
|
|
|
|
void crbug857442(int x) {
|
|
// Make sure to handle truncated or padded literals. The truncation is only valid in C.
|
|
struct {int x; char s[2]; } truncatedAscii = {x, "hello"};
|
|
// CHECK: "??_C@_01CONKJJHI@he@"
|
|
struct {int x; char s[16]; } paddedAscii = {x, "hello"};
|
|
// CHECK: "??_C@_0BA@EAAINDNC@hello?$AA?$AA?$AA?$AA?$AA?$AA?$AA?$AA?$AA?$AA?$AA@"
|
|
}
|