JTC1/SC22/WG21
N0784
Doc. No.: X3J16/95-0184
WG21/N0784
Date: September 26, 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
Version 3
Revision History
Version 1 - February 1, 1995: Distributed in pre-Austin mailing.
Version 2 - May 30, 1995: Distributed in pre-Monterey mailing.
Version 3 - September 26, 1995: Distributed in pre-Tokyo mailing.
Closed issues are compressed to save
paper.
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: 18-001
Title: Typedef typedef void fvoid_t(); not used anywhere
Sections: 18.1.2 [lib.stddef.types]
Status: closed
Resolution: Typedef removed (Austin resolution)
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-002
Title: Redundant typedefs
Sections: 18.1.2 [lib.stddef.types]
Status: closed
Description:
The second box in this chapter claims that this typedef is redundant
with what you find in <cstddef>:
typedef T ptrdiff_t;
The third box in this chapter claims that this typedef is redundant
with what you find in <ctime>, <cstddef>, <cstdio>, and <cstring>:
typedef T size_t;
The fourth box in this chapter claims that this typedef is redundant
with what you find in <cwchar> and <cwctype>:
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.
Resolution: Removed (Austin resolution)
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-003
Title: Call to set_new_handler() with null pointer
Sections: 18.4.1.1.1 operator new [lib.op.new]
Status: closed
Resolution: According to ANSI X3J16/95-0047, ISO WG21/N0647
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-004
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: closed
Resolution: The comment is removed (Austin resolution)
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-005
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: closed
Resolution: This is now stated explicitly as a "Requirement", which
is defined as a precondition in 17.2.1.3.
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-006
Title: <stdarg.h> and references
Sections: 18.7 Other runtime support [lib.support.runtime]
Status: closed
Resolution: According to Motion 2 c in Monterey, see paragraph 7
in 5.2.2 [expr.call].
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-007
Title: denormal_loss member to the numeric_limits class
Sections: 18.2.1 Numeric limits [lib.limits]
Status: closed
Resolution: According to Motion 19 in Monterey. The member was
renamed to "has_denormal_loss".
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-008
Title: global operator new
Sections: 18.4 Dynamic memory management [lib.support.dynamic]
Status: closed
Resolution: Move all of them to global scope according to Motion 9 in
Monterey (also see N0748 = 95-0148, core issue 463).
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-009
Title: whither exception?
Sections: 18 and 19
Status: closed
Resolution: Class exception moved from <stdexcept> to <exception>
and from clause 19 to clause 18, according to Motion 19
in Monterey.
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-010
Title: Exception specifications for class numeric_limits
Sections: 18.2.1.1, 18.2.1.2, 18.2.1.4
Status: closed
Resolution: "throw()" added to all static member functions of the
numeric_limits class, according to Motion 19 in Monterey.
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-011
Title: Exception specifications for set_new_handler()
Sections: 18.4, 18.4.2.3
Status: closed
Resolution: "throw()" added to set_new_handler(), according to Motion
19 in Monterey.
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-012
Title: Exception specifications for set_unexpected() and
set_terminate()
Sections: 18.6, 18.6.1.3, 18.6.2.2
Status: closed
Resolution: "throw()" added to set_unexpected() and set_terminate(),
according to Motion 19 in Monterey.
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-013
Title: deleting a pointer obtained by a nothrow version of
"operator new"
Sections: 18.4.1.1 [lib.new.delete.single] and
18.4.1.2 [lib.new.delete.array]
Status: active
Description: Steve Clamage in c++std-lib-3930:
Some comments in comp.std.c++ brought to my attention that we need
more words in 18.4.1 Storage allocation and deallocation
[lib.new.delete].
Section 5.3.5 Delete [expr.delete] says that deleting a pointer
obtained from a placement-new has undefined results. So what about
T* p = new (nothrow()) T;
delete p;
Surely this must be well-defined.
I think we need to clarify that the nothrow version of "operator new"
returns a pointer obtained as if acquired from the ordinary version
of "operator new", and that requirement is binding on replacement
versions of those functions.
Proposed Resolution:
Add two more sentences to the "Required Behavior" clause after the
interface of the nothrow call of "operator new" in 18.4.1.1
[lib.new.delete.single]:
The nothrow version of "operator new" returns a pointer
obtained as if acquired from the ordinary version. This
requirement is binding on a replacement version of this
function.
The same for 18.4.1.2 [lib.new.delete.array], i.e. add two more
sentences to the "Required Behavior" clause after the interface of
the nothrow call of "operator new[]":
The nothrow version of "operator new[]" returns a pointer
obtained as if acquired from the ordinary version. This
requirement is binding on a replacement version of this
function.
Resolution:
Requestor: Steve Clamage, stephen.clamage@eng.sun.com
Owner: Mats Henricson, mats.henricson@eua.ericsson.se
Emails: c++std-lib-3930
Papers: None.
Discussion: None.
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-014
Title: nothrow versions of "operator delete"
Sections: 18.4 Dynamic memory management [lib.support.dynamic]
Status: active
Description: Nathan Myers in c++std-lib-4176:
With the addition of placement new(size_t, nothrow()), we don't have
specified the correct action if there is an exception in the resulting
constructor. What's needed is a corresponding operator delete.
Proposed Resolution:
Nathan Myers in c++std-lib-4176 (continued):
Proposed Resolution:
Add to [lib.new.delete.single], after the declaration for
void operator delete(void* ptr) throw();
a declaration:
void operator delete(void* ptr, const nothrow&) throw();
documented to behave identically as delete(void*).
Resolution:
Requestor: Nathan Myers, myersn@roguewave.com
Owner: Mats Henricson, mats.henricson@eua.ericsson.se
Emails: c++std-lib-4176
Papers: None.
Discussion: None.
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-015
Title: Should terminate() and unexpected() be in <exception> ?
Sections: 18.6 Exception handling [lib.support.exception]
18.6.2.4 unexpected [lib.unexpected]
18.6.3.3 terminate [lib.terminate]
Status: active
Description: Nathan Myers in a private mail:
[The discussion is why terminate() and unexpected() are declared
in <exception>. I had speculated: ]
> > 1. They are present so that users can call them to simulate
> > the event normally generated only by the runtime environment.
> > 2. They are present so that users can restore the original behavior,
> > even if they didn't originally call set_*_handler.
> > 3. They are present so their address can be compared against
> > the result of calling set_*_handler.
[spicer replied:]
> Of these, I believe that only #1 is possible. The default terminate
> handler is not terminate(), but rather an implementation defined
> function that calls abort(). If you were to do
>
> set_terminate(&terminate);
>
> you would probably end up with an infinite loop (until you ran out
> of stack space). For the same reason, a call to set_terminate would
> never return the address of terminate() as the previous handler value.
> The same applies to unexpected.
>
> It seems odd to permit #1, particularly for unexpected. I would actually
> prefer that it be undefined if a user calls either of these
> functions.
OK, right. This is worth bringing up in the Lib WG. I suspect
that we didn't really look closely enough at this and just assumed
as I did that unexpected() was itself the default handler.
If these functions aren't mentioned in a header file, and can't
be called by users, why mention them at all? On the other hand,
wouldn't it be simpler if they were just the default handler?
This area needs further investigation.
Proposed Resolution:
Resolution:
Requestor: Nathan Myers, myersn@roguewave.com
Owner: Mats Henricson, mats.henricson@eua.ericsson.se
Emails: None.
Papers: None.
Discussion: None.
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-016
Title: Extra members in numeric_limits in support of IEC 559
Sections: 18.2.1 Numeric limits [lib.limits]
Status: active
Description:
Nathan Myers in a private email:
In support of iec559 there should be two or three other parameters
describing denormalized number behavior.
IEC 559 is the same as IEEE 754, and it is a subset of "ISO/IEC 10967-1,
Language independent arithmetic - Part 1: Integer and floating point
arithmetic" (also known as LIA-1).
Proposed Resolution:
Resolution:
Requestor: Nathan Myers, myersn@roguewave.com
Owner: Mats Henricson, mats.henricson@eua.ericsson.se
Emails: c++std-all-1262 mentions LIA-1.
Papers: Suggested reading is ISO/IEC 10967-1:1994.
Discussion:
Someone needs to do some real analysis here. There are quite a few open
issues:
1. Are we REQUIRED to be LIA-1 compliant?
2. What are they doing in WG14 in this area?
3. How do we keep compatibility with C? Is it possible?
4. Is it enough to add a few new members to numeric_limits, or do we need
to add a whole bunch of extra stuff (LIA-1, Annex E.4 suggests a
<lia.h> header for C implementations wishing to comply to LIA-1).
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-017
Title: Run-time dependent traps in numeric_limits
Sections: 18.2.1 Numeric Limits [lib.support.limits]
Status: active
Description: Mike Lijewski in c++std-lib-3975:
>I can imagine an implementation where
>the value of numeric_limits<double>::traps depends on the setting
>of some user-settable math library flags; i.e. the value of
>numeric_limits<double>::traps could be true in one part of a
>program and false in another, depending on what, if any,
>OS-specific math library calls the user's made. In any case, I
>don't see a good reason why this should be precluded.
The problem here is that changing this member to be an inline static
(member) function would impose a performance overhead.
Another problem is that noone has done a proper and close reading of
LIA-1. This is needed in order to make sure we do a general solution
to the problem of conforming to LIA-1.
Proposed Resolution:
Resolution:
Requestor: Mike Lijewski, lijewski@roguewave.com
Owner: Mats Henricson, mats.henricson@eua.ericsson.se
Emails: c++std-lib-3975.
Papers: Suggested reading is ISO/IEC 10967-1:1994.
Discussion: None.
-------------------------------------------------------------------------
Work Group: Library Clause 18
Issue Number: 18-018
Title: Run-time dependent rounding in numeric_limits
Sections: 18.2.1 Numeric limits [lib.limits]
Status: active
Description:
There are systems where the rounding style for floating point numbers
isn't constant. This member:
numeric_limits<float|double|long double>::round_style
can be changed by calling the IEEE function fpsetround at run time.
Additionally if the initial rounding style is set by the run-time
environment, the initializer for round_style isn't a constant
expression as it can only be determined by calling fpgetround and
related functions.
Proposed Resolution:
1. Add a new enum value to "18.2.1.3 [lib.round.style]":
namespace std {
enum float_round_style {
round_indeterminate = -1,
round_toward_zero = 0,
round_to_nearest = 1,
round_toward_infinity = 2,
round_toward_neg_infinity = 3,
round_runtime_dependent = 4 // New enum value
};
}
2. Add a new inline static (member) function to "18.2.1.1
[lib.numeric.limits]":
namespace std {
template<class T> class numeric_limits {
public:
// Current list
static float_round_style current_round_style() throw(); // New
};
}
This function shall return the current round style, and may therefore
not return float_round_style::round_runtime_dependent.
3. It should also be added in the text that these members are meaningful
for floating points only.
Resolution:
Requestor: Dominik Strasser, Dominik.Strasser@mch.sni.de
Owner: Mats Henricson, mats.henricson@eua.ericsson.se
Emails: c++std-lib-4073, 4091
Papers: Suggested reading is ISO/IEC 10967-1:1994.
Discussion:
It was difficult to select a good name for the new enum value. Dominik
and I had at least this list to choose from:
round_runtime_dependent // Selected
round_varying
round_variable
round_fluctuate
round_runtime_determinable
round_volatile
round_non_constant
Someone fluent in English might have objections to the suggested name.