Doc. No.: X3J16/95-0049 WG21/ N0649 Date: February 1, 1995 Project: Programming Language C++ Reply To: Mats Henricson Ellemtel Telecom Systems Labs mats.henricson@eua.ericsson.se Clause 18 (Language support library) Issues List Revision 1 Revision History Version 1 - February 1, 1995: Distributed in pre-Austin mailing. Introduction This document is a summary of the issues identified in Clause 18. For each issue the status, a short description, and pointers to relevant reflector messages and papers are given. This evolving document will serve as a basis of discussion and historical for Language support library issues and as a foundation of proposals for resolving specific issues. Issues ------------------------------------------------------------------------- Work Group: Library Clause 18 Issue Number: 1 Title: Typedef typedef void fvoid_t(); not used anywhere Sections: 18.1.2 [lib.stddef.types] Status: active Description: The first box in this chapter claims that this typedef is not used anywhere: typedef void fvoid_t(); I think this is correct. I have done a global search through the previous CD and this is the only place where fvoid_t is mentioned (except for in tables 28 and 40 where it is just listed). This means that the first paragraph under 18.1.2 should be removed together with its code example, and the box itself. Proposed Resolution: Remove the typedef Requestor: Mats Henricson, mats.henricson@eua.ericsson.se Owner: Discussion: However, Andy pointed out this problem to me: Removing the typedef would not be editorial, because it would change the meaning of a program that uses it. Is the use of this typedef widespread? ------------------------------------------------------------------------- Work Group: Library Clause 18 Issue Number: 2 Title: Redundant typedefs Sections: 18.1.2 [lib.stddef.types] Status: active Description: The second box in this chapter claims that this typedef is redundant with what you find in : typedef T ptrdiff_t; The third box in this chapter claims that this typedef is redundant with what you find in , , , and : typedef T size_t; The fourth box in this chapter claims that this typedef is redundant with what you find in and : typedef T wint_t; This seems to be correct, so the involved paragraphs under 18.1.2 should be removed together with code examples and the boxes themselves. Proposed Resolution: Remove them. Requestor: Mats Henricson, mats.henricson@eua.ericsson.se Owner: Discussion: Andy pointed out this problem to me: If ptrdiff_t is defined in two places, removing one of them is not editorial because a program could presumably include one and not the other. The same problem holds for all the typedefs above. ------------------------------------------------------------------------- Work Group: Library Clause 18 Issue Number: 3 Title: Call to set_new_handler() with null pointer Sections: 18.4.1.1.1 operator new [lib.op.new] Status: active Description: I think it is still an issue what happens if the last call to set_new_handler() was a null pointer, i.e. should the infamous footnote be there or not? Proposed Resolution: Requestor: Mats Henricson, mats.henricson@eua.ericsson.se Owner: Discussion: Andy agrees, and adds: A programmer must either be entitled to assume that "new" never returns 0 or must not be entitled to assume it. I can see no middle ground possible. I am not up to date with the discussion on this. ------------------------------------------------------------------------- Work Group: Library Clause 18 Issue Number: 4 Title: Inherited members explicitly mentioned Sections: 18.5.2.1 Class bad_cast [lib.bad.cast] 18.5.2.1.3 bad_cast::what [lib.bad.cast::what] Status: active Description: Why is bad_cast explicitly noted to have an inherited member function: // virtual string what() const; while the class bad_typeid is not, even though they inherit from the same base class logic_error? I think the comment noted above should be removed. It does not serve any purpose. The fact that public base class member functions are inherited should be known by all readers of the document. Proposed Resolution: Remove the comment Requestor: Mats Henricson, mats.henricson@eua.ericsson.se Owner: Discussion: I think these comments are quite widespread. If we decide to remove this comment, then I think we should do it throughout the document. ------------------------------------------------------------------------- Work Group: Library Clause 18 Issue Number: 5 Title: Call to set_terminate() or set_unexpected() with null pointer Sections: 18.6.1.2 set_terminate [lib.set.terminate] 18.6.2.2 set_unexpected [lib.set.unexpected] Status: active Description: What happens if set_terminate() or set_unexpected() is called with a null pointer as argument? "18.6.1.2 [lib.set.terminate]" claims: f shall not be a null pointer. What does that mean? The compiler cannot know beforehand, so is it implementation defined what happens? Or undefined? Proposed Resolution: Requestor: Mats Henricson, mats.henricson@eua.ericsson.se Owner: Discussion: -------------------------------------------------------------------------