Related functions, such as those that make up a library, should provide consistent and usable interfaces. Ralph Waldo Emerson might have said, "A foolish consistency is the hobgoblin of little minds," but inconsistencies in functional interfaces or behavior can lead to erroneous use, so we understand this to be a "wise consistency." One aspect of providing a consistent interface is to provide a consistent and usable error-checking mechanism. For more information, see API04-C. Provide a consistent and usable error-checking mechanism.
Noncompliant Code Example (Interface)
...
The POSIX threads library [Butenhof 1997] defines an interface that is both consistent and fits in with established conventions from the rest of the POSIX library. For example, all initialization functions follow the same consistent pattern of the first argument being a pointer to the object to initialize with the subsequent arguments, if any, optionally providing additional attributes for the initialization:
...
Function arguments that refer to objects that are not modified are declared const. Because the object pointed to by the first argument is modified by the function, it is not const. For functions that implement a data abstraction, it is reasonable to define the handle for the data abstraction as the initial parameter. (See DCL12-C. Implement abstract data types using opaque types.) Finally, initialization functions that accept a pointer to an attribute object allow it to be NULL as an indication that a reasonable default should be used.
...
CERT C++ Secure Coding Standard: API04-C. Provide a consistent and usable error-checking mechanism
ISO/IEC 9899:2011 Section 7.24, "String handling <string.h>"
MISRA] Rule 20.4
Bibliography
[VMware 2007, VIX API Version 1.1.1 (for Workstation 6.0.1) Release Notes] 16-August-2007
[Burch 2006]
[CERT 2006c]
[Miller 1999]
[Seacord 2005a] Chapter 2, "Strings"
...