Confusion over rule 17-0-3

Moderators: david ward, misra cpp

Posts: 87
Joined: Thu Nov 18, 2004 1:39 am

Confusion over rule 17-0-3

Postby gs » Mon Aug 25, 2008 8:43 pm


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
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
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: 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.

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

Code: Select all

void memcpy( vector<int>, 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: Select all

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

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

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, p2 (lib.using.linkage), states,
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 (,
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.)

Posts: 20
Joined: Fri Jul 27, 2007 3:25 pm

Re: Confusion over rule 17-0-3

Postby pkruk » Mon Feb 01, 2010 11:54 am

I also have a question about 17-0-3 (and whole group of 17-0-*)

As I understand the rules allow declaration of a variable/parameter with the same name as function from standard library?

Code: Select all

char max;
void foo(bool abort);

As I understand it, 17-0-1 restricts #define/#undef only, 17-0-2 restricts stdandard library macros/objects (not functions) and 17-0-3 restricts cases when we define a function (at least this is what is suggested by normative text IMO).

Maybe the overridden in rule headline isn't supposed to be overloaded as gs suggests, but should be understood more like reused (although I don't know why would there be a different word used than in 17-0-2, which uses reused)

Posts: 20
Joined: Mon Aug 01, 2005 8:24 pm
Company: JB Enterprises
Location: Germany

Re: Confusion over rule 17-0-3

Postby jbezem » Mon Feb 01, 2010 1:51 pm

Reused: used again, so the name is used first, and later in a compilation unit or between compilation units it is used again, possibly with a different definition. This is only possible with certain kinds of objects, like macros or global/local/static variables, especially _not_ for functions.
Overridden: The new definition completely replaces the old one, ven in those places (e.g. in the library) where the previous version is supposed to be used.
Because of the modus operandi of the linker it might be possible to create a function 'printf' having an signature identical to the standard library function. The library will take your definition, and ignore the definition in the library (as a rule, possibly generating a warning).
Overloaded: In OO programming, if you create a function of the same name but with different parameter(-types), both the standard library function definition and your new one can be in scope at the same time, and the variant chosen is determined by the linker.

The wording in 17-0-* is consistent with my descriptions AFAICT.


Johan Bezem
Email: [email protected]
Tel: +49 172 5463210

misra cpp
Posts: 145
Joined: Mon Jun 02, 2008 1:55 pm
Company: MISRA

Re: Confusion over rule 17-0-3

Postby misra cpp » Tue Oct 11, 2016 11:15 am

The original intention of the rule was to cover the “replacing” of standard library functions.

A future edition will remove the use of 'override' and clarify the actual intent
Posted by and on behalf of
the MISRA C++ Working Group

Return to “6.17 Library introduction (C++)”

Who is online

Users browsing this forum: No registered users and 1 guest