For rule 17-0-3, I see only two scenarios where the guidelines permit overloading a standard library function. (Note: I presume by 'overridden', the guidelines actually mean over 'overloaded', since only virtual member-functions may be 'overridden'. Do correct me, if I err in that assessment.)
The first scenario involves the addition of parameters to the function. The text
makes this statement prima facia true.However, it is permissible to overload the name to add new parameter types if the functionality is consistent with those of the original.
The second scenario involves replacing a parameter type with a non-library type, implied by the sentence
Therefore, we find the following code compliant:It is permissible to add a new sqrt function for a type not present in the library.
Code: Select all
// Standard library code, simplified for this discussion
template <class T> class vector{};
void memcpy( char *, char *, int );
// Non-library code
class A{};
void memcpy( char *, char *, int, int ); // Ok, extra parameter.
void memcpy( A, char *, int ); // Ok, non-library type for a parameter.
Code: Select all
void memcpy( vector<int>, char *, int ); // !Ok, library type for a parameter.
Code: Select all
void memcpy( char*, char *, long );
One would expect, would have sufficed.Standard library functions shall not be overloaded, except to add parameters or to substitute a non-library type for any of the parameters.
The fact MISRA chose to provide a rationale requiring a longer logic train, implies other scenarios are permitted. However, as I mentioned, I cannot conceive of such at this moment.
Additionally, the rationale makes no mention of how to handle standard library functions which include ellipses in there parameter lists. How should programmers handle such situations?
Lastly, the ISO C++ standard, 17.4.2.2 p2 (lib.using.linkage), states,
which recommends, but does not require extern "C++" linkage. Combine this fact with ISO C++, 7.5 p6 (dcl.link),It is implementation-defined whether a name from the Standard C library declared with external linkage has extern "C" or extern "C++" linkage. It is recommended that an implementation use extern "C++" linkage for this purpose.
and One must ask if such circumstances were considered in the drafting of this rule. (I feel reasonably confident the circumstances were considered. The wording of the rationale, simply put, does not make any suggestion one way or the other.)At most one function with a particular name can have C language linkage.