Bug 83749 - Types with different language linkage are treated as equivalent types
Summary: Types with different language linkage are treated as equivalent types
Status: RESOLVED DUPLICATE of bug 2316
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 7.2.1
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-01-09 09:15 UTC by dan.cermak
Modified: 2024-02-09 01:15 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description dan.cermak 2018-01-09 09:15:40 UTC
g++ has an inaccuracy when following the C++03 standard concerning the equality of types with different linkage. Section 7.5.1 states that: "Two function types with different language linkages are distinct types even if they are otherwise identical.".

Then the following code snippet should not compile:
~~~~~~~~~~~~~~~~~~~~~~~~{.cpp}
extern "C" void (*const interruptVectors[])();

typedef void (*ISR_t)(void);

static ISR_t* source_vector_table = const_cast<ISR_t*>(interruptVectors);
~~~~~~~~~~~~~~~~~~~~~~~~
Although interruptVectors is of type const ISR_t* it has C linkage, thus the types should be different and the const_cast should not work.

I have discovered this behavior when compiling a code base with TI's ARM compiler which choked on the aforementioned snippet. A TI employee then referred me to the C++03 standard (https://e2e.ti.com/support/development_tools/compiler/f/343/t/654558), which seems to back the compiler's behavior.
Comment 1 Marc Glisse 2018-01-09 10:42:51 UTC
See PR2316. Don't hold your breath for a change, it is more likely that the standard will eventually be changed to allow the current behavior.
Comment 2 dan.cermak 2018-01-09 11:49:00 UTC
Well I don't mind the current behavior at all and to be honest I find it more logical that way, so I would welcome a change in the standard.

Should I then close this bugreport or keep it open for further reference?
Comment 3 Jonathan Wakely 2018-01-09 12:04:36 UTC
It's a duplicate of PR 2316.

*** This bug has been marked as a duplicate of bug 2316 ***