What is the behavior if the program invokes an external entity

[xmh0511]

Full name of submitter (unless configured in github; will be published with the issue): Jim X

Since [lex.phases] p1.9 says:

All external entity references are resolved. Library components are linked to satisfy external references to entities not defined in the current translation.

and [dcl.link] says we can link to that entity. Consider this case:

extern "C"{
   void fun();
}
int main(){
 fun(); // #1
}

// impl.S
.globl _fun
_fun:
    ret

What's the behavior at #1? Is it implementation-defined or unspecified behavior, or just UB? Because this is a well-formed program, according to [intro.abstract] p5, it must have some observable behaviors. However, the current standard says nothing in this case.

Suggested Resolution

[dcl.link] p10 may be changed to cover this case

Linkage from C++ to objects/functions defined in other languages and to objects/functions defined in C++ from other languages is implementation-defined and language-dependent.

Then, the implementation should be responsible for telling the complete story.

[jensmaurer]

(I'm not introducing new worlds of documentation requirements for implementations in a core issue. If you want that, please write a paper. Some things are not specified by the C++ standard (e.g. name mangling and calling conventions), and the absence of such is not a defect, but an intentional limitation of scope.)

Note that the name mangling is not specified in the C++ standard, so it's not specified whether the _fun defined in impl.S would actually link against the 'extern "C"' fun you're referring to in C++.

(For example, on my Linux box, I get "undefined reference to `fun'" when trying to compile your example.)

[languagelawyer]

@jensmaurer but since it is about linkage, I think [dcl.link]/10 should say «entities» instead of «objects». Looks editorial enough?

[xmh0511]

Note that the name mangling is not specified in the C++ standard, so it's not specified whether the _fun defined in impl.S would actually link against the 'extern "C"' fun you're referring to in C++.

This is exactly the domain of implementation-defined behavior. So, I think the [dcl.link] should also say the linage for functions is also implementation-defined.

[jensmaurer]

Changing [dcl.link] p10 doesn't quite fit, because the second sentence specifically explains why sharing objects between language might be hard. (In contrast, calling a foreign-language function with scalar parameters is probably much easier to make work.)

[opensdh]

The case with impl.S is simply not a C++ program, since it's not a set of translation units ([basic.link]/1). The standard library is simply described as providing declarations ([res.on.headers]/1 and something similar for modules) and magically joining the link ([using.linkage]/3 and the quoted [lex.phases]/9); we could extend [lex.phases]/9 to allow the "this is a program" interpretation with something about implementation-defined additional (translated) translation units.