JTC1/SC22/WG21
N0770
Document No: BSI/95-0013
X3J16/95-0170
WG21/N0770
Date: 22/9/95
Project: Programming Language C++
Reply-To: Steve Rumsby
steve@maths.warwick.ac.uk
BSI C++ Panel Issues List
Compiled by
Steve Rumsby
steve@maths.warwick.ac.uk
Introduction
This document is a list of all outstanding problems found by the BSI C++ panel
(IST/5/-/21) in the WG21 working paper in its various revisions. The issues and
their descriptions have been contributed by many of the panel members - the
author of this document is simply the keeper of the database. Text inside
square brackets is my comments on the issue, and not part of the official issue
description.
The status of all the issues on this list is either Open or Fixed. Open issues
are issues we believe still exist in the most recent version of the committee's
working paper. Fixed issues are issues which exist in the CD sent for
balloting, but which we believe have subsequently been fixed in one way or
another. They are listed here, separately at the end, for completeness, and to
ensure that the committee is made aware of our interest in the issues.
======================================================================
Owner: Steve Rumsby
Summary: lvalue/rvalue
Category: Terminology
Date: 17/7/94
Status: Open
Number: 2
Section:
X-Ref:
Description:
The current uses of the terms lvalue and rvalue do not mean what people
expect them to mean from the ISO C usage.
We feel that the meanings given to the terms "lvalue" and "rvalue" by
the working paper are not the commonly accepted meanings, and are not
particularly intuitive meanings. In particular, if use of this terminology
persists, we require that the term "rvalue" shall not describe a value
that refers to an object. More generally, we feel that the lvalue/rvalue
model itself is flawed in the context of C++.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Terminology issues
Category: Clarification
Date: 19/7/94
Status: Open
Number: 7
Section:
X-Ref:
Description:
There are many inconsistencies in terminology in the current working
paper, and many uses of language that would be hard to understand for a
non-native English speaker. In particular we feel that the following must
be fixed: "Correct", "erroneous", and similar words shall be replaced by
"well-formed" or "ill-formed" as appropriate.
In some places the phrase "implementation dependent" is used, but this
is not defined by the working paper. The phrase shall have a definition,
or shall not be used.
The definition of "implementation defined" states that the standard will
delineate the range of allowable behaviours. In fact there are cases
where it cannot - this delineation should be optional.
The behaviour of "unspecified" states that the standard will delineate
the range of allowable behaviours. This is not done consistently. All
uses of "unspecified" shall specify the range of allowable behaviours.
All uses of "may not" shall be removed. Most uses seem to require "shall
not", but some are ambiguous.
All other uses of "may" shall be reviewed. These are likely to be
particularly confusing for the non-native English speakers.
We would like to see all uses of the word "pointer" qualified with "to
object", "to function", or "to member" as appropriate. Since these are
distinct types, and generally have different representations, we feel
this is a necessary and important qualification.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Non-required diagnostics
Category: Diagnostics
Date: 19/7/94
Status: Open
Number: 9
Section:
X-Ref:
Description:
We believe that current technology now allows many of the non-required
diagnostics to be diagnosed without excessive overhead. For example, the
use of & on an object of incomplete type, when the complete type has a
user-defined operator&(). We would like to see diagnostics for such cases.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Pointer to function conversions
Category: Language change
Date: 19/7/94
Status: Open
Number: 10
Section:
X-Ref:
Description:
Because of the restrictions on conversions involving pointers to
functions, and in particular the implementation defined aspects of
conversions to and from void *, we feel that all conversions involving
pointers to functions should be deprecated. We would resist any proposal
for a generic "pointer to member" type, for similar reasons.
Conversions between (*)() and void * were outlawed at the July 94 meeting.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Multi-threading
Category:
Date: 19/7/94
Status: Open
Number: 11
Section:
X-Ref:
Description:
No constraints should be put into the WP that preclude an implementation
using
multi-threading, where available and appropriate.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Terminology
Date: 21/7/94
Status: Open
Number: 13
Section:
X-Ref: 148
Description:
Confusion of processor, compiler, implementation throughout Change all
uses of the terms "compiler" and "implementation" to "processor".
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Terminology
Date: 21/7/94
Status: Open
Number: 14
Section:
X-Ref:
Description:
Change all occurances of "error" to "ill-formed" and all occurances of
"correct" to "well-formed".
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Terminology
Date: 21/7/94
Status: Open
Number: 16
Section:
X-Ref:
Description:
The term 'implementation dependent' is not defined by the WP. Replace all
occurrences of "implementation dependent" with either "implementation
defined" or "unspecified" as appropriate to each case.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: STL operator templates
Category: Language change
Date: 30/1/95
Status: Open
Number: 135
Section:
X-Ref:
Description:
The STL provides a set of templates defining the equality and inequality
operators in terms of other operators in the set. The intention is
that people defining their own classes to be used with the STL have
to provide only some of the necessary operators, and the others will
be "magically" provided. Currently, because operators and namespaces
do not interact in a useful way, this is not a problem. However, this
will be fixed and then it might be impossible to avoid having these
operator templates apply to user written classes, even when they are
not appropriate. Any solution to the operator/namespace problem must
provide a way of controlling these operator templates.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: Allow operator void()
Category: Language change
Date: 27/6/95
Status: Open
Number: 228
Section:
X-Ref:
Description:
A decision was taken to make operator void() ill-formed on the grounds
that implicit calls to it would be dangerous / confusing. Explicit calls
were also a source for confusion. However, the increase of template
programming leads to the following scenario:
template<class Arg>
class Func : public unary_function<Arg, void>
{
public:
result_type f(const Arg&); // result_type == void
operator result_type(); // operator void() !!
};
This assumes that 'typedef void result_type;' followed by uses of
'result_type' is legal anyway (not entirely sure).
Action: add issue to revisit operator void()
Proposed resolution: allow operator void() to be declared in templates
but uses of the operator are ill-formed. Implicit conversions never use
operator void().
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 11/8/95
Status: Open
Number: 245
Section:
X-Ref:
Description:
Change all occurances of "well-formed" to "conforming".
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 11/8/95
Status: Open
Number: 551
Section:
X-Ref:
Description:
Review all accurances of "an implementation" and "each implementation"
- most should be changed to "the implementation".
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 27/6/95
Status: Open
Number: 229
Section: 01.1 [intro.scope] para 2
X-Ref:
Description:
Delete the last sentence and Annex C.1.2. This is the first standard
for C++, what happened prior to 1985 is not relevant to this document.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 27/6/95
Status: Open
Number: 230
Section: 01.2 [intro.refs] para 1
X-Ref:
Description:
Delete the last sentence - it adds nothing to the document.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 27/6/95
Status: Open
Number: 231
Section: 01.2 [intro.refs] para 1
X-Ref:
Description:
Change:
ISO/IEC 9899:1990, C Standard
to:
ISO/IEC 9899:1990 Programming Languages - C
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 27/6/95
Status: Open
Number: 232
Section: 01.2 [intro.refs] para 1
X-Ref:
Description:
Change:
ISO/IEC 9899:1990/DAM 1, Amendment to C Standard
to:
ISO/IEC:1990 Programming languages -- C AMENDMENT 1: C Integrity
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 27/6/95
Status: Open
Number: 233
Section: 01.2 [intro.refs] para 2
X-Ref:
Description:
Change:
standard
to:
Standard
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: Example not made clear
Category: Editorial
Date: 18/9/95
Status: Open
Number: 588
Section: 01.3 [intro.defs] para 1
X-Ref:
Description:
In the "dynamic type" bullet, add "[Example:" and "]" around the second
sentence:
If a pointer (8.3.1)..."pointer to D."
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: Incorrect definition for signature
Category:
Date: 18/9/95
Status: Open
Number: 590
Section: 01.3 [intro.defs] para 1
X-Ref:
Description:
As it stands, the text does not differentiate amongst function members of
derived classes that otherwise have the same signature, since "whether
the function is a direct member of its class or inherited from a base
class" is a boolean, either-or, quantity. Suggest changing:
..., the CV-qualifiers (if any) on the function itself and whether
the function is a direct member of its class or inherited from
a base class...
to:
and the static type of the `this' pointer
Also, how are the signatures of two static function members in two
separate classes distinguished?
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 27/6/95
Status: Open
Number: 234
Section: 01.3 [intro.defs] para 1, diagnostic message
X-Ref:
Description:
Change:
message output
to:
output messages
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 27/6/95
Status: Open
Number: 235
Section: 01.3 [intro.defs] para 1, dynamic type
X-Ref:
Description:
This is not a very complete definition. Please supply an exhaustive
list of all objects types that can be dynamic and rules for determining
these types.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 27/6/95
Status: Open
Number: 237
Section: 01.3 [intro.defs] para 1, implementation-defined behaviour
X-Ref:
Description:
Delete the last sentence. The Standard cannot and should not delineate
the possible behaviours.
----------------------------------------------------------------------
Owner: Derek Jones
Summary: Missing character set definitions
Category:
Date: 27/6/95
Status: Open
Number: 239
Section: 01.3 [intro.defs] para 1, multibyte character
X-Ref:
Description:
The term basic character set is not defined by the CD. ISO 9899
(Clause 5.2.1) goes to great lengths to precisely define character
set terminology. The C++ standard should adopt the same terminology
and use the definitions contained in ISO 9899. Suggest that paragraphs
from Clause 5.2.1 of ISO 9899 be copied into this section of the CD.
The concept of execution character set also needs to be added to the
C++ standard.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 27/6/95
Status: Open
Number: 240
Section: 01.3 [intro.defs] para 1, parameter
X-Ref:
Description:
Delete the sentence:
A function call can be said ... to have parameters
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary:
Category: Editorial
Date: 11/8/95
Status: Open
Number: 553
Section: 01.3 [intro.defs] para 1, parameter
X-Ref:
Description:
In the last two sentences, change:
...parameters."
to:
...parameters".
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary:
Category: Editorial
Date: 11/8/95
Status: Open
Number: 554
Section: 01.3 [intro.defs] para 1, parameter
X-Ref:
Description:
Footnote 2 is not referenced from the main text.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 27/6/95
Status: Open
Number: 242
Section: 01.3 [intro.defs] para 1, static type
X-Ref:
Description:
In the last sentence, delete:
and does not change.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 27/6/95
Status: Open
Number: 243
Section: 01.3 [intro.defs] para 1, undefined behaviour
X-Ref:
Description:
Delete the second and third sentences.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 27/6/95
Status: Open
Number: 244
Section: 01.3 [intro.defs] para 1, undefined behaviour
X-Ref:
Description:
ISO 9899 states that 'Undefined behaviour is otherwise indicated in
this International Standard by the words "undefined behaviour" or by
the omission of any explicit definition of behaviour'. The C++ standard
should also adopt the rule that omission of explicit definition of
behaviour results in undefined behaviour.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 246
Section: 01.3 [intro.defs] para 1, well-formed program
X-Ref:
Description:
The standard should introduce the concept of Strict Conformance, that
is a program that contains no undefined, implementation defined or
unspecified behaviours.
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: Use a semi-colon list for "parameter"
Category: Editorial
Date: 18/9/95
Status: Open
Number: 589
Section: 01.3 [intro.defs] 1
X-Ref:
Description:
The bullet item for "parameter is poorly punctuated, since it uses
subordinate clauses that are themselves lists in elements of the list.
Use semi-colons to separate elements of the outermost list, and commas
to separate the elements of the subordinate clauses.
Also add the conjunction "or" at strategic places. Suggested re-wording:
-- parameter: an object or reference declared as part of a function
declaration or definition [, or] in the catch clause
of an exception handler [,] that acquires a value on
entry to the function or handler [;] an identifier from
the comma-separated list bounded by the parentheses
immediately following the macro name in a function-like
macro definition [;] or a template-parameter.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 11/8/95
Status: Open
Number: 557
Section: 01.3 [intro.refs] para 1, argument
X-Ref: 241
Description:
This does not mention template arguments - it should.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 27/6/95
Status: Open
Number: 241
Section: 01.3 [intro.refs] para 1, parameter
X-Ref: 557
Description:
"... or a template-parameter". Given the effort taken in tying down the
other types of parameters this concept needs a bit more explanation at
this point.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 248
Section: 01.5 [intro.memory] para 1
X-Ref:
Description:
Change:
... C++ program is one or ...
to:
... C++ program consists of one or ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 249
Section: 01.5 [intro.memory] para 1
X-Ref:
Description:
Footnote 3. Change:
... to disregard this requirement ...
to:
... to disregard any requirement ...
[This is the "as if" rule. Is it stated in normative text anywhere
else? Should it be?]
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category: Editorial
Date: 15/9/95
Status: Open
Number: 570
Section: 01.5 [intro.memory] para 1
X-Ref:
Description:
In the third sentence, "high-order" should be italicised.
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 15/9/95
Status: Open
Number: 571
Section: 01.5 [intro.memory] para 1
X-Ref:
Description:
Change the fourth sentence to:
The memory available to a C++ program is one or more sequences
of contiguous bytes.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 250
Section: 01.5 [intro.memory] para 2
X-Ref:
Description:
Delete this paragraph.
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary:
Category:
Date: 18/9/95
Status: Open
Number: 594
Section: 01.6 [intro.object para 3
X-Ref:
Description:
This paragraph doesn't seem to be defining anything at all, or
to be giving us any new information not previously given in other
clauses. Delete the paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 253
Section: 01.6 [intro.object] para 1
X-Ref:
Description:
Change:
... the meaning of the ...
to:
... the interpretation of the ...
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category: Editorial
Date: 15/9/95
Status: Open
Number: 572
Section: 01.6 [intro.object] para 1
X-Ref:
Description:
In the sixth sentence, "type" should be italicised.
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: Confusion between "complete object" and "the complete object of"
Category: Editorial
Date: 18/9/95
Status: Open
Number: 593
Section: 01.6 [intro.object] para 1
X-Ref:
Description:
There is confusion between "complete object" and "the complete object of".
The definition of "the complete object of" can be misread as running
on from the definition of "complete object". Suggest spliting the
paragraph in two, with the second paragraph starting with "For every
object x, there is some object ...".
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: Notes on the format of this document belong at the front!
Category: Editorial
Date: 18/9/95
Status: Open
Number: 596
Section: 01.7 [intro.comlpiance] para 5
X-Ref:
Description:
This clause describes the fomatting conventions of the document itself.
Since several of the notations have already been used, it makes sense to
move this clause to as near to the start of the document as possible.
Logically, it belongs between [intro.scope].2 and [intro.scope].3.
Notes on the formatting conventions used throughout the document are
also required here.
Suggested change: Move [intro.compliance].5 to before [intro.scope].3,
and add text as follows :
In this International Standard a term is italicised when it is
first defined.
----------------------------------------------------------------------
Owner: Derek Jones
Summary: No definition of a strictly conforming program
Category: Modelling
Date: 15/6/95
Status: Open
Number: 218
Section: 01.7 [intro.compliance]
X-Ref:
Description:
A definition of a strictly conforming program is required, as is provided
by the C standard.
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: Repunctuate and reorder paragraphs for clarity
Category:
Date: 18/9/95
Status: Open
Number: 595
Section: 01.7 [intro.compliance] para 1-3
X-Ref:
Description:
These clauses use terms before their definition, and their punctutation
is a mess. They need reordering, and the "except as noted herein"
qualification is redundant. Also, there is no such thing as a
"diagnosable error".
The phrases "diagnosable semantic rules" and "no diagnostic is required"
may also be required to be italicised. There is a separate open issue
on the need to add clause describing the formatting conventions used
throughout the document (for when terms are defined, and so forth).
Suggested change:
The set of "diagnosable semantic rules" consists of all semantic
rules in this International Standard except for those rules
containing the explicit notation that "no diagnostic is required".
Every conforming C++ processor shall, within its resource limits,
accept and correctly execute well-formed C++ programs, and shall
issue at least one diagnostic message when presented with any
ill-formed program that contains a violation of any diagnosable
semantic rule or of any syntax rule.
If an ill-formed program contains no violations of diagnosable
semantic rules, this International Standard places no requirement
on processors with respect to that program.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 255
Section: 01.7 [intro.compliance] para 2
X-Ref:
Description:
Change:
. diagnosable errors, this
to:
This
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 256
Section: 01.7 [intro.compliance] para 4
X-Ref:
Description:
Change "standard" to "International Standard"
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 15/9/95
Status: Open
Number: 573
Section: 01.8 [intro.exectution] para 6,7
X-Ref:
Description:
The perfectly legitimate use of the adjective 'volatile' in these 2
paras could lead to confusion with the keyword 'volatile'. Suggested
Change: Just omit the adjective.
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: The last sentence is not part of the list
Category: Editorial
Date: 18/9/95
Status: Open
Number: 599
Section: 01.8 [intro.execution] para
X-Ref:
Description:
"More stringent correspondences between abstract and actual semantics" is
not one of the "least requirements on a conforming implementation". This
text is non-normative (of course implementations are free to impose more
stringent correspondences if they so wish!).
Suggest making the text beginning "More stringent correspondences between
abstract and actual semantics ..." into a footnote.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 264
Section: 01.8 [intro.execution] para 10
X-Ref:
Description:
It is not true to say that values of objects at the previous sequence
point may be relied on. If an object has a new value assigned to it
and is not of type sig_atomic_t the bytes making up that object may be
individually assigned values at any point prior to the next sequence
point. So the value of any object that is modified between two sequence
points is indeterminate between those two points. This paragraph needs
to be modified to reflect this state of affairs.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 265
Section: 01.8 [intro.execution] para 11
X-Ref:
Description:
Delete this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 266
Section: 01.8 [intro.execution] para 12
X-Ref:
Description:
Delete the third bullet item.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 267
Section: 01.8 [intro.execution] para 13
X-Ref:
Description:
This is a definition and should appear under definitions. Move it to 1.3
(intro.defs).
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 268
Section: 01.8 [intro.execution] para 14
X-Ref:
Description:
Two examples are given to illustrate the Note. The second example adds
little new insight and should be removed.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 269
Section: 01.8 [intro.execution] para 17
X-Ref:
Description:
There are two cases given in the Example. One is sufficient and the
second should be removed.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 270
Section: 01.8 [intro.execution] para 18
X-Ref:
Description:
This paragraph should be deleted, and the information moved to the
relevant sub-clauses of clause 5.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 257
Section: 01.8 [intro.execution] para 2
X-Ref:
Description:
Delete "(for example, sizeof(int))"
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 259
Section: 01.8 [intro.execution] para 3
X-Ref:
Description:
Delete "(for example, the order of evaluation of arguments to a function)"
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 260
Section: 01.8 [intro.execution] para 3
X-Ref:
Description:
Delete second sentence ("In each case...behaviours"). The standard does
not define the set of allowable behaviours.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 261
Section: 01.8 [intro.execution] para 4
X-Ref:
Description:
Delete "(for example, the effect of dereferencing the null pointer)"
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 15/9/95
Status: Open
Number: 574
Section: 01.8 [intro.execution] para 7
X-Ref:
Description:
The term "lvalue" is used in this para but it has not yet been defined.
Suggest adding a definition of lvalue and rvalue to [intro.defs]
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: Terms being defined must be italicised
Category: Editorial
Date: 18/9/95
Status: Open
Number: 597
Section: 01.8 [intro.execution] para 7
X-Ref:
Description:
In the final sentence. italicise the phrase "sequence points".
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: Poor grammar
Category: Editorial
Date: 18/9/95
Status: Open
Number: 598
Section: 01.8 [intro.execution] para 8
X-Ref:
Description:
Change:
...execution of the called function is completed.
to:
...execution of the called function has completed.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 263
Section: 01.8 [intro.execution] para 9
X-Ref:
Description:
What is a "needed side-effect"? This paragraph, along with footnote 3
appears to be a definition of the C standard "as-if" rule. This rule
should be defined as such.
[Proposed definition of "needed": if the output of the program depends
on it.]
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 271
Section: 02 [lex] para 1
X-Ref:
Description:
Delete sentences 4, 5 and 6 (last three sentences).
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: Interaction of templates with phases of translation
Category: Clarification
Date: 21/7/94
Status: Open
Number: 19
Section: 02.1 [lex.phases]
X-Ref:
Description:
Needs to be specified.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 272
Section: 02.1 [lex.phases] para 1, phase 8
X-Ref:
Description:
To agree with the wording in ISO 9899, change:
The translation units that will form a program are combined.
to:
The translation units are combined to form a program.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 273
Section: 02.2 [lex.trigraph] para 1
X-Ref:
Description:
Delete and replace with wording from C standard:
All occurrences in a source file of the following sequences of
three characters (called trigraph sequences) are replaced with the
corresponding single character. No other trigraph sequence exist.
Each ? that does not begin one of the trigraphs listed above is
not changed.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: pp-number has no grammar
Category:
Date: 21/7/94
Status: Open
Number: 20
Section: 02.3 [lex.pptoken]
X-Ref: Core issue 519
Description:
pp-number has no grammar. Use the grammar from the ISO C standard.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 274
Section: 02.3 [lex.pptoken] para 3
X-Ref:
Description:
Change:
... lexically analsysed ...
to:
... parsed ...
to agree with wording in C standard.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 275
Section: 02.3 [lex.pptoken] para 3
X-Ref:
Description:
Delete ", even if that would cause further lexical analysis to fail" to
agree with existing, clear wording in C standard.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 277
Section: 02.6 [lex.comment] para 1
X-Ref:
Description:
Delete sentence 4.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 282
Section: 02.8 [lex.key] para 4
X-Ref:
Description:
Change:
After preprocessing, each ...
to:
Each ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 283
Section: 02.8 [lex.key] para 5
X-Ref:
Description:
Delete this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 284
Section: 02.9.1 [lex.icon] para 1
X-Ref:
Description:
This is a clumsy rewrite of the description in Clause 6.1.3.2 of the
C standard. Replace by the text contained in the two paragraphs of the
Description in Clause 6.1.3.2.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 285
Section: 02.9.1 [lex.icon] para 2
X-Ref:
Description:
This is a clumsy rewrite of the semantics in Clause 6.1.3.2 of the C
standard. Replace by the text contained in the two paragraphs of the
Semantics in Clause 6.1.3.2.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 286
Section: 02.9.1 [lex.icon] para 3
X-Ref:
Description:
Change:
A program is ill-formed if it contains...
to:
A program is ill-formed if one of its translation units
contains...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Open
Number: 287
Section: 02.9.1 [lex.icon] footnote 16
X-Ref:
Description:
This statement of a well known fact is not needed for the historical
education of users of K&R C compilers.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 288
Section: 02.9.2 [lex.ccon] para 1
X-Ref:
Description:
Second sentence. What is "the machine's character set"? Is this the
basic source character set that we have forgotten to define? Suggest that
the wording from C standard, Clause 6.1.3.4, Semantics, first paragraph
be used (it contains the important concept of mapping).
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 289
Section: 02.9.2 [lex.ccon] para 2
X-Ref:
Description:
Suggest that C standard, Clause 6.1.3.4, Semantics, second paragraph be
used as the basis of a rewrite of this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 290
Section: 02.9.2 [lex.ccon] para 3
X-Ref:
Description:
Suggest that C standard, Clause 6.1.3.4, Description, paragraph 2, 3,
4, and 5 be used as the basis of a rewrite of this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 291
Section: 02.9.2 [lex.ccon] para 4
X-Ref: 290
Description:
Delete para 4 if para 3 is re-written as suggested.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 292
Section: 02.9.3 [lex.fcon] para 1
X-Ref:
Description:
Suggest that this be replaced by C standard Clause 6.1.3.1, Description,
paragraph 1. Otherwise the term "missing" should be replaced by
"omitted".
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 293
Section: 02.9.4 [lex.string] para 1-3
X-Ref:
Description:
Suggest that paragraph 1, 2 and 3 be replaced by C standard, Clause
6.1.4, all paragraphs in Description and Semantics.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: Storage class of L"str"
Category: Clarification
Date: 21/7/94
Status: Open
Number: 24
Section: 02.9.4 [lex.string] para 2
X-Ref:
Description:
Change
has type "array of wchar_t."
to
has type "array of wchar_t" and has static storage duration.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 294
Section: 02.9.4 [lex.string] para 4
X-Ref:
Description:
Delete this paragraph. The size of a string is not equal to the number
of characters it contains. The \" rule is already covered by the text
from the C standard. The first paragraph belongs in an introductory
text to the language.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/7/95
Status: Open
Number: 295
Section: 02.9.5 [lex.bool] para 1
X-Ref:
Description:
Second sentence: "the given values". Where are these values given? They
should be given in this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 324
Section: 03 [basic] para 5
X-Ref:
Description:
Third sentence. Rules for deducing what constitutes the name being
"valid" need to be given.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 325
Section: 03 [basic] para 5
X-Ref:
Description:
Last sentence. Text needs to be added to specify more fully what is
meant when the potential scope is excluded from another scope.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 327
Section: 03 [basic] para 7
X-Ref:
Description:
Last sentence. Change:
... that determines this is called ...
to:
... that describes this determination is called ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 329
Section: 03 [basic] para 8
X-Ref:
Description:
In the second point, the number of parameters also needs to be considered,
unary or binary.
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 330
Section: 03 [basic] para 9
X-Ref:
Description:
Change this paragraph to:
An identifier used in more than one translation unit can
potentially refer to the same entity dependent upon the linkage
(basic.link) of the identifier in each translation unit.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 331
Section: 03.1 [basic.def] para 1
X-Ref:
Description:
Change this paragraph to:
A declaration introduces one or more names into a translation unit
and specifies the interpretation and attributes of these names.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 524
Section: 03.10 [basic.lval] para 11
X-Ref:
Description:
In the second sentence, change:
... this pointer type ...
to:
... the pointed to type ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 525
Section: 03.10 [basic.lval] para 12
X-Ref:
Description:
Array objects are made up of thier elements. If the elements can be
modified the array can be modified. Delete this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 526
Section: 03.10 [basic.lval] para 14
X-Ref:
Description:
First sentence. An expression may many objects and more than one of
them may be modified during the evaluation of the expression. State more
clearly how the "its object" is selected.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 519
Section: 03.10 [basic.lval] para 3
X-Ref:
Description:
Delete this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 520
Section: 03.10 [basic.lval] para 4
X-Ref:
Description:
Delete this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 521
Section: 03.10 [basic.lval] para 6
X-Ref:
Description:
Change:
... lvalue is not expected, ...
to:
... rvalue is expected, ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 522
Section: 03.10 [basic.lval] para 8
X-Ref:
Description:
In the second sentence., change:
Rvalues always have...
to:
Rvalues shall always have...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 523
Section: 03.10 [basic.lval] para 8
X-Ref:
Description:
In the second sentence, delete:
; lvalues may have incomplete type
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: ODR
Category: Clarification
Date: 9/1/95
Status: Open
Number: 123
Section: 03.2 (Box 6)
X-Ref:
Description:
The ODR needs more work.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 334
Section: 03.2 [basic.def.odr] para 1
X-Ref: 152, core issue 460
Description:
The standard does not define the concept of "variable". The concept of
"object" is defined.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: ODR
Category: Clarification
Date: 23/9/94
Status: Open
Number: 63
Section: 03.2 [basic.def.odr] para 2
X-Ref:
Description:
Change
only if an attempt is actually made to call that function
to
only if an attempt is actually made to use that function
[Want a diagnostic if the address is taken.]
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 335
Section: 03.2 [basic.def.odr] para 2
X-Ref:
Description:
Delete third sentence.
[This sub-clause is being re-written as a result of votes at the July
'95 meeting.]
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 336
Section: 03.2 [basic.def.odr] para 2
X-Ref:
Description:
Delete last sentence.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 337
Section: 03.2 [basic.def.odr] para 3
X-Ref:
Description:
The term "non-local variable" is not defined.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Clarification
Date: 21/7/94
Status: Open
Number: 27
Section: 03.2 [basic.def.odr] para 4
X-Ref:
Description:
Change
At least one definition of a class
to
Exactly one definition of a class
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 338
Section: 03.2 [basic.def.odr] para 6
X-Ref:
Description:
Change:
... the enumerators are the same.
to:
... the corresponding enumerators are identical.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 339
Section: 03.2 [basic.def.odr] para 7
X-Ref:
Description:
The term "same type" does not appear to be defined anywhere.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 340
Section: 03.2 [basic.def.odr] para 8
X-Ref:
Description:
The "ODR rule" is not defined anywhere. There is a clause entitiled
"One definition rule". Specify what the ODR rule is.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 341
Section: 03.3 [basic.scope] para 1
X-Ref:
Description:
Delete this paragraph.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Clarification
Date: 27/7/94
Status: Open
Number: 28
Section: 03.3.01 [basic.scope.local] para 1
X-Ref:
Description:
Change
Its scope begins at its point
to
Its potential scope begins at its point
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 342
Section: 03.3.01 [basic.scope.local] para 2
X-Ref: 343
Description:
If the type of one of the parameters declares a function prototype the
wording in the sentence requires that any names in the function prototype
be given block scope.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 343
Section: 03.3.01 [basic.scope.local] para 2
X-Ref: 342
Description:
Function parameter names have the property of being "local names".
This property needs to be described or function parameter names ascribed
alternative, defined properties.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 344
Section: 03.3.01 [basic.scope.local] para 4&5
X-Ref:
Description:
All this wording should be replaced by a simple rule that states that
local names may not be redeclared in the same scope.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 27/7/94
Status: Open
Number: 31
Section: 03.3.02 [basic.scope.proto] para 1
X-Ref:
Description:
Change
which terminates at the end of the function declarator.
to
which terminates at the end of the nearest enclosing function
declarator.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 345
Section: 03.3.04 [basic.scope.namespace] para 1
X-Ref:
Description:
last sentence. Change:
A namespace member can also be used after ...
to:
A namespace member can also be referred to after ...
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 15/9/95
Status: Open
Number: 575
Section: 03.3.07 [basic.scope.exqual] para 1
X-Ref:
Description:
This note is worthy of being made normative!!
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 347
Section: 03.3.08 [basic.scope.elab] para 1
X-Ref:
Description:
second sentence. Change:
... union (7.1.5) ...
to:
... union keywords (7.1.5) ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 348
Section: 03.3.09 [basic.scope.pdecl] para 1
X-Ref:
Description:
Change:
The point of declaration for a name is immediately ...
to:
The point of declaration for a name occurs immediately ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 349
Section: 03.3.09 [basic.scope.pdecl] para 1
X-Ref:
Description:
Change:
... and before its initializer (if any)
to:
... but before any initializer it may have
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 350
Section: 03.3.09 [basic.scope.pdecl] para 1
X-Ref:
Description:
Change:
... with its own (unspecified) value.
to:
... with its own (undefined) value.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 351
Section: 03.3.09 [basic.scope.pdecl] para 2
X-Ref:
Description:
The rule in this paragraph is a consequence of the rule in the previous
paragraph. Either delete this paragraph or turn it into a note.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 353
Section: 03.4 [basic.scope] para 1
X-Ref:
Description:
In the second sentence, delete the characters:
only; [basic.link] discusses linkages issues
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 354
Section: 03.4 [basic.scope] para 1
X-Ref:
Description:
Delete last sentence.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 357
Section: 03.4 [basic.scope] para 12
X-Ref:
Description:
Change:
... category above ...
to:
... paragraphs above ...
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Name lookup model
Category: Modelling
Date: 19/7/94
Status: Open
Number: 12
Section: 03.4 [class.scope]
X-Ref:
Description:
The elements of name lookup are described in various places within the
working paper. It is difficult to establish if these separate descriptions
are complete and/or consistent. Describing the name lookup algorithm(s)
by way of a single model would allow the completeness and consistency
to be established. This may also lead to simplification of the working
paper and help speed up the standardisation process.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 352
Section: 03.4 [class.scope] para 1
X-Ref:
Description:
first sentence. Delete the characters:
(including typedef names (7.1.3), namespace names (7.3) and
class names (9.3))
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 355
Section: 03.4 [class.scope] para 2
X-Ref:
Description:
In the second sentence, change:
... if it finds the name to be a function name
to:
... if it finds all such names to have function type
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 356
Section: 03.4 [class.scope] para 2
X-Ref:
Description:
Delete last sentence.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Linkage of unnamed objects
Category: Clarification
Date: 9/1/95
Status: Open
Number: 124
Section: 03.5 [basic.link]
X-Ref:
Description:
What is the linkage of unnamed classes and their members? Unnamed
enumerations and their enumerators?
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 358
Section: 03.5 [basic.link] para 2
X-Ref:
Description:
Using the plural form of "name" suggests that there might be different
names rather than more than one name of the same spelling. Reword.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 359
Section: 03.5 [basic.link] para 2
X-Ref:
Description:
second point. Change:
... scopes of the ...
to:
... scopes in the ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 360
Section: 03.5 [basic.link] para 3
X-Ref:
Description:
In the first sentence, change:
A name of namespace scope has...
to:
A name having namespace scope has...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 361
Section: 03.5 [basic.link] para 3
X-Ref:
Description:
In the first point, change:
a variable ...
to:
an object ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 362
Section: 03.5 [basic.link] para 4
X-Ref:
Description:
In the first sentence., change:
A name of namespace scope...
to:
A name having namespace scope...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 363
Section: 03.5 [basic.link] para 4
X-Ref:
Description:
In the first point, change:
a variable ...
to:
an object ...
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Non-normative sentence in 3.5.1
Category: Editorial
Date: 23/9/94
Status: Open
Number: 69
Section: 03.5.1 [basic.start.main] para 2
X-Ref:
Description:
"It is recommended that any further (optional) parameters be added
after argv."
This should really be a footnote.
[We should adopt the relevant wording from the ISO C standard]
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: main() needed in freestanding environment?
Category: Clarification
Date: 1/8/95
Status: Open
Number: 314
Section: 03.6.1 [basic.start.main] para 1
X-Ref: 162
Description:
C++ should require a main function, even in a freestanding environment.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 27/7/94
Status: Open
Number: 38
Section: 03.6.1 [basic.start.main] para 4
X-Ref:
Description:
"value is returned to the program's environment".
This cannot be a requirement of C++.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Missing definition
Date: 1/8/95
Status: Open
Number: 364
Section: 03.6.2 [basic.start.init] para 1
X-Ref:
Description:
In the first sentence, define what constitutes a "use" of a function
or object.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 365
Section: 03.6.2 [basic.start.init] para 1
X-Ref:
Description:
Delete second sentence.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Clarification
Date: 27/7/94
Status: Open
Number: 39
Section: 03.6.3 [basic.start.term] para 1
X-Ref:
Description:
Change:
If atexit() is to be called the implementation shall not destroy
objects...
to:
If atexit() is to be called the implementation shall not destroy
file scope objects...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 367
Section: 03.6.3 [basic.start.term] para 1
X-Ref:
Description:
Delete third sentence.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 368
Section: 03.6.3 [basic.start.term] para 1
X-Ref: 367
Description:
fourth sentence. Change:
If atexit() is to be called ...
to:
If atexit() <cstdlib> is called ...
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 27/7/94
Status: Open
Number: 41
Section: 03.6.3 [basic.start.term] para 3
X-Ref:
Description:
Change
terminates the program without executing
to
terminates the program without leaving the current block and
without executing
[This change makes it clear that destructors for local objects aren't
executed either. Perhaps we should just say that?
Josee has a proposal in N0725 to do the opposite - guarantee that
destructors for local objects *are* called.]
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 369
Section: 03.7 [basic.stc] para 1
X-Ref: 370
Description:
Change the first sentence:
Storage duration...might last.
to:
Storage duration is the property of an object which defines
the minimum
potential lifetime of the storage containg the object.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 27/7/94
Status: Open
Number: 47
Section: 03.7 [basic.types] para 2
X-Ref:
Description:
Why introduce unnecessary synonyms?
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Reference
Date: 1/8/95
Status: Open
Number: 373
Section: 03.7.1 [basic.stc.static] para 3
X-Ref:
Description:
Change:
... static storage duration; ... see stmt.dcl.
to:
... static storage duration (stmt.dcl).
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Reference
Date: 1/8/95
Status: Open
Number: 371
Section: 03.7.1 [basic.stc.static] para 1
X-Ref:
Description:
In the second sentence, change:
... program.
to:
... program (basic.start.init, basic.start.term).
Also, delete the third sentence.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 27/7/94
Status: Open
Number: 44
Section: 03.7.2 [basic.stc.auto] para 1
X-Ref:
Description:
Change
Local objects explicitly declared auto or register or not
explicitly declared static
to
Local objects explicitly declared auto or register or not
explicitly declared static or extern
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 375
Section: 03.7.2 [basic.stc.auto] para 2
X-Ref:
Description:
Delete this paragraph.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 27/7/94
Status: Open
Number: 54
Section: 03.7.3 table 10
X-Ref:
Description:
This partial ordering doesn't seem to be used.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 376
Section: 03.7.3.1 [basic.stc.dynamic.allocation] para 2
X-Ref:
Description:
In the sixth sentence, change:
... the value returned shall be nonzero and ...
to:
... the value returned shall be non NULL and ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 381
Section: 03.7.3.2 [basic.stc.dynamic.allocation] para 3
X-Ref:
Description:
In the second sentence, change:
... is zero ...
to:
... is the null pointer ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 380
Section: 03.7.3.2 [basic.stc.dynamic.allocation] para 3
X-Ref:
Description:
In the first sentence, change:
... shall be zero ...
to:
... shall be the null pointer ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 382
Section: 03.7.3.2 [basic.stc.dynamic.allocation] para 4
X-Ref:
Description:
What is an "unusable value"? What is the runtime behaviour of accessing
such an "unusable value"? Suggest that status of pointer become
indeterminate, see paragraph 5.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 384
Section: 03.7.3.2 [basic.stc.dynamic.allocation] para 5
X-Ref:
Description:
Delete footnote 20.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 379
Section: 03.7.3.2 [basic.stc.dynamic.deallocation] para 2
X-Ref:
Description:
Change:
... type size_t ...
to:
... type size_t, an implementation-defined integral type defined
in the standard header <cstddef> ...
Yes, this is repeating Clause 3.7.3.1, paragraph 1. The alternative to
to add wording to the effect that whenever size_t is mentioned the one
from <cstddef> is intended.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 387
Section: 03.8 [basic.life] para 6
X-Ref:
Description:
In the first sentence, change:
...while the storage which the object occupied still exists...
to:
...until the storage which the object occupied is reused or
released...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 388
Section: 03.8 [basic.life] para 6
X-Ref:
Description:
In the second sentence, the term "valid storage" is not defined.
A definition needs to be supplied.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 389
Section: 03.8 [basic.life] para 7
X-Ref:
Description:
This paragraph has been written in very broad terms to handle a very
special case. It implies that a function can return, another function
called and, provided the objects in the new function occupy the same
locations, it is ok to read values from them and get the values stored
into the previous objects.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 391
Section: 03.9 [basic.types] para 1
X-Ref:
Description:
This paragraph should be a note.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 392
Section: 03.9 [basic.types] para 2
X-Ref:
Description:
In the first sentence, change:
... underlying bytes (intro.memory) of the object...
to:
... underlying bytes (intro.memory) making up the object ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 394
Section: 03.9 [basic.types] para 2
X-Ref:
Description:
In the third sentence, delete "Whether or not the value of the object
is later changed,"
----------------------------------------------------------------------
Owner: Andy Sawyer
Summary: Copying objects via char/unsigned char
Category: Language change
Date: 18/9/95
Status: Open
Number: 611
Section: 03.9 [basic.types] para 2
X-Ref:
Description:
Why is memcpy a special case? Re-word to allow copying via any mechanism.
Note that the current wording will give one of the few instances where
memcpy is more 'reliable' than memmove. For example:
class Foo { unsigned char a, b; };
struct X {
unsigned char padding;
unsignec char buffer[sizeof(Foo)*2];
};
union Bar {
X x;
Foo foo;
};
...
Bar b;
memcpy( b.x.buffer, &b.foo, sizeof( Foo ) );
...
memcpy( &b.x.foo, b.x.buffer, sizeof( Foo ) );
Note that this example can be constructed regardless of the direction
in which memcpy goes about its buisness.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Clarification
Date: 1/8/95
Status: Open
Number: 397
Section: 03.9 [basic.types] para 5
X-Ref:
Description:
In the second sentence, change:
... that is divisible ...
to
... that is exactly divisible ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 398
Section: 03.9 [basic.types] para 6
X-Ref:
Description:
In the second sentence, change:
... type; it represents an empty set of values.
to:
... type that cannot be completed.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 400
Section: 03.9 [basic.types] para 6
X-Ref:
Description:
Last sentence. In ISO 9899 an incomplete type is not an object type
(Clause 6.1.2.5, first paragraph). Defining an "incompletely-defined
object type" is a needless incompatibility with ISO 9899. Use another
term.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: C incompatability
Date: 1/8/95
Status: Open
Number: 401
Section: 03.9 [basic.types] para 7
X-Ref:
Description:
Last sentence. ISO 9899 allows a typedef declaration of an array of
unknown size to be later completed for a specific object (Clause 6.5.7,
example 6). C++ should also allow such a usage. Disallowing this
construct is a needless incompatibility.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 402
Section: 03.9 [basic.types] para 8
X-Ref:
Description:
Paragraph 6 describes the contexts rather well. This Note is not needed.
Delete.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 403
Section: 03.9 [basic.types] para 9
X-Ref:
Description:
In the first sentence, change:
... are scalar ...
to:
... are collectively called scalar ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 404
Section: 03.9 [basic.types] para 9
X-Ref:
Description:
In the last sentence, change:
... are POD ...
to:
... are collectively called POD ...
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 27/7/94
Status: Open
Number: 48
Section: 03.9.1 [basic.fundamental] para 1
X-Ref: Core issue 522
Description:
Not all fundamental types! void, bool, enum are not included.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 405
Section: 03.9.1 [basic.fundamental] para 1
X-Ref:
Description:
In the second sentence, change:
... largest and smallest ...
to:
... maximum and minimum ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 415
Section: 03.9.1 [basic.fundamental] para 11
X-Ref:
Description:
Delete sentences 1, 2 & 3. The shall not is already covered in Clause
3.9 paragraph 6.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 406
Section: 03.9.1 [basic.fundamental] para 2
X-Ref:
Description:
First sentence. The term "basic character set" is not defined.
The "basic execution character set" is probably intended.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 407
Section: 03.9.1 [basic.fundamental] para 2
X-Ref:
Description:
Second sentence. What is the definition of the "integer code" of
a character? Suggest that this senetnce be deleted.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 409
Section: 03.9.1 [basic.fundamental] para 4
X-Ref:
Description:
In the second sentence, delete the characters "but the implementation
can otherwise make any of them equal in storage size"
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 410
Section: 03.9.1 [basic.fundamental] para 5
X-Ref:
Description:
Replace footnote 24 with "(dcl.type.simple)"
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 411
Section: 03.9.1 [basic.fundamental] para 5
X-Ref:
Description:
Last sentence. "same value for each type" is this the same
signed/unsigned type or all types? It needs to be specified more fully.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 412
Section: 03.9.1 [basic.fundamental] para 8
X-Ref:
Description:
Replace first sentence with:
"Objects of type bool can have the values true or false."
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 413
Section: 03.9.1 [basic.fundamental] para 8
X-Ref:
Description:
Delete second sentence:
There are no signed, unsigned, short, or long bool types or
values.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 414
Section: 03.9.1 [basic.fundamental] para 8
X-Ref:
Description:
In the last sentence, change:
... bit-field of any (nonzero) size.
to:
... bit-field object of any size.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 416
Section: 03.9.2 [basic.compound] para 1&2
X-Ref:
Description:
Given that they contain little information and no subsequent use is made
of them, these two paragraphs should be deleted.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/8/95
Status: Open
Number: 511
Section: 03.9.2 [basic.compound] para 3
X-Ref:
Description:
Delete the example.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/8/95
Status: Open
Number: 512
Section: 03.9.2 [basic.compound] para 5
X-Ref:
Description:
Delete this paragraph. Duplicate wording exists in paragraph 3, sentence
3 of this sub-clause.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 514
Section: 03.9.3 [basic.type.qualifier] para 1
X-Ref:
Description:
Delete first sentence.
----------------------------------------------------------------------
Owner: Jonathan de Boyne Pollard
Summary: Text about "object type"
Category:
Date: 18/9/95
Status: Open
Number: 592
Section: 03.9.3 [basic.type.qualifier] para 1
X-Ref:
Description:
Since object type is (or should be) defined as the static type with
which an object is created, this text is extraneous, as static type
already encompasses CV qualfiers.
Suggest deleting the third sentence:
The term `object type' (1.6) includes the cv-qualifiers specified
when the object is created.
If desired, this may remain as a footnote to the definition of object
type in [intro.object]
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 515
Section: 03.9.3 [basic.type.qualifier] para 2
X-Ref:
Description:
Delete first sentence.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/8/95
Status: Open
Number: 516
Section: 03.9.3 [basic.type.qualifier] para 2
X-Ref:
Description:
In the second sentence, change:
However, any cv-qualifiers that appears...
to:
Any cv-qualifiers that appear ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 517
Section: 03.9.3 [basic.type.qualifier] para 5
X-Ref:
Description:
The second sentence, duplicates statements made in paragraph 2, second
sentence. Delete this sentence or the second sentence of paragraph 2.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/8/95
Status: Open
Number: 518
Section: 03.9.4 [basic.type.name]
X-Ref:
Description:
Delete this sub-clause.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 528
Section: 04 [conv] para 1-4
X-Ref:
Description:
Replace these paragraphs by:
Expressions with a given type may be implicitly converted to
other types. One or more of the following standard conversions
will be applied to an expression if required by the destination.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 531
Section: 04.1 [conv.lval] para 1
X-Ref:
Description:
In the fourth sentence, delete:
(i.e., T is a class type)
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 532
Section: 04.1 [conv.lval] para 1
X-Ref:
Description:
In the last sentence, move footnote to C compatibility Annex.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/8/95
Status: Open
Number: 533
Section: 04.1 [conv.lval] para 2
X-Ref:
Description:
In the second sentence, change:
... conversion is done ...
to:
... conversion occurs ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/8/95
Status: Open
Number: 545
Section: 04.10 [conv.ptr] para 1
X-Ref:
Description:
Replace the last sentence by:
Two null pointer values of the same type shall compare equal.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 547
Section: 04.11 [conv.mem] para 1
X-Ref:
Description:
Replace the third sentence with:
Two null member pointer values of the same type shall compare
equal.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 27/7/94
Status: Open
Number: 59
Section: 04.13 [conv.bool]
X-Ref:
Description:
Not clear that the following conversion is disallowed:
int i;
char *cp;
cp = i; // convert char* -> bool -> int
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 27/7/94
Status: Open
Number: 55
Section: 04.3 [conv.double] para 1
X-Ref:
Description:
Where is the term "single precision" defined?
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 537
Section: 04.5 [conv.prom] para 3
X-Ref:
Description:
Make footnote 34 normative by moving to main body of text.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 538
Section: 04.7 [conv.integral] para 1
X-Ref:
Description:
This summary of Clause 4.5 is pointless and should be deleted.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/8/95
Status: Open
Number: 539
Section: 04.7 [conv.integral] para 3
X-Ref:
Description:
Change "bitfield" to "bit-field"
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 540
Section: 04.7 [conv.integral] para 4
X-Ref:
Description:
The second sentence, duplicates Clause 4.5, paragraph 4. Delete this
sentence.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 541
Section: 04.8 [conv.double] para 1
X-Ref:
Description:
Delete the first sentence.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Undefined terms
Category: Terminology
Date: 24/9/94
Status: Open
Number: 76
Section: 04.9 [conv.fpint] para 1
X-Ref:
Description:
Where is the term "fractional" defined?
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 542
Section: 04.9 [conv.fpint] para 2
X-Ref:
Description:
In the second sentence, how possible does "possible" need to be before it
is required to be implemented? The standard should require implementors
to define the model used for floating point representation. "Possible"
then needs to be defined in terms of what that model can represent.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: C incompatability
Date: 3/8/95
Status: Open
Number: 543
Section: 04.9 [conv.fpint] para 2
X-Ref:
Description:
Replace the third sentence by:
Otherwise, it is an implementation-defined choice of either
the nearest lower or higher representable value.
Status will then also agree with ISO 9899.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 3/8/95
Status: Open
Number: 544
Section: 04.9 [conv.fpint] para 2
X-Ref:
Description:
Delete the fourth sentence.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 427
Section: 05 [expr] para 12
X-Ref:
Description:
This is a very close copy of the rules in Clause 6.2.1.5 of ISO 9899.
It should be an exact copy.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 428
Section: 05 [expr] para 13
X-Ref:
Description:
Replace the last point by "a character type." to cover the signed char
case and make wording identical to Clause 6.3 of ISO 9899.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 429
Section: 05 [expr] para 13
X-Ref:
Description:
Last point. Move reference to footnote 38 to first sentence.
This footnote is not character specific.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 417
Section: 05 [expr] para 3
X-Ref:
Description:
In the first sentence, change:
This clause defines the operators ...
to:
This clause defines the effects of operators ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 418
Section: 05 [expr] para 3
X-Ref:
Description:
In the second sentence, change:
... defined by the language itself.
to:
... defined by this standard.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 419
Section: 05 [expr] para 4
X-Ref:
Description:
The fourth sentence conflicts with the contents of the third sentence
and should be deleted.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 420
Section: 05 [expr] para 4
X-Ref:
Description:
Delete the last sentence.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 421
Section: 05 [expr] para 4
X-Ref:
Description:
In the example, change "undefined" to "unspecified".
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 422
Section: 05 [expr] para 5
X-Ref:
Description:
Delete the note.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 423
Section: 05 [expr] para 7
X-Ref:
Description:
Delete the last sentence.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 424
Section: 05 [expr] para 9
X-Ref:
Description:
This paragraph adds no new requirements to the standard and would fit
better as a Note.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 425
Section: 05 [expr] para 9
X-Ref:
Description:
In the first sentence the meaning of the phrase "... and so on" needs
to be clarified.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 430
Section: 05.1 [expr.prim] para 4
X-Ref:
Description:
Most occurrences of "name" need to be replaced by "qualified-id".
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 431
Section: 05.1 [expr.prim] para 4
X-Ref:
Description:
In the fifth sentence, change:
... shall be of global namespace scope.
to:
... shall have global namespace scope.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 432
Section: 05.1 [expr.prim] para 4
X-Ref:
Description:
Delete the note.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 434
Section: 05.1 [expr.prim] para 6
X-Ref:
Description:
The syntax for id-expression also appears in Clause 7.3.1.1.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Editorial
Date: 24/9/94
Status: Open
Number: 87
Section: 05.1 [expr.prim] para 8
X-Ref:
Description:
para 8 talks about nested-name-specifier and classes -- should be
updated to refer to namespaces.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 435
Section: 05.1 [expr.prim] para 8,9
X-Ref:
Description:
The text discusses nested-name-specifier being followed by a ::.
The syntax does not allow such a construct. The syntax and associated
text need to be made consistent.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 18/9/95
Status: Open
Number: 607
Section: 05.18 [expr.comma]
X-Ref:
Description:
The syntax given for is identical to that given in Clause 5.2 for
expression-list. Rules need to be given to disambiguate the two cases.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 437
Section: 05.2 [expr.post] para 1
X-Ref:
Description:
The syntax for expression-list is also defined in Clause 5.18. One of
these sytax rules should be deleted.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Clarification
Date: 24/9/94
Status: Open
Number: 89
Section: 05.2.1 [expr.sub]
X-Ref:
Description:
"One of the expressions ... and the other must be of enumeration or
integral type."
Since enumeration types convert to integral types isn't this
overspecified? In fact, shouldn't it be "convertible to an integral
type" to allow the following:
struct X { operator int(); };
X x;
char buf[];
buf[x];
(the same applies to "must have the type 'pointer to T'" -- this should be
"convertible to a pointer to object type")
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 438
Section: 05.2.1 [expr.sub] para 1
X-Ref:
Description:
Delete the first note in this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 439
Section: 05.2.1 [expr.sub] para 1
X-Ref:
Description:
In the second sentence, change:
... be of enumeration of integral type.
to:
... have enumeration of integral type.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 467
Section: 05.2.10 [expr.const.cast] para 4
X-Ref:
Description:
In the first sentence, change:
... define casting away constness.
to:
... define the process known as casting away constness.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 468
Section: 05.2.10 [expr.const.cast] para 4
X-Ref:
Description:
In the third sentence, delete the characters:
(e.g., int)
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 469
Section: 05.2.10 [expr.const.cast] para 7
X-Ref:
Description:
The last two sentences should be made Normative.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 440
Section: 05.2.2 [expr.call] para 1
X-Ref:
Description:
In the third sentence, change:
For ordinary function call...
to:
For an ordinary function call...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 441
Section: 05.2.2 [expr.call] para 1
X-Ref:
Description:
In the fourth sentence, change:
For member function call...
to:
For a member function call...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 450
Section: 05.2.2 [expr.call] para 11
X-Ref:
Description:
Delete this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 442
Section: 05.2.2 [expr.call] para 3
X-Ref:
Description:
In the second sentence, some form of ordering should be specified.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 443
Section: 05.2.2 [expr.call] para 5
X-Ref:
Description:
Delete this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 445
Section: 05.2.2 [expr.call] para 7
X-Ref:
Description:
In the first sentence, change:
... for which there is no parameter...
to:
for which ellipsis notation is used...
Use of the term "no parameter" suggests that more arguments than
parameters may be passed. The term should be replaced by "for which
ellipsis notation is used".
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 446
Section: 05.2.2 [expr.call] para 7
X-Ref:
Description:
In the first sentence, promotions also need to be specified for unsigned
char, signed char and unsigned short.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 447
Section: 05.2.2 [expr.call] para 8
X-Ref:
Description:
This Note needs to be made Normative.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 449
Section: 05.2.2 [expr.call] para 9
X-Ref:
Description:
In the second sentence, change:
... expressions take effect before...
to:
... expression evaluations take effect before...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 451
Section: 05.2.3 [expr.type.conv] para 1
X-Ref:
Description:
In the second sentence, delete:
...(in definedness, and if defined in meaning)
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 452
Section: 05.2.4 [expr.ref] para 2
X-Ref:
Description:
In the third sentence, the term "imputed destructor" needs to be defined.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 453
Section: 05.2.4 [expr.ref] para 3
X-Ref: 454
Description:
In the fourth sentence, is a "single type" one type once, the same type
many times, or a fundamental type?
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 454
Section: 05.2.4 [expr.ref] para 4
X-Ref: 453
Description:
See previous query regarding "same type".
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 455
Section: 05.2.6 [expr.dynamic.cast] para 7
X-Ref:
Description:
In the first sentence, change
... the result is a ...
to
... the result shall be a ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 456
Section: 05.2.6 [expr.dynamic.cast] para 8
X-Ref:
Description:
In the first sentence, change:
The run-time check logically executes like this:
to:
The run-time check performs the following tests:
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 457
Section: 05.2.7 [expr.typeid] para 3
X-Ref:
Description:
In the first sentence, the term "valid object" needs to be defined.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 458
Section: 05.2.7 [expr.typeid] para 3
X-Ref:
Description:
Replace the term "zero" by "null" when refering to pointer values.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 459
Section: 05.2.7 [expr.typeid] para 4
X-Ref:
Description:
In the first sentence, change:
...a pointer, say p, that points to...
to:
...a pointer, p, that points to...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 460
Section: 05.2.8 [expr.static.cast] para 2
X-Ref:
Description:
In the second sentence, change:
... , for some invented temporary variable t, ...
to:
... , object t, ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 461
Section: 05.2.8 [expr.static.cast] para 3
X-Ref:
Description:
In the last sentence, change:
... no other conversion can be performed...
to:
... no other conversion shall be performed...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 462
Section: 05.2.8 [expr.static.cast] para 5
X-Ref:
Description:
Delete the fourth sentence:
This interpretation...given above.
Add a paragraph at the start of the sub-clause specifying that there
are two cases that need to be considered.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 464
Section: 05.2.9 [expr.reinterpret.cast] para 10
X-Ref:
Description:
In the last sentence, change:
... is unspecified, except in ...
to:
... is undefined, except in ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 465
Section: 05.2.9 [expr.reinterpret.cast] para 11
X-Ref:
Description:
No rules are given for when function types "differ". Replace the term
"differ" by "is not the same" or "is incompatable".
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 463
Section: 05.2.9 [expr.reinterpret.cast] para 8
X-Ref:
Description:
In the last sentence, change:
... unspecified;
to:
... undefined.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 470
Section: 05.3.1 [expr.unary.op] para 1
X-Ref:
Description:
Replace the first sentence by:
The unary * operator performs indirection; the expression to
which it is applied shall have a pointer type, and the result
is an lvalue refering to the object or function to which the
expression points.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 471
Section: 05.3.1 [expr.unary.op] para 2
X-Ref:
Description:
Delete the first example.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Diagnostics
Date: 24/9/94
Status: Open
Number: 93
Section: 05.3.1 [expr.unary.op] para 3
X-Ref:
Description:
Change
behaviour is undefined (and no diagnostic is required).
to
behaviour is undefined.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 472
Section: 05.3.1 [expr.unary.op] para 3
X-Ref:
Description:
Delete the characters "(operator &())"
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 475
Section: 05.3.1 [expr.unary.op] para 5
X-Ref:
Description:
Change the first sentence to read:
The operand of the unary + operator shall have scalar type.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 476
Section: 05.3.1 [expr.unary.op] para 5
X-Ref:
Description:
In the last sentence, the type of the result needs to be specified for
non-integral, non-enumeration operands.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 478
Section: 05.3.1 [expr.unary.op] para 6
X-Ref:
Description:
An ordering needs to be given for when promotion and operator application
occur. This ordering requirement should be stated globally for all
expression operands.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 479
Section: 05.3.2 [expr.pre.incr] para 1
X-Ref:
Description:
Delete the characters "or set to true if it is bool (this use is
deprecated)"
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 480
Section: 05.3.2 [expr.pre.incr] para 1
X-Ref:
Description:
Delete the fourth sentence.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 481
Section: 05.3.2 [expr.pre.incr] para 2
X-Ref:
Description:
Delete the characters "except that the operand shall not be of type bool"
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 482
Section: 05.3.2 [expr.pre.incr] para 2
X-Ref:
Description:
Rules need to be given for lvalue status and the type of the return value.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 483
Section: 05.3.3 [expr.sizeof] para 1
X-Ref:
Description:
The note in this paragraph is Normative. It is also specified too
narrowly. See ISO 9899 Clause 6.3.3.4, second paragraph of semantics
for correct text.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 484
Section: 05.3.3 [expr.sizeof] para 1
X-Ref:
Description:
Delete footnote 45.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 485
Section: 05.3.3 [expr.sizeof] para 1
X-Ref:
Description:
Delete the second sentence of the note.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 486
Section: 05.3.3 [expr.sizeof] para 2
X-Ref:
Description:
In the second sentence, change:
... such objects ...
to:
... objects of that type ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 487
Section: 05.3.3 [expr.sizeof] para 4
X-Ref:
Description:
Change:
... suppressed on ...
to:
... are not applied to ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 488
Section: 05.3.3 [expr.sizeof] para 6
X-Ref:
Description:
Replace this paragraph with:
The result is a constant with type size_t, as defined in the
standard header <cstddef>
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 496
Section: 05.3.4 [expr.new para 7
X-Ref:
Description:
In the second sentence, change:
... with a ...
to:
... and evaluate to a ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 490
Section: 05.3.4 [expr.new] para 1
X-Ref:
Description:
In the second sentence, the term "nonabstract object type" needs to
be defined.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 500
Section: 05.3.4 [expr.new] para 10
X-Ref:
Description:
In the first sentence, change:
... definitions of the ...
to:
... definitions for the ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 501
Section: 05.3.4 [expr.new] para 10
X-Ref:
Description:
In the first sentence, change both occurrences of "arrays" to "array
types".
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 503
Section: 05.3.4 [expr.new] para 11
X-Ref:
Description:
In the second sentence, change:
... overloading resolution is done by assembling an argument
list from ...
to:
... overload resolution is performed on a function call created
by assembling an argument list consisting of ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Clarification
Date: 1/8/95
Status: Open
Number: 504
Section: 05.3.4 [expr.new] para 11
X-Ref:
Description:
In the second sentence, types need to be specified for the arguments.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 505
Section: 05.3.4 [expr.new] para 12
X-Ref:
Description:
In the last point, insert a new-line before "Here, a and y"
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 506
Section: 05.3.4 [expr.new] para 12
X-Ref:
Description:
Replace the last sentence of the last bullet by:
Their value may vary from one invocation of new to another.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 507
Section: 05.3.4 [expr.new] para 13
X-Ref:
Description:
In the first sentence, change:
... in which the object shall be created.
to:
... in which space for the object shall have been reserved.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 491
Section: 05.3.4 [expr.new] para 2
X-Ref:
Description:
In the first sentence, change:
The new-type in a...
to:
The new-type-id in a...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 492
Section: 05.3.4 [expr.new] para 2
X-Ref:
Description:
The second sentence should be given Note status.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 493
Section: 05.3.4 [expr.new] para 3
X-Ref:
Description:
This requirement is very poorly worded. The following example all contain
parentheses, but some are regarded as being well formed. Reword the
requirement more precisely.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 494
Section: 05.3.4 [expr.new] para 6
X-Ref:
Description:
In the note, change:
... return an int*...
to:
... have return type int*...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 495
Section: 05.3.4 [expr.new] para 7
X-Ref:
Description:
In the second sentence, change:
... be of integral type...
to:
... have integral type...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Open
Number: 498
Section: 05.3.4 [expr.new] para 9
X-Ref:
Description:
In the second sentence, change:
... will be ...
to:
... shall be ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Open
Number: 502
Section: 05.3.4 [expr.type] para 11
X-Ref:
Description:
In the first sentence, change:
The new-placement syntax can be used ...
to:
The new-placement syntax is used ...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 18/9/95
Status: Open
Number: 600
Section: 05.3.5 [expr.delete] para 2
X-Ref:
Description:
In the first sentence, change:
...operand of delete...
to:
...operand to delete...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 18/9/95
Status: Open
Number: 601
Section: 05.3.5 [expr.delete] para 2
X-Ref:
Description:
In the second sentence, change:
...operand of delete...
to:
...operand to delete...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 18/9/95
Status: Open
Number: 602
Section: 05.3.5 [expr.delete] para 2
X-Ref:
Description:
There is a symbolc reference, "(_class.conv,fct_)", in the second
sentence. This should be a numeric reference.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 18/9/95
Status: Open
Number: 603
Section: 05.3.5 [expr.delete] para 2
X-Ref:
Description:
Delete the third sentence. The previous sentence contains a "shall".
Violating a "shall" already has a status, so this sentence serves
no purpose.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 18/9/95
Status: Open
Number: 604
Section: 05.3.5 [expr.delete] para 2
X-Ref:
Description:
Delete the fifth sentence. The previous sentence contains a "shall".
Violating a "shall" already has a status, so this sentence serves
no purpose.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 18/9/95
Status: Open
Number: 605
Section: 05.3.5 [expr.delete] para 2
X-Ref:
Description:
Change:
...operand of delete...
to:
...operand to delete...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 18/9/95
Status: Open
Number: 606
Section: 05.3.5 [expr.delete] para 3
X-Ref:
Description:
In footnote 46, change:
...cannot be deleted using a point of...
to:
...cannot be deleted using a pointer of...
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Language change
Date: 24/9/94
Status: Open
Number: 99
Section: 05.5 [expr.mptr.oper]
X-Ref:
Description:
Incomplete semantics -- there is no way to navigate to nested class
members (and no syntax to declare such a pointer to member?)
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Pointer comparisons
Category:
Date: 1/8/95
Status: Open
Number: 316
Section: 05.9 [expr.rel] para 3
X-Ref: 174
Description:
The behaviour of non-meaningful pointer comparisons should be undefined,
as in ISO C, rather than implementation defined.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Clarification
Date: 24/9/94
Status: Open
Number: 109
Section: 06.7 [stmt.dcl] para 5
X-Ref: Core issue 484
Description:
"... before or as part of the calls of the atexit() functions."
What if there are no such calls? Related issue: what if the called
atexit functions contain local static objects? Consider the following
example:
void f() {
static T t(1);
}
void g() {
static T u(2);
}
main() {
atexit(f);
atexit(g);
f(); // ensures 't' is constructed, 'u' is not yet
exit(0); // now what? calls 'g' and then 'f'
// two questions arise:
// 1) is 'u' destroyed? (it wasn't constructed
prior
// to the atexit function calls)
// 2) has 't' been destroyed prior to calling 'f'
// again?
}
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Rationale
Date: 24/9/94
Status: Open
Number: 104
Section: 07.1.3 [dcl.typedef] para 2
X-Ref:
Description:
Why is (benign) redefinition of a typedef allowed, when the equivalent
for a variable is not. Delete this paragraph.
----------------------------------------------------------------------
Owner: Derek Jones
Summary: Duplicate syntax definitions
Category:
Date: 18/9/95
Status: Open
Number: 609
Section: 07.1.5.3 [dcl.type.elab]
X-Ref:
Description:
The syntax rule for elaborated-type-specifier is also given in 14.2. The
syntax rule for class-key is also given in 9. Delete the duplicate
definitions here.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Clarification
Date: 24/9/94
Status: Open
Number: 106
Section: 07.3.1 [dcl.typedef] para 8
X-Ref:
Description:
It seems inconsistent to deprecate namespace scope static when file
scope const implies static -- this needs to be made clearer.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category:
Date: 3/11/94
Status: Open
Number: 114
Section: 07.3.2 [namespace.alias] para 3
X-Ref:
Description:
Change
in that declarative region to refer to the namespace to which
it already refers.
to
in that declarative region to refer only to the namespace to
which it already refers.
[The old wording only says what is possible, and not what isn't possible.]
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Clarification
Date: 24/9/94
Status: Open
Number: 103
Section: 07.5 [dcl.link]
X-Ref:
Description:
Interaction of linkage and namespace needs clarification (esp. para 5
"Functions and objects may be declared static ..." which is deprecated).
----------------------------------------------------------------------
Owner: Derek Jones
Summary: Duplicate syntax definitions
Category:
Date: 18/9/95
Status: Open
Number: 608
Section: 7.5 [dcl.link]
X-Ref:
Description:
Declaration-seq is also defined at the top of Clause 7. Delete the
duplicate definition here.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Clarification
Date: 24/9/94
Status: Open
Number: 102
Section: 07.5 [dcl.link] para 2
X-Ref: Core issue 486
Description:
"Linkage specifications nest." -- what does the following mean?
extern "C" {
extern "C++" {
double func(); // what linkage does 'func' have?
}
}
We agree with the proposed resolution of core issue 486, that in the
example above function "func()" would have "C++" linkage.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Zero sized base class sub-objects
Category: Clarification
Date: 1/8/95
Status: Open
Number: 317
Section: 09 [class] para 3
X-Ref: 179
Description:
Base class sub-objects should be allowed to occupy zero bytes of the
complete object.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary:
Category: Editorial
Date: 11/9/95
Status: Open
Number: 558
Section: 09 [class] para 4
X-Ref:
Description:
Add this sentence to the end of this paragraph:
The term POD is used as an abbreviation for "POD-struct or
POD-union"
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary:
Category: Editorial
Date: 9/1/95
Status: Open
Number: 127
Section: 09.2 para 23
X-Ref:
Description:
Change:
A static data member, enumerator, member of an anonymous union,
or nested type may not have...
to:
No other member shall have...
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Allow reference members in unions
Category: Clarification
Date: 1/8/95
Status: Open
Number: 318
Section: 09.6 [class.union] para 1
X-Ref: 181
Description:
Unions should be allowed to contain reference members.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary:
Category: Non-normative text
Date: 1/12/94
Status: Open
Number: 118
Section: 09.7 [class.bit] para 1&2
X-Ref:
Description:
The following sentences are non-normative, and should be moved to
footnotes:
Fields straddle allocation boundaries on some machines and not
on others.
Fields are assigned right-to-left on some machines, left-to-right
on others.
An unnamed bit-field is useful for padding to conform to
externally imposed layouts.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Hiding rules
Category: Language change
Date: 30/1/95
Status: Open
Number: 138
Section: 10.2 [class.member.lookup] para 2
X-Ref:
Description:
The current wording in the hiding rules is unclear. It is easy to come
up with examples where the outcome is unexpected or undesirable! eg.when
an virtual base class is a direct base class and a name in it is hidden
by an alternate, longer path:
V::x
/ \
B::x |
\ /
D
B::x hides V::x and accesses to x in D are unambiguous (to B::x).
The interaction of overriding and hiding is also unclear.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: global/file scope instead of namespace scope
Category: Editorial
Date: 30/1/95
Status: Open
Number: 136
Section: 10.5 [class.scope] para 5,6,7
X-Ref:
Description:
s/file scope/namespace scope/
s/globally/at namespace scope/
etc.
This almost certainly needs to be done to the whole document!
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary:
Category: Editorial
Date: 30/1/95
Status: Open
Number: 140
Section: 11.2 [class.access.base] para 4
X-Ref:
Description:
The WP says:
A base class is said to be accessible if an invented public
member of the base class is accessible
What is an "invented" public member. I know what this is trying to say,
but it doesn't say it very well!!
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: friends and linkage
Category: Clarification
Date: 30/1/95
Status: Open
Number: 142
Section: 11.4 [class.friend]
X-Ref:
Description:
If a class has external linkage, must its friends also have external
linkage? e.g. is this well-formed:
//x.h
class X {
friend void f();
int x;
};
// a.c // b.c
static void f(); static void f();
#include "x.h" #include "x.h"
void f() { void f() {
x = 0; x = 1;
} }
[I think this is currently allowed. Once the new ODR is incorporated this
case needs to be checked. BSI consensus is that it should not be allowed.]
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 15/9/95
Status: Open
Number: 577
Section: 12 [special] para 1
X-Ref:
Description:
A clause shouldn't start with a non-normative para. Add an intro para
listing/defining which member functions are classed as 'special'.
----------------------------------------------------------------------
Owner: Andy Sawyer
Summary: Lifetime of temporaries rules inconsistent
Category:
Date: 12/6/95
Status: Open
Number: 182
Section: 12.2 [class.temporary] para 6
X-Ref: Core issue 509
Description:
This paragraph is inconsistent with the other rules. For example:
class X {
public:
X( const char *p );
X( const X& x );
// Note: No Default Constructor!
};
X func( X ){ /* .. */ }
X& ref = func( X( "Call-Me-Tmp" );
Since there is no default ctor, "Call-Me-Tmp" must be created before the
temporary to which ref is bound. '2' above states that Call-Me-Tmp will
be destroyed at the end of the statement, whilst the X bound to ref has
the same lifetime as ref. This contradicts 5.
[Solution is to change 5 to apply only to references not bound to
temporaries?]
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Implicitly generated copy assignment operator
Category: Clarification
Date: 1/8/95
Status: Open
Number: 323
Section: 12.8 [class.copy] para 10
X-Ref: 193
Description:
See 320, 322. The impicitly gerenated copy assignment operator should
not be able to copy volatile objects.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: What is a copy constructor?
Category: Clarification
Date: 1/8/95
Status: Open
Number: 320
Section: 12.8 [class.copy] para 3
X-Ref: 188
Description:
The WP is currently unclear on this. The BSI preference is that
constructors with parameter type volatile X& and const volatile X& are
not copy constructor. This must be clarified.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Implicitly declared copy constructor
Category: Clarification
Date: 1/8/95
Status: Open
Number: 321
Section: 12.8 [class.copy] para 5
X-Ref: 189
Description:
See issue 320. A constructor that can copy volatile objects should not
be a copy constructor, so the implicitly generated one should not be
able to copy volatile objects. The WP needs to make this clear.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Copy assignment operator
Category: Clarification
Date: 1/8/95
Status: Open
Number: 322
Section: 12.8 [class.copy] para 9
X-Ref: 192
Description:
See issue 320. An assignment operator that takes volatile ref parameters
should not be a copy assignment operator.
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category: Editorial
Date: 11/9/95
Status: Open
Number: 559
Section: 13 [over] para 2
X-Ref:
Description:
Change the first sentence to:
Comparison of the types of the arguments at the point of use of
an overloaded function name with the types of the parameters in
the set of overloaded declarations that are visible at the point
of use is used to determine which declaration is being referenced.
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category: Editorial
Date: 11/9/95
Status: Open
Number: 560
Section: 13.1 [over.load]
X-Ref:
Description:
The whole of this section needs re-writing. Each "bullet" point should
be a separately numbered paragraph:
Function declarations that differ only in return type cannot be
overloaded.
Member function declarations with the same name and the same
parameter
types cannot be overloaded if any of them is a static member
function
declaration[class.static].
...etc...
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 11/9/95
Status: Open
Number: 564
Section: 13.3.1.1 [over.best.ics] para 9
X-Ref:
Description:
In footnote 91, change:
...then f(b) would resolved to...
to:
...then f(b) would resolve to...
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 11/9/95
Status: Open
Number: 561
Section: 13.3.1.1 [over.match.call] para 2
X-Ref:
Description:
Change:
...used in the first two cases...
to:
...used in the first and third cases...
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 11/9/95
Status: Open
Number: 562
Section: 13.3.1.1 [over.match.call] para 3
X-Ref:
Description:
In the first sentence, change:
The third case arises from...
to:
The fourth case arises from...
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category:
Date: 11/9/95
Status: Open
Number: 563
Section: 13.3.3.1 [over.best.ics] para 9
X-Ref:
Description:
It would be much clearer if footnote 91 could be kept on one page instead
of being split across two.
----------------------------------------------------------------------
Owner: John Borthwick
Summary:
Category: Editorial
Date: 11/9/95
Status: Open
Number: 565
Section: 13.5 [over.oper] para 6
X-Ref:
Description:
In the fourth sentence, change:
Operator functions are inherited the same as other functions,...
to:
Opertaor functions are inherited in the same manner as other
base class functions,...
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: Template identity model
Category: Modelling
Date: 15/6/95
Status: Open
Number: 217
Section: 14
X-Ref:
Description:
A description of the template identity model is required. Of the two
models so far proposed, the discrete and the unified models, we have no
preference currently. This may change when a concrete model has been
produced and the consequences of it and its impact on the rest of the
language can be more easily assessed.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: ODR requirements
Category: Editorial
Date: 18/9/95
Status: Open
Number: 578
Section: 14 [temp]
X-Ref: 197
Description:
The requirements on unique definition of templates shall be made
consistent with the One Definition Rule 3.2 [basic.def.odr]
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: Non-normative text and unclear intent
Category: Clarification
Date: 15/9/95
Status: Open
Number: 567
Section: 14.02 [temp.res] para 4
X-Ref:
Description:
The text refers to 'errors' and discusses when they are diagnosed. This is
clearly non-normative. Replace sentences 2-4:
Syntax errors...with the dependent type errors.
With:
[Note: syntactically ill-formed template declarations will cause
a diagnostic to be issued regardless of whether the template is
instantiated or not.]
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: What does 'mention' mean?
Category: Clarification
Date: 18/9/95
Status: Open
Number: 587
Section: 14.02.3 [temp.dep]
X-Ref:
Description:
The phrase "depends on" is defined in terms of "mentioned" but the latter
is not defined.
A more precise definition of either "depends on" or "mentioned" is
required. In particular, the behaviour of the following example must be
clearly specified:
typedef Thing X;
Temp<X> x;
'Thing' is not "mentioned" in the template argument ('X') but clearly
function calls inside 'Temp' could depend on 'Thing' without needing the
definition of 'X'.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: template-id and member templates
Category: Editorial
Date: 18/9/95
Status: Open
Number: 580
Section: 14.03 [temp.inst]
X-Ref:
Description:
The wording seems to disallow member templates being explicitly
specialised because the 'name' in the definition is required to be a
'template-id'.
Replace:
A class defined with a template-id as its name is called
an explicitly specialized class. A function defined with a
template-id as its name is called an explicitly specialized
function. A static data member defined with a template-id as its
name is called an explicitly specialized static data member.
With:
A class, function or static data member defined with a
template-id as the unqualified-id in its name is called an
explicitly specialized class, explicitly specialized function
or explicitly specialized static data member respectively.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: [temp.linkage] partly conflicts with 14.1 [temp.names]
Category: Clarification
Date: 15/9/95
Status: Open
Number: 566
Section: 14.03.1 [temp.linkage]
X-Ref:
Description:
Linkage of template functions is already described in 14.1 [temp.names]
and 14.3.1 [temp.linkage] incorrectly prohibits internal linkage for
template functions.
Delete subclause 14.3.1 [temp.linkage].
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: Name injection
Category: Language change
Date: 18/9/95
Status: Open
Number: 583
Section: 14.03.2 [temp.point]
X-Ref:
Description:
Name injection interacts badly with namespaces.
Either:
a) change name injection to inject into the namespace of the template
definition and define the 'sequence points' for injection, or
b) remove name injection from the language and provide an alternative
mechanism to allow conversions on function template arguments
(to support existing techniques).
The UK have a preference for (b).
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: What does 'use' mean?
Category: Clarification
Date: 18/9/95
Status: Open
Number: 586
Section: 14.03.2 [temp.point]
X-Ref:
Description:
The phrase "used in a way that requires a specialization of its
definition" appears in the CD but no definition of this is given. We
believe the intent is that a specialisation of a template class is
required whenever the template class is required to be complete.
Change:
requiring its definition
and
requires a specialization of its definition
To:
requir(ing/es) the template class to be complete
Although this does not define the 'use' it reduces the number of cases
that need to be defined (the meaning of 'use' is raised elsewhere in
the discussion of complete versus incomplete types).
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: Explicit instantiation syntax
Category: Language change
Date: 18/9/95
Status: Open
Number: 584
Section: 14.04 [temp.explicit]
X-Ref:
Description:
An explicit instantiation should not require '<>' for a function template
where all the arguments can be deduced. Replace 14.4 [temp.explicit]
para 2 qualifying clause:
Where the unqualifier-id in the declaration shall be a
template-id.
With:
Where the unqualified-id in the declaration shall be a
template-id, unless the declaration names a function template
for which all the template parameters can be deduced from the
parameter types given in the declaration where the unqualified-id
shall be a template-id or an identifier.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: "template function" versus "function template"
Category: Clarification
Date: 15/9/95
Status: Open
Number: 568
Section: 14.10 [temp.fct] (and 14 [temp])
X-Ref:
Description:
There is no distinction between "template class" and "class template":
both name a template and the instantiated template is called a
"specialisation". The same should be true for function templates. Delete
the [temp.fct] sentence:
A function generated from a function template is called a template
function, so is...
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: Deducing template template-parameters
Category: Clarification
Date: 18/9/95
Status: Open
Number: 585
Section: 14.10.2 [temp.deduct]
X-Ref:
Description:
The CD does not specify whether it is possible to deduce the type of a
template template-parameter. Wording should be added to clearly state that
such a deduction is not possible.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary:
Category: Library change
Date: 11/8/95
Status: Open
Number: 555
Section: 17-27
X-Ref:
Description:
Re-partition the library namespace into sub-namespaces.
----------------------------------------------------------------------
Owner: Andy Sawyer
Summary:
Category: Editorial
Date: 18/9/95
Status: Open
Number: 610
Section: 26.3.1.2 [lib.valarray.assign]
X-Ref:
Description:
In the first line of this sub-clause, replace:
operator=( const valarr<T>y& );
With:
operator=( const valarry<T>& );
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Fixed
Number: 258
Section: 01.8 [intro.execution] para 2
X-Ref:
Description:
Change:
, which documentation defines...
to:
. Such documentation shall define...
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Terminology
Date: 21/7/94
Status: Fixed
Number: 17
Section: 01.8 [intro.execution] para 3
X-Ref:
Description:
Should "unspecified" always specify the range of allowable behaviours?
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Fixed
Number: 278
Section: 02.7 [lex.name] para 1
X-Ref:
Description:
Change:
The first character is a letter; the underscore _ counts as
a letter.
to:
The first character shall be a non-digit.
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 3/7/95
Status: Fixed
Number: 281
Section: 02.8 [lex.key] para 3
X-Ref:
Description:
The status of the term "avoided" is not defined. Replace with "Use of
reserved identifiers results in undefined behaviour."
----------------------------------------------------------------------
Owner: Sean Corfield
Summary:
Category: Editorial
Date: 21/7/94
Status: Fixed
Number: 23
Section: 02.9.2 [lex.ccon] para 3
X-Ref:
Description:
Change
the double quote ", ?, and
to
the double quote ", the question mark ?, and
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary: More precise reference in 3.3.9
Category: Editorial
Date: 23/9/94
Status: Fixed
Number: 66
Section: 03.3.08 [basic.scope.elab] para 1
X-Ref:
Description:
Change
prefixed with enum (7.1.5 [dcl.type])
to
prefixed with enum (7.1.5.3 [dcl.type.elab])
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category: Editorial
Date: 1/8/95
Status: Fixed
Number: 366
Section: 03.6.3 [basic.start.term] para 1
X-Ref:
Description:
In the second sentence, change:
Destruction is done in reverse order...
to:
Destruction is done in the reverse order...
----------------------------------------------------------------------
Owner: Derek Jones
Summary:
Category:
Date: 1/8/95
Status: Fixed
Number: 426
Section: 05 [expr] para 11
X-Ref:
Description:
In the last sentence remove quotes from "usual arithmetic conversions"
and change font.
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary:
Category: Editorial
Date: 27/2/95
Status: Fixed
Number: 144
Section: 09.4.2 [class.this] para 2
X-Ref:
Description:
In the example, change:
This is not allowed in a const member function where this is a...
to:
This is not allowed in a const member function, because this
is a...
----------------------------------------------------------------------
Owner: Steve Rumsby
Summary:
Category: Editorial
Date: 30/1/95
Status: Fixed
Number: 141
Section: 11.4 [class.friend] para 1
X-Ref:
Description:
Change:
A friend of a class is a function that is not a member of
to:
A friend of a class is a function or class that is not a
member of
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: Point of instantiation
Category: Clarification
Date: 18/9/95
Status: Fixed
Number: 581
Section: 14.03.2 [temp.point]
X-Ref:
Description:
The point of instantiation as defined in the CD means that the current
namespace scope definition containing the instantiation is not visible at
the point of instantiation.
Change the point of instantiation to make all namespace scope names that
are visible at the instantiation site also visible at the 'point of
instantiation'.
----------------------------------------------------------------------
Owner: Sean Corfield
Summary: What is 'for implementation purposes'?
Category: Clarification
Date: 18/9/95
Status: Fixed
Number: 582
Section: 14.03.2 [temp.point]
X-Ref:
Description:
Replace:
However, virtual functions can be instantiated for implementation
purposes.
With:
It is unspecified whether or not an implementation instantiates a
virtual member function that does not require instantiation.
----------------------------------------------------------------------