<![CDATA[MISRA Discussion Forums - 6.17 Library introduction (C++)]]> https://forum.misra.org.uk/ Thu, 05 Nov 2026 15:13:26 +0000 MyBB <![CDATA[Should #17-0-2 include any non-function identifier?]]> https://forum.misra.org.uk/showthread.php?tid=717 Tue, 16 Mar 2010 14:11:45 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=717 <![CDATA[Confusion over rule 17-0-3]]> https://forum.misra.org.uk/showthread.php?tid=570 Mon, 25 Aug 2008 19:43:28 +0000 gs]]> https://forum.misra.org.uk/showthread.php?tid=570
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
Quote:However, it is permissible to overload the name to add new parameter types if the functionality is consistent with those of the original.
makes this statement prima facia true.

The second scenario involves replacing a parameter type with a non-library type, implied by the sentence
Quote:It is permissible to add a new sqrt function for a type not present in the library.

Therefore, we find the following code compliant:

Code:
// Standard library code, simplified for this discussion
template  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.

Meanwhile the following would not (the above code is presumed given):

Code:
void memcpy( vector, char *, int );  // !Ok, library type for a parameter.

What of built-in types? Technically, the built-ins are not part of the library. They are built-in. So, would this could comply with the rule? (The above, again presumed.)

Code:
void memcpy( char*, char *, long );

If the two scenarios are the only ones permitted, a rule as straightforward as,

Quote:Standard library functions shall not be overloaded, except to add parameters or to substitute a non-library type for any of the parameters.
One would expect, would have sufficed.

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,
Quote: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.
which recommends, but does not require extern "C++" linkage. Combine this fact with ISO C++, 7.5 p6 (dcl.link),
Quote:At most one function with a particular name can have C language linkage.
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.)]]>
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
Quote:However, it is permissible to overload the name to add new parameter types if the functionality is consistent with those of the original.
makes this statement prima facia true.

The second scenario involves replacing a parameter type with a non-library type, implied by the sentence
Quote:It is permissible to add a new sqrt function for a type not present in the library.

Therefore, we find the following code compliant:

Code:
// Standard library code, simplified for this discussion
template  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.

Meanwhile the following would not (the above code is presumed given):

Code:
void memcpy( vector, char *, int );  // !Ok, library type for a parameter.

What of built-in types? Technically, the built-ins are not part of the library. They are built-in. So, would this could comply with the rule? (The above, again presumed.)

Code:
void memcpy( char*, char *, long );

If the two scenarios are the only ones permitted, a rule as straightforward as,

Quote:Standard library functions shall not be overloaded, except to add parameters or to substitute a non-library type for any of the parameters.
One would expect, would have sufficed.

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,
Quote: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.
which recommends, but does not require extern "C++" linkage. Combine this fact with ISO C++, 7.5 p6 (dcl.link),
Quote:At most one function with a particular name can have C language linkage.
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.)]]>