Hello, Nathan,
On Jul 15, 2023, Nathan Sidwell <nat...@acm.org> wrote:
> Not commenting on the semantics, but the name seems unfortunate (hello
> bikeshed).
Yeah, it's a bit challenging to express the concept, when the notion of
"alias" is kind of symmetric between decl and target, but the
previously-implemented extension attaches it to decl rather than to
target. I tried "extra alias" before, but that didn't fly either.
Maybe I should give up and just recommend the use of asm ("name")
instead of allowing alternative names (AKA aliases, in the dictionary
sense; oh, the irony) to be introduced for a decl? Maybe that would be
simpler and enough to sidestep the problem of varying mangled names when
trying to import into Ada (or defining C++ aliases for) C++ symbols that
use standard types in signatures that are not fundamental types, such as
size_t. That they mangle differently depending on what size_t is
typedef'ed to makes for some undesirable inconvenience, which this
attribute attempts to alleviate.
> The documentation starts with 'attribute causes @var{name}
> to be emitted as an alias to the definition'. So not emitting a
> 'reverse alias', whatever that might be.
It's reverse in that it doesn't alias another declaration, as in the
preexisting meaning of the alias attribute, it adds an alias for the
present declaration.
> It doesn;t seem to mention how reverse alias differs from 'alias'.
> Why would 'alias' not DTRT?
contrast:
int foo();
int __attribute__ ((alias ("foo"))) bar();
static_assert (&foo == &bar); // ok
with:
int __attribute__ ((reverse_alias ("bar"))) foo();
static_assert (&foo == &bar); // error, bar is not a C++ symbol
int __attribute__ ((alias ("bar"))) baz(); // ok
static_assert (&foo == &baz); // ok
asm (".quad bar"); // ok, even in other TUs
asm (".quad foo"); // not necessarily ok, foo's symbol may be mangled
asm (".quad baz"); // not necessarily ok, baz's symbol may be mangled
> Is is emitting a an additiona symbol -- ie, something like 'altname'.
Yup. Is there precedent for this attribute name elsewhere? I think it
could work.
> Is that symbol known in the current TU, or other TUs?
Only in the assembly/linker name space, not in any C++ namespace.
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>
