MISRA Discussion Forums

Hi,

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

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?
E.g.

Code:
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)

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

FWIW,

Johan

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

gs

pkruk

jbezem

misra cpp