Does redefining a function from the standard library violate the one-definition rule?

Question

#include 

double log(double) {return 1.0;}
int main() {
  log(1.0);
}

Suppose the function log() in <

Answer 1

The following addresses a previous revision of the OP. I leave it here in case future readers come here with a similar query.

I guess that two names refer to the same entity if and only if they have the same declarative region, where the concept "declarative region" is defined in the standard [...] Is this guess correct? Is there any word in the standard supporting this?

It's called variable hiding or shadowing colloquially. And the standard says what you said almost verbatim. §3.3.10 ¶1 in the current C++17 standard draft:

A name can be hidden by an explicit declaration of that same name in a nested declarative region or derived class

---

So does this code violate the one-definition rule (see here, since no diagnostic required, this code may compile in some compiler and we cannot assert it is correct)?

I won't expect it to. The standard requires that all cheader headers (and in particular cmath) introduce their symbols in the std namespace. An implementation that also pours it into the global namespace is standard conforming (since the standard leaves that bit as unspecified), but I would find in bad form. You are correct that it could happen. Now if you were to include math.h (against sage advice) then that would definitely result in a violation of the one definition rule.

Answer 2

Typical scenario.

If extern "C" double log(double) is initially declared in the global namespace, then you have redeclared it and provided a definition. The implementation's previous mention of extern "C" carries over to your matching redeclaration. Your definition applies to the function belonging to the implementation, and it is an ODR violation.

As for the manifestation of UB: It's apparently common to treat log as a weak linker symbol. Your implementation overrides libc.so according to ABI rules.

(If the implementation doesn't do extern "C", it's still basically all the same.)

Other likely scenario.

If log is declared in namespace std and then brought into the global namespace, then your declaration will conflict with it. (Actually, a using declaration is technically a declaration.) This error is diagnosed.

Assumption-violating scenario.

then it refers to the same function as the log function we defined

One way for the implementation to put <cmath> names into the global namespace would be to declare extern "C" functions inside namespace std, then do using namespace std, and to ensure that this always happens as the first thing when any standard header is included. Since using namespace isn't "sticky" — it only applies to preceding declarations in the nominated namespace — the rest of the standard library would not be made visible. (This would not declare the names in the global namespace, but the standard only says "placed within the global namespace scope.")

In such an implementation, your declaration would hide the standard one and declare a new function with a new mangled name (say _Z3logd instead of simply log) and a new fully-qualified name (::log instead of ::std::log). Then there would be no ODR violation (unless some inline function uses one log in one TU and the other in a different TU).

Answer 3

Beware. The ODR only concerns definitions that will be included in the resulting program. That means that is does not concern symbols that could be present in libraries, because a (normal) linker does not load the whole libraries, but only the parts that are required to resolve symbols. For example in this code:

#include <cmath>

double log(double) {return 1.0;}

int main()
{
    log(1.0);
}

There is no violation of the ODR:

• either the log symbol from the C standard library was only included in the std namespace and there is no collision at all
• or it is also included in global namespace

In latter case, the declaration double log(double) does not conflict with the one from cmath because it is the same. And as the symbol log is already defined, its definition from the standard library will not be included in the program. As such, only one definition for the log function exists in the program, that one: double log(double) {return 1.0;}.

Things would be different if you extracted the object module containing log from the math library and explicitely link it in your program. Because object modules are always included in the resulting program whereas object modules in libraries are only conditionaly included if they resolve undefined symbols.

---

References from standard:

Draft n3337 for C++11 or n4296 for C++14 (or n4618 for last revision) are explicit in paragraph 2.2 Phases of translation [lex.phases]:

§9. All external entity references are resolved. Library components are linked to satisfy external references to entities not defined in the current translation. All such translator output is collected into a program image which contains information needed for execution in its execution environment.

As shown code uses only one translation unit and as log is already defined in it, the definition from the library will not be used.