ISOcxx: The C++ Portability Package

Defects Database

Last update: 5 March 2002 Walter E. Brown

Contents

Language Issues Library Issues

Language Issues

DEFECT_ABSTRACT_VIRTUAL_BASE, ISOcxx_ABSTRACT_VIRTUAL_BASE

Standard C++ allows virtual inheritance from an abstract base class. Some environments, however, do not correctly implement this feature, particularly in the context of multiple inheritance involving a templated class. A test program, absvbase.cc, which ought to compile and run correctly in a compliant environment, is provided in order to determine this defect's presence or absence.

There is no compliance code for this defect, as no run-time code can compensate for the absence of this compiler feature. Client code is advised to use caution in inheriting from an abstract base class in general, and especially when using virtual multiple inheritance in the presence of templates.

DEFECT_BOOL_NOT_DISTINCT_TYPE, ISOcxx_BOOL_IS_DISTINCT_TYPE

Standard C++ specifies bool as a native type. Some environments implement bool in the form of a typedef or other alias for another native type (e.g., int, short, or char). This suffices for most applications. Since the compiler can't distinguish such a bool type from its alias, however, such an aliasing scheme allows neither proper function call overload resolution nor proper template specialization. A cast from int to such a bool may, in some cases, also give an unexpected result.

A test program, booluniq.cc, which ought to compile and run correctly in a compliant environment, is provided in order to determine this defect's presence or absence.

There is no compliance code for this defect, as no known non-native bool implementation has been demonstrated to cure this defect to even a minimally useful extent. Client code requiring a distinguishable bool type is therefore advised to consider alternate techniques for maximum portability.

DEFECT_CONDITIONAL, ISOcxx_CONDITIONAL

In a conditional expression, the second and third operands are required by the C++ standard to be compatible types. There is an extensive and intricate set of rules by which such compatibility is determined. Unfortunately, some environments do not quite properly adhere to these rules.

A test program, conditnl.cc, which ought to compile and run correctly in a compliant environment, is provided in order to determine this defect's presence or absence.

Alas, there is no compliance code for this defect. Client code running afoul of this defect is advised to insert an explicit cast in the offending operand(s).

DEFECT_NESTED_CLASS_ID, ISOcxx_NESTED_CLASS_ID

In standard C++, members (both data and functions) of a nested class may be referenced via a fully-qualified identifier of the form Outer::Inner::member. Certain environments, however, do not correctly recognize such fully-qualified names when applied to members of nested classes. A test program, nestcls.cc, which ought to compile and run correctly in a compliant environment, is provided in order to determine the presence or absence of this defect.

Unfortunately, no transparent cure for this defect, if present, is known. However, client code is advised to use the following workaround in consistent fashion: provide a typedef for the nested class, such as typedef Outer::Inner OI;, and then use the typedef'd identifier consistently, as in OI::member.

DEFECT_NO_BOOL, ISOcxx_HAS_BOOL

Standard C++ specifies bool as a native type. However, certain environments do not provide this data type. A test program, bool.cc, which ought to compile and run correctly in a compliant environment, is provided in order to determine the presence or absence of this defect. If present, the portability package completely and transparently cures this defect on all tested platforms.

Caveat: the compliance code that cures this defect will usually trigger DEFECT_BOOL_NOT_DISTINCT_TYPE.

DEFECT_NO_DEFAULT_TEMPLATE_PARAMETERS, ISOcxx_HAS_DEFAULT_TEMPLATE_PARAMETERS

Some environments do not support default parameters for templates. The test program default.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

Where the defect affects the standard library, this package does provide a number of cures, documented elsewhere. However, no known cure is available to remedy this very basic defect in the general case. The following coding alternatives may serve to ameliorate this defect's consequences.

Absent default template parameter capability, it is always possible to specify explicitly the desired default at each point of instantiation. While perhaps somewhat tedious to code, this approach is guaranteed to yield semantics identical to that of code written assuming the default template argument value.

Other approaches are also possible. In particular, it may be possible to omit the defaulted template parameter entirely and furnish equivalent information in other ways (e.g., via a typedef or a const), especially when the default value is always wanted. Other situations may yield still further approaches.

Caveat: this defect will always trigger DEFECT_PRIQ_DEFAULT_CONTAINER, DEFECT_QUEUE_DEFAULT_CONTAINER, and DEFECT_STACK_DEFAULT_CONTAINER, among others.

DEFECT_NO_DELETE_CONST, ISOcxx_OK_DELETE_CONST

The C++ standard states that a dynamically-allocated object (i.e., one that has been instantiated via a new-expression) may be deallocated (destroyed) via a delete-expression taking a pointer to the object. In particular, according to the standard, the constness of the object is irrelevant in this context.

Unfortunately, a few environments do not permit a delete-expression that takes a pointer-to-const, contrary to the standard. A test program, delconst.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

Client code impacted by this defect has two choices. The offending pointer-to-const may be CONST_CAST (see here) so as to become a pointer-to-nonconst. Alternatively, client code may employ a macro, DELETE_CONST, that the portability package provides. This macro takes two arguments: the desired pointer-to-nonconst type, and the offending pointer-to-const. The macro will perform any cast needed, depending on the compliance of the environment, then delete the (non-array) object via the resulting cast pointer; it thus completely cures the defect. Client code that deletes an array ought to use the first of these approaches in conjunction with an array-delete-expression (delete[]).

DEFECT_NO_EXCEPTIONS, ISOcxx_HAS_EXCEPTIONS

The C++ standard provides the exception-handling keywords try, throw, and catch. Unfortunately, a few environments do not support (or deliberately disable) use of these features. A test program, except.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

Client code impacted by this defect is advised to replace use of the above keywords by the following macros provided by the portability package: TRY, THROW(exception), RETHROW(), CATCH(exception), and THROWS( (exception_list) ) (note double parentheses!) or NOTHROW(), as appropriate. In a compliant environment, these macros make full use of the native exception-handling capability. In a defective environment, these macros will allow the client code to compile cleanly, but are otherwise unable to compensate for the defect.

DEFECT_NO_EXPLICIT, ISOcxx_HAS_EXPLICIT

Standard C++ provides a keyword, explicit, to indicate that a class' constructor may be invoked only where explicitly called for, and never implicitly. This is sometimes desirable to prevent unwanted conversions due to implicit constructor calls. Some environments do not yet support explicit, and so the test program explicit.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

Compliance code to cure this defect, if it is present, is completely transparent in that the explicit keyword is transparently made acceptable. However, the compliance code is unable to provide the correct semantics of explicit. Therefore, in a non-compliant environment, client code may yield surprising results due to unexpected and/or unwanted conversion constructor calls, as would be the case in the absence of explicit.

DEFECT_NO_FRIEND_TEMPLATES, ISOcxx_HAS_FRIEND_TEMPLATES

According to the C++ standard, a class may have friends that are templates, implying that each specialization of such a template is a friend to the class. Some environments incorrectly do not support such friend templates. The test program tmplfrnd.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this defect.

DEFECT_NO_FULL_SPECIALIZATION_SYNTAX, ISOcxx_HAS_FULL_SPECIALIZATION_SYNTAX

Some environments do not recognize or properly support full specialization for templates. The test program fullspec.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this rather basic defect. Reliance on this language feature is, therefore, strongly discouraged.

DEFECT_NO_FUNCTION_TRY_BLOCKS, ISOcxx_OK_FUNCTION_TRY_BLOCKS

In standard C++, the body of a function may consist of a try block followed by a catch clause. The test program fctntry.cc, which ought to compile and run properly in a compliant environment, tests for the presence of this language feature.

Unfortunately, many environments do not support this feature. Since no known cure is available to remedy this defect, reliance on this language feature is strongly discouraged.

DEFECT_NO_FUNCTMPL_PARTIAL_ORDERING, ISOcxx_HAS_PARTIAL_ORDERING

Some environments do not recognize or properly support partial ordering for template functions. The test program porder.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this defect. Reliance on this language feature is, therefore, strongly discouraged.

DEFECT_NO_MEMBER_CONSTANTS, ISOcxx_HAS_MEMBER_CONSTANTS

According to the C++ standard, a class may have data members that are static constants of integral type. Some environments incorrectly do not support such compile-time constant members. The test program mbrconst.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

In may cases, a value of enumerated type can serve as a perfectly adequate substitute for a member constant as described above; the main difference is in the data type of the constant. A macro, MEMBER_CONSTANT(), has been provided to facilitate use of this workaround: for a compliant compiler, the correct static const is generated, but an enum is generated when using a defective compiler, as shown by the following example:

 
macro invocation 
MEMBER_CONSTANT(int,N,7); 
 
      macro expansion 
static int const N = 7; // if compliant 
enum { N = 7 }; // if defective
 

DEFECT_NO_MEMBER_TEMPLATES, ISOcxx_HAS_MEMBER_TEMPLATES

According to the C++ standard, a class may have member functions (methods) that are templates. Some environments incorrectly do not support such member templates. The test program tmplmbr.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this defect.

DEFECT_NO_MEMBER_USING, ISOcxx_HAS_MEMBER_USING

According to the C++ standard, a derived class may selectively overload and/or override member functions from its base class. Before overloading or overriding only some of a set of overloaded functions (say, f), the derived class must bring all these functions into its own scope with a member using declaration. The following example typifies such usage:
 
// Base class: 
class B  { 
public: 
  int  f( char )  { return 0; }
  int  f( int  )  { return 1; }
};
      // Derived class: 
class D : public B { 
public: 
  using B::f;
  int  f( int )  { return 2; } // selective override
};
 
Some environments incorrectly do not support such member using declarations. The test program usingmbr.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

To remedy this defect requires client code cooperation. In particular, client code must test for the presence of this defect and, in its presence, refrain from applying the using declaration. Further, it may be necessary either to forego the overload/override in the derived class, or to insert forwarding functions in the derived class that (a) match the signatures of the non-overridden functions from the base class and (b) respectively call these non-overridden functions.

DEFECT_NO_METHOD_SPECIALIZATION, ISOcxx_HAS_METHOD_SPECIALIZATION

According to the C++ standard, a class may have member functions (methods) that are templates and that, in turn, may be specialized. Some environments incorrectly do not allow such specialization. The test program methspec.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this defect.

DEFECT_NO_MUTABLE, ISOcxx_HAS_MUTABLE

Standard C++ provides a keyword, mutable, to indicate that a data member may be updated even when its parent object is const. Some environments do not yet support mutable, and so the test program mutable.cc, which ought to compile and run correctly, tests for this defect.

Compliance code to cure this defect, if it is present, is only semi-transparent. The mutable keyword is transparently made acceptable, but client code that updates a mutable data member must be specially coded, as illustrated by the following examples (assume that k has been declared as a mutable int data member of a const object c):

 
in standard C++ 
c.k = 27 
++c.k
      using ISOcxx compliance code 
MUTABLE_ENTITY(int,c.k) = 27 
++ MUTABLE_ENTITY(int,c.k)
 

DEFECT_NO_NAMESPACES, ISOcxx_HAS_NAMESPACES

Some non-compliant environments do not yet support namespace (and allied keywords such as using). A test program, nmspace.cc, which ought to compile and run correctly in a compliant environment, tests for such a defect.

Due to the required syntax of these keywords, compliance code to cure this defect is only semi-transparent. While the identifier std (used to qualify the names of the standard library's entities) is transparently made acceptable, client code that declares, defines, or otherwise employs a namespace must be specially coded. The following table provides examples of the recommended compliance code usage:

 
in standard C++ 
myNS::mySymbol 
namespace myNS { 
}  /* myNS */ 
using myNS::mySym; 
using namespace myNS; 
namespace myNS = yourNS;
      using ISOcxx compliance code 
QUAL_NAME(myNS,mySymbol) 
BEGIN_NAMESPACE(myNS) 
END_NAMESPACE(myNS) 
USING(myNS::mySym) 
USING_NAMESPACE(myNS) 
ALIAS_NAMESPACE(myNS,yourNS)
 
For maximum portability, the compliance code requires one additional form of cooperation. Because an environment that does not support explicit namespaces will place all global names into a single (unnamed) namespace, client code is advised to select names carefully so as to avoid duplicate identifiers in this (potential) single namespace.

DEFECT_NO_NEW_CONST, ISOcxx_OK_NEW_CONST

Contrary to the C++ standard, some environments do not permit a new-expression to allocate a const object. A test program, newconst.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

Client code impacted by this defect is advised simply to remove the const qualifier from the object being allocated. This causes no problems, for the resulting pointer-to-nonconst may be immediately and safely copied to a pointer-to-const, thus ensuring const-correctness thenceforth throughout the remainder of the program.

DEFECT_NO_PARTIAL_SPECIALIZATION, ISOcxx_HAS_PARTIAL_SPECIALIZATION

Some environments do not recognize or properly support partial specialization for templates. The test program partspec.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this rather basic defect. Reliance on this language feature is, therefore, strongly discouraged.

DEFECT_NO_STATIC_CONST_INIT, ISOcxx_HAS_STATIC_CONST_INIT

According to the C++ standard, a class' static data members, if const and of integral type, may be given initializers as part of their declaration within the class definition. Some environments incorrectly do not support such initialization. The test program tmplinit.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this defect. Client code is advised to avoid this defect by initializing all static data members, const and non-const, integral and non-integral alike, outside their class' definition. In particular, this ought be done at the point of each static member's definition.

DEFECT_NO_STATIC_TEMPLATE_DATA, ISOcxx_HAS_STATIC_TEMPLATE_DATA

According to the C++ standard, a templated class may have static data members. Some environments incorrectly do not support such data members. The test program tmplstat.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this defect.

DEFECT_NO_TEMPLATES, ISOcxx_HAS_TEMPLATES

Some environments pre-date and hence do not support template. The test program template.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

While the portability package does provide some compliance code, it consists primarily of discarding the template keyword. No known cure is available to remedy this very basic defect, whose presence is very likely to be the herald of a small cascade of additional related defects.

DEFECT_NO_TEMPLATES_AS_TEMPLATE_PARAMETERS, ISOcxx_HAS_TEMPLATES_AS_TEMPLATE_PARAMETERS

The C++ standard permits the use of a template as a parameter to another template. Some environments,however, do not recognize or properly support this feature. The test program tmpltmpl.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this defect. Reliance on this (quite sophisticated) language feature is, therefore, strongly discouraged.

DEFECT_NO_TEMPLATE_MEMBER_FWDDECL, ISOcxx_HAS_TEMPLATE_MEMBER_FWDDECL

According to the C++ standard, a member function may be declared within its class and subsequently defined outside of the class definition. Some environments incorrectly require a member function of a templated class to be defined within the class definition. The test program membrfwd.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this defect.

DEFECT_NO_TEMPLATE_NESTEDCLASS_FWDDECL, ISOcxx_HAS_TEMPLATE_NESTEDCLASS_FWDDECL

According to the C++ standard, a member function may be declared within its class and subsequently defined outside of the class definition. Some environments incorrectly require that a member function of a class nested within a templated class be defined within the class definition. The test program nestfwd.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

No known cure is available to remedy this defect.

DEFECT_NO_TYPENAME, ISOcxx_HAS_TYPENAME

The typename keyword, in standard C++, is used in two ways: (1) as a synonym for class in the context of a template's type parameter, and (2) to identify a qualified name as a type name rather than as a non-type member name. Some environments, however, do not recognize either use of the keyword. The test program typename.cc, which ought to compile and run correctly in a compliant environment, tests the latter usage of typename for this defect.

For maximum portability, client code is advised (1) to use the classkeyword consistently in lieu of the typename keyword for all template type parameters, and therefore (2) to reserve use of typenameto precede qualified names that would otherwise be interpreted (by default, per the C++ standard) as non-type member names. If these recommendations are followed, the compliance code associated with this defect transparently and completely cures the defect in all tested environments.

DEFECT_NO_UNSIGNED_ENUM, ISOcxx_HAS_UNSIGNED_ENUM

The C++ standard states that the fundamental integral type underlying an enum may be either an int or an unsigned int, depending on the values of the enum's enumerators. Some environments, however, insist on using an int, and so produce an error for certain large enumerator values, e.g., (1UL<<31). The test program bigenum.cc, which ought to compile and run correctly in a compliant environment, tests for this defect.

The portability package is unable to provide compliance code for this defect. Instead, client code is advised to avoid use of such large enumerators, if possible. If large enumerators are unavoidable, client code is advised to provide an explicit cast (to int), conditioned on the presence of this defect.

DEFECT_NO_VIRTUAL_COVARIANCE, ISOcxx_HAS_VIRTUAL_COVARIANCE

A covariant return type arises in the context of a virtual member function of a derived class. It is sometimes necessary for the return type of a derived class' member function to differ from the return type of the comparable function in the base class. The following example illustrates one application of this concept in standard C++, two declarations for a member function, clone():
 
// Base class: 
class B  { 
public: 
  virtual  B *  clone(); 
};
      // Derived class: 
class D : public B { 
public: 
  virtual  D *  clone(); 
};
 
As shown above, the return type of the member function depends on the class of which it is a member. Unfortunately, not all environments permit such covariant return types. A test program, covary.cc, which ought to compile and run correctly in a compliant environment, tests for such defect.

Compliance code to cure this defect is not transparent to client code. For maximum portability, client code is advised to make use of the compliance macro COVARIANT_TYPE(), as illustrated in the following table:

 
in standard C++ 
virtual  D *  D::clone();
      using ISOcxx compliance code 
virtual  COVARIANT_TYPE(B, D) *  D::clone();
 
Please note also that the above cure is syntactic only; the compliance code is unable to provide the correct semantics of true virtual covariant return types when such a return value is subsequently used polymorphically.

DEFECT_NO_VIRTUAL_OVERRIDE, ISOcxx_HAS_VIRTUAL_OVERRIDE

It is possible, in standard C++, to override in a derived class only some of the signatures of a family of member functions declared in a base class. The following example is illustrative with respect to the functions named f(); only one of the two base class functions is overridden:
 
// Base class: 
class B  { 
public: 
  virtual  void  f( int ); 
  virtual  void  f( double ); 
};
      // Derived class: 
class D : public B { 
public: 
  using B::f; 
  virtual  void  f( int ); 
};
 
Note especially the using declaration inside D's definition. Without this statement, the declaration of f() within D (in other words, D::f()) would, via standard scope rules, completely hide both definitions of B::f(). As shown above, however, the using declaration makes all declarations of B::f() visible to D so that only the desired signature(s) can be overridden without hiding the remaining signatures.

Unfortunately, some compilers do not correctly handle such a using declaration. A test program, virtovrd.cc, which ought to compile and run correctly in a compliant environment, tests for such defect.

There is no known cure for this defect. A workaround, however, may be possible, as illustrated below:

 
// Derived class:
class D : public B {
public:
  #ifndef DEFECT_NO_VIRTUAL_OVERRIDE  // compliant
    using B::f;
  #else  // defective: override all other signatures, too
    virtual  void  f( double ); 
  #endif
  virtual  void  f( int );
};
 

DEFECT_NO_WCHAR_T, ISOcxx_HAS_WCHAR_T

Standard C++ specifies wchar_t as a native type. However, certain environments do not yet provide this data type. A test program, wchart.cc, which ought to compile and run correctly in a compliant environment, is provided in order to determine the presence or absence of this defect. If present, the portability package completely and transparently cures this defect on all tested platforms.

Caveat: the compliance code that cures this defect will usually trigger DEFECT_WCHAR_T_NOT_DISTINCT_TYPE, described below.

DEFECT_OLD_FOR_SCOPING, ISOcxx_NEW_FOR_SCOPING

In standard C++, a variable defined in a for loop's initialization clause is in the scope of the loop. It should not conflict with any previously-defined entity of the same name, and its lifetime should end upon exit from the loop. An earlier draft of the C++ standard, however, permitted such a variable's lifetime and scope to extend outside the loop's body. Certain environments still adhere to the earlier draft.

Presence or absence of this defect is determined via the test programs forok.cc and forbad.cc. In a compliant environment, the former ought to compile and run correctly, but the latter ought not to compile.

The portability package completely and transparently cures this defect, if it is present, on all tested platforms.

Caveat: the compliance code may give rise to warning messages regarding unreachable code at or immediately above each for statement; any such warnings may be safely ignored.

DEFECT_OLD_STYLE_CASTS, ISOcxx_NEW_STYLE_CASTS

The C++ standard defines four new cast operators, and recommends their use over the traditional C-style cast operators. The four are, of course, static_cast<>, const_cast<>, dynamic_cast<>, and reinterpret_cast<>. Unfortunately, a few environments do not yet accept these new forms.

A test program, casts.cc, tests for the correct behavior of two of these new styles of cast, static_cast<>and const_cast<>. If they are not present, or do not behave properly, they are considered defective. (This defect may be revisted in the future if there is additional need to improve the compliance code by testing for the presence and correct behavior of the other two new cast styles.)

Compliance code to cure this defect is not transparent to client code. For maximum portability, client code is advised to make use of the compliance macros STATIC_CAST() and CONST_CAST(), as illustrated in the following table (assume that d is a const double):

 
in standard C++ 
const_cast<double &>(d) 
static_cast<int>(d)
      using ISOcxx compliance code 
CONST_CAST(double &, d) 
STATIC_CAST(int, d)
 

DEFECT_PASCAL_IS_KEYWORD, ISOcxx_PASCAL_NOT_KEYWORD

In the C++ standard, pascal is not defined as a keyword. Unfortunately, a few environments have incorrectly reserved this word.

A test program, pascal.cc, which ought to compile and run correctly in a compliant environment, tests for this incorrect behavior. If the defect is determined to be present, it is transparently cured by the associated compliance code.

DEFECT_WCHAR_T_NOT_DISTINCT_TYPE, ISOcxx_WCHAR_T_IS_DISTINCT_TYPE

As indicated in the description of DEFECT_NO_WCHAR_T, standard C++ specifies wchar_t as a native type. Some environments implement wchar_t in the form of a typedef or other alias for another native type (e.g., int, short, or char). This suffices for most applications. Since the compiler can't distinguish such a wchar_t type from its alias, however, such an aliasing scheme allows neither proper function call overload resolution nor proper template specialization. A cast to such a wchar_t may, in some cases, also give an unexpected result.

A test program, wchruniq.cc, which ought to compile and run correctly in a compliant environment, is provided in order to determine this defect's presence or absence.

There is no compliance code for this defect, as no known non-native wchar_t implementation has been demonstrated to cure this defect to even a minimally useful extent. Client code requiring a distinguishable wchar_t type is therefore advised to consider alternate techniques for maximum portability.

DEFECT_USING_NAMESPACE_OVERLOAD, ISOcxx_USING_NAMESPACE_OVERLOAD

Overload resolution is the process, prescribed by the C++ standard, of selecting one function from a set of candidate functions that overload a function name. At least one environment does not correctly perform overload resolution in the presence of a using namespace directive.

A test program, using_ns.cc, which ought to compile and run correctly in a compliant environment, tests for this incorrect behavior.

There is no known cure for this defect, but a workaround is possible by avoiding the using namespace directive. Instead, function names may be declared by their fully qualified names via the using declaration (e.g., using ns::f;). Alternatively, the fully qualified function name may be used at the point of call.


Library Issues

DEFECT_ALLOCATOR_NOT_TEMPLATE, ISOcxx_ALLOCATOR_IS_TEMPLATE

A compliant C++ <memory> header provides an allocator class template. At least one environent, however, incorrectly provides only an untemplated allocator class. A test program, alloc.cc, which ought to compile and execute correctly in a compliant environment, determines the presence of this defect. For maximum portability, client code is advised to make use of the compliance macro STL_ALLOCATOR(t) in lieu of allocator<t>. This macro will produce either the templated or non-templated allocator, as appropriate for the environment.

DEFECT_BAD_BITSET_SUPPORT, ISOcxx_OK_BITSET_SUPPORT

The C++ standard requires the bitset class template (found in the <bitset> header).

In at least one environment, this template is provided but incorrectly configured. A test program, bitset.cc, which ought to compile and run correctly in a compliant environment, tests for such a defect. If present, the compliance code in the portability package completely and transparently cures this defect on all tested platforms.

DEFECT_BAD_ITERATOR_ARGS, ISOcxx_OK_ITERATOR_ARGS

The C++ standard requires the iterator class template (found in the <iterator> header).

In at least one environment, this template is provided but incorrectly configured. A test program, iter8or.cc, which ought to compile and run correctly in a compliant environment, tests for such a defect. If present, the compliance code in the portability package completely and transparently cures this defect on all tested platforms.

Because of the nature of the compliance code, it is possible that the defect, if present, is actually cured before the test program runs. If so, the defect appears not to manifest to the test program, and the defect macro is not set.

DEFECT_BAD_LIST_SPLICE, ISOcxx_OK_LIST_SPLICE

The C++ standard specifies that the list class template (found in the <list> header) contain an overloaded member function, splice().

In at least one environment, one of the overloaded versions does not behave properly in a boundary case when splicing a part of a list into itself. A test program, splice.cc, which ought to compile and run correctly in a compliant environment, tests for such a defect. Unfortunately, no compliance code for this defect, if present, is known.

DEFECT_BAD_PRIQ_DEFAULT_CONTAINER, ISOcxx_OK_PRIQ_DEFAULT_CONTAINER
DEFECT_BAD_QUEUE_DEFAULT_CONTAINER, ISOcxx_OK_QUEUE_DEFAULT_CONTAINER
DEFECT_BAD_STACK_DEFAULT_CONTAINER, ISOcxx_OK_STACK_DEFAULT_CONTAINER

In standard C++, each of the three containers priority_queue<>, queue<>, and stack<> are adapters; that is, each is merely a specialized interface to a different container. If users do not specify a desired underlying container, the language provides a default container to be used for this purpose.

Some environments, however, incorrectly specify these defaults. The test programs listed below, which ought to compile and execute correctly in a compliant environment, determine the presence of this defect for their respective adapters. For maximum portability, client code is advised to make use of the compliance macros STL_PRIORITY_QUEUE(t), STL_QUEUE(t), and STL_STACK(t) in lieu of std::priority_queue<t>, std::queue<t>, and std::stack<t>, respectively. These macros will produce adapters that employ the correct default underlying containers wherever possible.

 
adapter 
priority_queue<> 
queue<> 
stack<> 
      found in header 
<queue> 
<queue> 
<stack> 
      default container 
vector<> 
deque<> 
deque<> 
      test program 
defpriq.cc 
defque.cc 
defstk.cc 
 

DEFECT_CMATH_DOUBLE_VERSIONS, ISOcxx_CMATH_ALL_VERSIONS

Each function declared in <cmath> should, according to the C++ standard, be overloaded so as to take arguments of type double, float, and long double. At least one environment, however, provides only the double version of these functions.

A test program, cmathver.cc, which ought to compile and run correctly in a compliant environment, tests for such a defect. If present, the compliance code in the portability package completely and transparently cures this defect on all tested platforms.

DEFECT_COMPLEX_INCOMPATIBLE, ISOcxx_COMPLEX_INCOMPATIBLE

The C++ standard expects that all its mandated headers will smoothly interoperate with each other. In at least one environment, the header <complex> is implemented infelicitously, leading to compilation failure when used in combination with <math.h>.

The portability package incorporates compliance code to cure this defect. This cure is, however, preemptive in nature: it is efficatious to such a degree that the defect is undetectable. For this reason, no test program is available. In consequence, the portability package sets neither of the defect presence symbols devoted to this defect.

DEFECT_EOF, ISOcxx_EOF

According to the C++ standard, eof() should only be set on an istream when an attempt is made to read past the end of the stream. Some compilers set this bit too early.

A test program, eof.cc, tests for this incorrect behavior. Unfortunately, there is no compliance code known to cure this defect.

DEFECT_INF_LONG_DOUBLE, ISOcxx_INF_LONG_DOUBLE

The C++ standard specifies that the numeric_limits class template (found in the <limits> header) contain a static member function, infinity(). This function must be meaningful for each specialization in which the static data member has_infinity has the value true.

In at least one environment, the value returned by this member function does not behave properly for the long double specialization. A test program, inf_ldbl.cc, which ought to compile and run correctly in a compliant environment, tests for such a defect. Unfortunately, no compliance code for this defect, if present, is known.

DEFECT_NO_*_HEADER, ISOcxx_*_HEADER
DEFECT_*_H

Coping with the prevalence of library headers by non-standard names is a major accomplishment of the portability package. For each of the 70 C++ headers mandated by the standard, the package provides a symbol to denote the environment's local name for the header. Thus, a standard header whose name has the form <xxx> would have a corresponding symbol ISOcxx_XXX_HEADER, while a header whose name has the form <yyy.h> would have a corresponding symbol ISOcxx_YYY_H_HEADER.

If a particular header is missing or has a nonstandard name in a given environment, the portability package defines a symbol of the form DEFECT_NO_XXX_HEADER or the form DEFECT_NO_YYY_H_HEADER as appropriate. (A few related defect symbols are supported as described below, primarily for backward compatibility with past practice at Fermilab.) There is, in general, no reason for client code to consult these symbols, which are used internally by the package to cure, completely and transparently, any defect in the name(s) of the standard headers on all test platforms. Client code is advised, therefore, to use the standard header names.

Direct client use of any of the most common nonstandard names (e.g., <iostream.h>) for standard headers will result in compilation termination with a diagnostic of the form "<iostream.h> is nonstandard; use <iostream> instead!" If such a diagnostic appears, client code is advised to use the standard header names in lieu of the outdated names. A test program, oldhdrs.cc, is used to confirm that library headers by outdated names produce this diagnostic. Symbols of the form DEFECT_XXX_H are produced in such cases, but are intended solely for internal package use; no practical client use for them is anticipated.

To the extent possible, the package transparently compensates for any headers that are missing from a given environment. Often this is done by (a) substituting a different header that has equivalent (or near-equivalent) functionality and then (b) forwarding client services to the substitute header as appropriate. A test program, library.cc, is used to confirm that library headers are available.

Sometimes client code must include a header from a package, not under client control, that is itself defective because it uses the outdated header names. To prevent complaints due to such code, a special symbol may be defined, as illustrated by the following scenario:

 
instead of: 
 
#include "bad_header.h" 
 
      use: 
#define ISOcxx_ALLOW_DRAFT_HEADERS 
#include "bad_header.h" 
#undef ISOcxx_ALLOW_DRAFT_HEADERS 
 

DEFECT_NO_AUTO_PTR, ISOcxx_HAS_AUTO_PTR

The C++ standard mandates the existence of a class template, auto_ptr<>, in the <memory> header. At least one environment, however, does not provide this template.

A test program, autoptr.cc, which ought to compile and run correctly in a compliant environment, tests for this defect. If the defect is present, the compliance code in the portability package transparently cures this defect on all tested platforms.

DEFECT_*_NOT_STD, ISOcxx_*_IS_STD

According to the C++ standard, each of the nineteen library headers inherited from C is provided in two forms. The first form exactly matches that of C, i.e. <xxx.h>, while the second has the form <cxxx>. In both cases, functions and types declared within the header ought to be in the std:: namespace. In the second case, the same functions and types ought to be declared in the global namespace as well.

Some environments, however, incorrectly use only the global namespace in both cases. The compliance code in the portability package completely and transparently insures all declared names will be found in the std:: namespace on all tested platforms for the headers itemized in the following table. The indicated test programs, which ought to compile and run correctly in a compliant environment, test for this defect in the respective headers.

 
header 
<cmath> 
<cstddef> 
<cstdlib> 
<cstring> 
      test program 
cmathstd.cc 
cstdfstd.cc 
cstlbstd.cc 
cstrgstd.cc 
 

Note that, at present, the package does not test to insure that headers do not pollute the global namespace with identifiers that are supposed not to be there.

DEFECT_MEM_FUN1, ISOcxx_MEM_FUN1

According to the C++ standard, the header <functional> is to provide four forms of the mem_fun() adapter: const and nonconst versions for niladic and for unary member functions. In addition, the comparable four forms of the mem_fun_ref() adapter are also required of this header. Unfortunately, some environments are missing the versions for unary member functions.

A test program, mem_fun1.cc, which ought to compile and run correctly in a compliant environment, tests for this defect. If the defect is present, the compliance code in the portability package transparently cures this defect on all tested platforms.

DEFECT_NO_CONST_MEM_FUN1_T, ISOcxx_HAS_CONST_MEM_FUN1_T

According to the C++ standard, the header <functional> is to provide an intermediate class const_mem_fun1_t<> as an analog to the nonconst version mem_fun1_t<>, as well as an intermediate class const_mem_fun1_ref_t<> as an analog to the nonconst version mem_fun1_ref_t<>. Unfortunately, some environments are missing these const versions for unary member functions.

A test program, cmf1t.cc, which ought to compile and run correctly in a compliant environment, tests for this defect. If the defect is present, the compliance code in the portability package transparently cures this defect on all tested platforms.

DEFECT_NO_ABS, ISOcxx_HAS_ABS
DEFECT_NO_ABS_DOUBLE, ISOcxx_HAS_ABS_DOUBLE
DEFECT_NO_ABS_FLOAT, ISOcxx_HAS_ABS_FLOAT
DEFECT_NO_ABS_LONG, ISOcxx_HAS_ABS_LONG
DEFECT_NO_ABS_LONG_DOUBLE, ISOcxx_HAS_ABS_LONG_DOUBLE

According to the C++ standard, there are to be five overloaded versions of the mathematical function abs() distributed among three headers. Some environments, however, do not provide all required versions. The following table summarizes the required signatures, the header responsible for each, and the test programs that test for each defect. Each of these tests ought to compile and run correctly in a compliant environment. If present, the portability package's compliance code completely and transparently cures any of these defects.
 
signature 
abs(int) 
abs(double) 
abs(float) 
abs(long) 
abs(long double) 
          header 
<stdlib.h> 
<cmath> 
<cmath> 
<cstdlib> 
<cmath> 
          test program 
abs_int.cc 
abs_dbl.cc 
abs_flt.cc 
abs_long.cc 
abs_ldbl.cc 
 

DEFECT_NO_DEQUE_ALLOCATOR, ISOcxx_OK_DEQUE_ALLOCATOR
DEFECT_NO_LIST_ALLOCATOR, ISOcxx_OK_LIST_ALLOCATOR
DEFECT_NO_MAP_ALLOCATOR, ISOcxx_OK_MAP_ALLOCATOR
DEFECT_NO_MULTIMAP_ALLOCATOR, ISOcxx_OK_MULTIMAP_ALLOCATOR
DEFECT_NO_MULTISET_ALLOCATOR, ISOcxx_OK_MULTISET_ALLOCATOR
DEFECT_NO_SET_ALLOCATOR, ISOcxx_OK_SET_ALLOCATOR
DEFECT_NO_VECTOR_ALLOCATOR, ISOcxx_OK_VECTOR_ALLOCATOR

In standard C++, each of the containers deque<>, list<>, map<>, multimap<>, multiset<>, set<>, and vector<> permits users to elect a custom allocator to be used as the container grows and shrinks.

Some environments, however, incorrectly do not permit users this flexibility. The test programs listed below, which ought to compile and execute correctly in a compliant environment, determine the presence of this defect for their respective adapters. For maximum portability, client code is advised to make use of the compliance macros STL_DEQUE_ALLOC(t,a), STL_LIST_ALLOC(t,a), STL_MAP_COMP_ALLOC(k,t,comp,a), STL_MULTIMAP_COMP_ALLOC(k,t,comp,a), STL_MULTISET_COMP_ALLOC(t,comp,a), STL_SET_COMP_ALLOC(t,comp,a), and STL_VECTOR_ALLOC(t,a) in lieu of deque<t,a>, list<t,a>, and map<k,t,comp,a>, and multimap<k,t,comp,a>, and set<t,comp,a>, and multiset<t,comp,a>, and vector<t,a>, respectively. These macros will produce containers that employ the specified allocators wherever possible.

 
adapter 
deque<> 
list<> 
map<> 
multimap<> 
multiset<> 
set<> 
vector<> 
      found in header 
<deque> 
<list> 
<map> 
<map> 
<set> 
<set> 
<vector> 
      test program 
allocdeq.cc 
alloclst.cc 
allocmap.cc 
allocmmp.cc 
allocmst.cc 
allocset.cc 
allocvec.cc 
 

DEFECT_NO_STRING_CLEAR, ISOcxx_HAS_STRING_CLEAR

In standard C++, the string<> container defines a clear() method that discards a string's contents, thus reducing it to length zero.

Some environments, however, incorrectly do not define this method. The test program clearstr.cc , which ought to compile and execute correctly in a compliant environment, determines the presence of this defect.

For maximum portability, client code is advised to use the macro STRING_CLEAR(s), where s is of type std::string, in place of s.clear().

DEFECT_NO_DEQUE_AT, ISOcxx_HAS_DEQUE_AT
DEFECT_NO_VECTOR_AT, ISOcxx_HAS_VECTOR_AT

In standard C++, the deque<> and vector<> containers define at() methods that provide range-checked subscripting.

Some environments, however, incorrectly do not define these methods. The test programs atdeq.cc  and atvec.cc , which ought to compile and execute correctly in a compliant environment, determine the presence of this defect for their respective containers.

As of this writing, this package provides no cure for this defect, if present.

DEFECT_NO_IOS_BASE, ISOcxx_IOS_BASE

In standard C++, the standard ios header is to define, among others, a class ios_base.

Some environments, however, incorrectly do not provide this class. The test program iosbase.cc, which ought to compile and execute correctly in a compliant environment, determine the presence of this defect. If present, the defect is transparently cured.

DEFECT_NO_IOS_MANIPULATORS, ISOcxx_IOS_MANIPULATORS

Standard C++ specifies the following ios_base manipulators as part of the iostream interface in header <ios>.
 
fmtflags 
boolalpha,   noboolalpha 
showbase,   noshowbase 
showpoint,   noshowpoint 
showpos,   noshowpos 
skipws,   noskipws 
uppercase,   nouppercase 
unitbuf,   nounitbuf 

adjustfield 
internal,   left,   right 

basefield 
dec,   hex,   oct 

floatfield 
fixed,   scientific 
 

Some environments, however, incorrectly do not provide some or all of these. The test program iosmanip.cc, which ought to compile and execute correctly in a compliant environment, determine the presence of this defect. If present, the defect is, in most cases, completely and transparently cured. However, the boolalpha manipulator is not correctly supported in some environments, and so may not have the desired effect.

Client code employing any of the above manipulators should insure that the line: #include <ios> is present. While other headers may implicitly incorporate this one, such behavior is not guaranteed by the Standard.

DEFECT_NO_MAP_COMPARATOR, ISOcxx_OK_MAP_COMPARATOR
DEFECT_NO_MULTIMAP_COMPARATOR, ISOcxx_OK_MULTIMAP_COMPARATOR
DEFECT_NO_MULTISET_COMPARATOR, ISOcxx_OK_MULTISET_COMPARATOR
DEFECT_NO_PRIQ_COMPARATOR, ISOcxx_OK_PRIQ_COMPARATOR
DEFECT_NO_SET_COMPARATOR, ISOcxx_OK_SET_COMPARATOR

In standard C++, the priority_queue<> adapter and the map<>, multimap<>, multiset<>, and set<> containers require, by their nature, a means of ordering (arranging) their respective elements. Such a means is termed a comparator. While a default comparator is provided, users may elect to specify their own.

Some environments, however, incorrectly do not permit users this flexibility. The test programs listed below, which ought to compile and execute correctly in a compliant environment, determine the presence of this defect for these containers.

 
container 
map<> 
multimap<> 
multiset<> 
priority_queue<> 
set<> 
      found in header 
<map> 
<map> 
<set> 
<queue> 
<set> 
      test program 
compmap.cc 
compmmap.cc 
compmset.cc 
comppriq.cc 
compset.cc 
 
For maximum portability, client code is advised to make use of the compliance macros STL_MAP_COMP(k,t,comp), STL_MULTIMAP_COMP(k,t,comp), STL_MULTISET_COMP(t,comp), STL_PRIORITY_QUEUE_CONT_COMP(t,c,comp), STL_SET_COMP(t,comp), in lieu of map<k,t,comp>, multimap<k,t,comp>, multiset<t,comp>, priority_queue<t,c,comp>, set<t,comp>, respectively. These macros will produce containers that employ the specified comparator whenever possible.

DEFECT_NO_PRIQ_CONTAINER, ISOcxx_OK_PRIQ_CONTAINER
DEFECT_NO_QUEUE_CONTAINER, ISOcxx_OK_QUEUE_CONTAINER
DEFECT_NO_STACK_CONTAINER, ISOcxx_OK_STACK_CONTAINER

In standard C++, each of the three containers priority_queue<>, queue<>, and stack<> are adapters; that is, each is merely a specialized interface to a different container. Users may elect to specify a desired underlying container.

Some environments, however, incorrectly do not permit users this flexibility. The test programs listed below, which ought to compile and execute correctly in a compliant environment, determine the presence of this defect for their respective adapters. For maximum portability, client code is advised to make use of the compliance macros STL_PRIORITY_QUEUE_CONT(t,c), STL_QUEUE_CONT(t,c), and STL_STACK_CONT(t,c) in lieu of priority_queue<t,c>, queue<t,c>, and stack<t,c>, respectively. These macros will produce adapters that employ the specified underlying containers wherever possible.

 
adapter 
priority_queue<> 
queue<> 
stack<> 
      found in header 
<queue> 
<queue> 
<stack> 
      test program 
contpriq.cc 
contque.cc 
contstk.cc 
 

DEFECT_NO_PRIQ_CONTAINER_TYPE, ISOcxx_OK_PRIQ_CONTAINER_TYPE
DEFECT_NO_QUEUE_CONTAINER_TYPE, ISOcxx_OK_QUEUE_CONTAINER_TYPE
DEFECT_NO_STACK_CONTAINER_TYPE, ISOcxx_OK_STACK_CONTAINER_TYPE

In standard C++, the containers queue<>, and stack<> are adapters; that is, each is merely a specialized interface to a different container. Each of these adapters is, according to the Standard, required to provide a typedef, named container_type, identifying the underlying container being adapted.

Some environments, however, incorrectly do not supply this typedef. The test programs listed below, which ought to compile and execute correctly in a compliant environment, determine the presence of this defect for their respective adapters. If present, the compliance code transparently cures this defect.

 
adapter 
queue<> 
stack<> 
      found in header 
<queue> 
<stack> 
      test program 
contque.cc 
contstk.cc 
 

DEFECT_NO_DIV_LONG_LONG, ISOcxx_HAS_DIV_LONG_LONG

According to the C++ standard, the header <cstdlib> ought contain an additional signature for the div() function. In particular, the added signature takes two long arguments, returning an ldiv_t entity.

Some environments, however, do not provide this additional signature. A test program, div_l_l.cc, which ought to compile and run correctly in a compliant environment, tests for such a defect. If present, the portability package's compliance code completely and transparently cures this defect.

DEFECT_NO_MIN_MAX, ISOcxx_HAS_MIN_MAX

The functions min() and max() are, according to the C++ standard, to be declared in the header <algorithm>. Some environments, however, do not provide such functions. A test program, min_max.cc, which ought to compile and run correctly in a compliant environment, tests for such a defect. If present, the portability package's compliance code completely and transparently cures this defect.

DEFECT_NO_USER_PLACEMENT_DELETE, ISOcxx_NO_USER_PLACEMENT_DELETE

In accordance with the C++ standard, the delete() operator should be able to take user placement parameters. Some environments, however, do not allow for this.

A test program, placedel.cc, which should compile and run correctly in a compliant environment, tests for this defect. Unfortunately, there is no compliance code known to cure this defect.

DEFECT_NO_WCHAR_FUNCTIONS, ISOcxx_HAS_WCHAR_FUNCTIONS

According to the C++ standard, five functions dealing with multibyte characters are to be declared in the header <cstdlib>. Some environments, however, do not provide these functions. A test program, multibyt.cc, which ought to compile and run correctly in a compliant environment, tests for such a defect. If present, the portability package's compliance code completely and transparently cures this defect.

DEFECT_OLD_IOSTREAM_HEADERS, ISOcxx_NEW_IOSTREAM_HEADERS

The C++ standard mandates (among others) the following iostream-related header files: <fstream>, <iomanip>, <ios>, <iostream>, <istream>, <ostream>, <streambuf>, and <strstream>.  Earlier drafts and implementations of the standard used different (generally similar but of the form <xxx.h>) names for these headers; some environments have not yet made the changes.

Since installation of the portability package implicitly tests for the existence of all mandated headers, no additional program is needed to test for this potential defect. However, as described elsewhere herein, there is a test program, library.cc, that is used to confirm that all mandated library headers are available.

If the defect is present, the compliance code in the portability package completely and transparently cures this defect on all tested platforms.

DEFECT_OLD_STDC_HEADERS, ISOcxx_NEW_STDC_HEADERS

The C++ standard mandates that each standard C header file be of the form <xxx.h>, and that its contents also be available under a second name of the form <cxxx>. For example, the usual <string.h> is also to be available as <cstring>. The difference between the two forms of the header is primarily a namespace issue:
 
form of header name 
<xxx.h> 
<cxxx>
      contents' namespace 
both std:: and ::
only std::
 
Some environments have not yet added the <cxxx> form of the headers.

Since installation of the portability package implicitly tests for the existence of all mandated headers, no additional program is needed to test for this potential defect. However, as described elsewhere herein, there is a test program, library.cc, that is used to confirm that all mandated library headers are available.

If the defect is present, the compliance code in the portability package completely and transparently cures this defect on all tested platforms.

DEFECT_OLD_STL_COUNT, ISOcxx_NEW_STL_COUNT

As originally proposed, count() and count_if() were void functions that returned the results of their respective computations via a side effect on one of their parameters. These functions' signature and behavior were changed during the C++ standardization process such that these functions, now declared in <algorithm>, are no longer void, have one fewer parameter each, and return their results as their respective return's operand.

Some environments still support only the original definitions of these functions. Two test programs, countok.cc and countbad.cc, test for this defect. If the defect is present, the compliance code in the portability package transparently cures this defect on all tested platforms.

DEFECT_OLD_STL_HEADERS, ISOcxx_NEW_STL_HEADERS

The C++ standard incorporates most of the library known as the STL (Standard Template Library). The original reference implementation of this library was done at HP and refined at SGI. That implementation provided a number of header files whose names, during the C++ standardization process, were changed. For example, <vector.h> was renamed <vector>.

In a few cases, the standardization process also moved functionality among headers in addition to renaming them. For example, the former <algo.h> and <algobase.h> headers were first combined, then differently segregated into the new <algorithm> and <numeric> headers.

Some environments still have the original headers' names. However, since installation of the portability package implicitly tests for the existence of all mandated headers, no additional program is needed to test for this potential defect. However, as described elsewhere herein, there is a test program, library.cc, that is used to confirm that all mandated library headers are available.

If the defect is present, the compliance code in the portability package largely. transparently, cures this defect on all tested platforms. The cure does handle the renaming of the headers, but does not now attempt to cure any changes in functionality. (In practice, this has not been a significant problem.)

DEFECT_OLD_STRINGSTREAM, ISOcxx_NEW_STRINGSTREAM

At least one environent fails to provide the <sstream> header mandated by the C++ standard.

Since installation of the portability package implicitly tests for the existence of all mandated headers, no additional program is needed to test for this potential defect. However, as described elsewhere herein, there is a test program, library.cc, that is used to confirm that all mandated library headers are available.

If the defect is present, the compliance code in the portability package transparently, though incompletely, cures this defect on all tested platforms. The compliance code is deemed incomplete in that, while it does provide the required functionality, it does not do so via the means prescribed by the C++ standard.

DEFECT_SGICC_STRING_HEADER, ISOcxx_OK_STRING_HEADER

At least one environent fails to provide the <string> header mandated by the C++ standard.

Since installation of the portability package implicitly tests for the existence of all mandated headers, no additional program is needed to test for this potential defect. However, there is a test program, library.cc, that is used to confirm that all mandated library headers are available.

If the defect is present, the compliance code in the portability package completely and transparently cures this defect on all tested platforms.

DEFECT_WCTYPE_H_NEEDS_UNSIGNED_ENUM, ISOcxx_WCTYPE_H_OK

At least one environent provides a <wctype.h> header that is vulnerable to the DEFECT_NO_UNSIGNED_ENUM described above. Because this defect has no compliance code to cure the defect, a separate defect is needed to expose its existence in this header, as determined by a test program, wctype.cc, which ought to compile and execute correctly in a compliant environment.

If <wctype.h> exhibits the defect, the compliance code in the portability package transparently and completely cures this defect in this header on all tested platforms.

DEFECT_BAD_MAP_DEFAULT_ALLOCATOR, ISOcxx_OK_MAP_DEFAULT_ALLOCATOR

At least one environent provides an incorrect default, in its <map> header, for the allocator argument to the map<> container template. A test program, defmapal.cc, which ought to compile and execute correctly in a compliant environment, tests for the presence of this defect.

If <map> exhibits the defect, the compliance code in the portability package transparently and completely cures this defect in this header on all tested platforms.