[llvm-bugs] [Bug 39069] Non-const extern successfully link with const value

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=39069

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID
                 CC|                            |richard-llvm at metafoo.co.uk

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> ---
(In reply to Oleg Doronin from comment #0)
> For the code below, I get a link error for compiler msvc on Windows, but
> clang on Linux successfully compiles, but when I run the executable I get
> segfault. Is this behavior correct?

Yes.

>   3. I opened the ELF format document and found no information about how to
> differentiate between const and non-const.

There is no relevant difference, neither in ELF nor in the name mangling scheme
used on Linux.

>   4. At the same time msvc compiler is able to specify additional
> information for extern const

The name decoration scheme used on Windows includes the type of a global
variable as part of its name, which is why you happen to get a link error
there.

> Can anyone explain in more detail why this is so done, not the other way
> around?

Your program is ill-formed, with no diagnostic required, due to the type
mismatch between the declaration and definition of A. That means that anything
can happen -- the program can be rejected by the linker, or crash, or appear to
"work", or something else.

The name mangling scheme used on Linux only attempts to distinguish entities
where both can validly appear in the same program. As a result, it does not
include extraneous information such as the return type of a non-template
function or the type of a global variable, and cannot detect programming errors
such as this.

The name decoration scheme used on Windows includes more information in cases
like this, allowing it to detect bugs such as the one in your program (at the
cost of making symbol names more complex).

So this is all working as it should.

(For your future reference, requests for information such as "can someone
explain what's going on here" where you're not sure there's a bug are often
better suited for mailing list discussions rather than as bug reports -- the
cfe-dev list would have been a good choice for this query.)

-- 
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/20180925/1609068f/attachment-0001.html>