Topic: Some Draft Standard Comments.
Author: aitken@coho.halcyon.com (William E. Aitken)
Date: 1995/07/09 Raw View
I haven't had much time to review the draft, nor do I think I'm
going to send in any comments officially, but I do have a few comments.
Clause 1.8, Paragraph 4 says that the standard describes the effect
of dereferencing a null pointer as undefined. Can someone point me to
where it does so? The closest I've found is in paragraph 5 of clause 5,
but that seems awfully tenuous for something so fundamental.
Clause 2.8, the definition of preprocessing-op-or-punc raises a number
of problems. (1) At least two tokens . and .* are missing. (2) What
are new<%%> and delete<%%> for? (3) Why do they have to look so
much like alternate spellings of the non-existent tokens new{} and delete{}.
(4) Why aren't there alternate spellings for new[] and delete[]?
(5) Why are new[] and delete[] 1 token instead of three? (6)
is it intentional that in the scope of the directive
#define new foo
new[] expands to new[] rather than foo[], and that in the scope of
#define foo new
foo[] expands to a three token sequence new [ ] (with no intervening spaces)
rather than the single token new[]?
Clause 2.9.5. It seems unfortunate that you can't use
the boolean literal true in conditional inclusion directives----
well you can, but it doesn't do what you expect.
#if true
// random code
#endif
does NOT include the random code.
Clause 3.3 seems to use scope in circumstances where potential scope is
what is meant. For example, the second sentence of paragraph 1 of
3.3.1. This needs to be fixed.
Clause 3.3.1 Paragraph 8 talks about redeclaring variables in the controlling
expression of a do statement. How is this accomplished, since the grammar
(clause 6.5) is
do /statement/ while ( /expression/ ) ;
rather than
do /statement/ while ( /condition/ ) ;
Clause 4.5. Shouldn't footnote 34 be normative; i.e., shouldn't it be
moved up into the text of the standard?
Clause 5.2, Paragraph 10. Where does the standard tell us which operators
expect r-values? Paragraph 12 is really confusing, since it isn't obvious that
it's a definition of the ''usual arithmetic conversions'' defined in
paragraph 11.
Clause 5.2.2. Paragraph 7. What happens to bool arguments for which
there is no parameter? It seems that as written, a program
that passes
i != 0 && j != 0
in such a context and expects to retrieve it using va_arg(int)
is broken. This is surprising, and will probably break
programs.
Clause 5.2.5. Why are the rules for ++ and -- and bools so capricious?
Why allow ++ for bools, but not --? Why invent features merely to deprecate
them?
Clause 5.2.7. Paragraph 3 says "If the /expression/ is the result of applying
unary * to a pointer to a polymorphic type, then the pointer shall either be
zero or point to a valid object". How in the world do you print a diagnostic
if this semantic rule is violated? What does it mean for a pointer to be zero?
Clause 5.2.10. Because the subscripts are so messed up, and because
the committee hasn't published a rationale, I can't make head or tail of
the definition of casting away constness. Could someone explain them for me?
Clause 5.3.1, Paragraph 2, example. Why is the type int A::*? Please cite
chapter and verse.
Clause 5.3.4. A number of questions:
Is the allocation functio called for new float[0]? probably, but the
ordering of paragraphs suggests that it might not be. Paragraph 9 is strange
it seems to allow the new-expression to ask for less storage than it needs
(but not more) shouldn't it be required to ask for the right
amount of storage. In particular, the example of paragraph 12 requires this.
What happens if the allocation function returns null or throws an exception
other than bad_alloc? If it throws bad_alloc, does paragraph 16 mean that
the exception is caught inside the implementation of new?
What is the type of new int[0]?
Clause 5.3.5. new[] returns a pointer to the first element of the array,
but delete[] expects a pointer to the array. How do you get this pointer?
Clause 5.16. Suppose the following declarations:
bool f;
int rg1[10];
int rg2[9];
Is the expression
f ? rg1 : rg2
well formed? Note that ? : allows l-values in its second and third arguments,
Clause 5 paragraph 10 doesn't seem to apply.
Clause 5.17, Clause 7 (as written) seems to allow
float f;
f ^= 1.0;
Clause 5.19 seems to have stolen all of the ambiguities of C's specification
of constants. The biggest problem I have with it is its wholesale mixing
of syntactic and semantic things; for example, its talk of
expressions evaluating to arithmetic constant expressions is really grating.
Disclaimer: The views expressed in this message are my own, and do not
reflect the policies or opinions of my employer, Microsoft.
--
William E. Aitken | Formal verification is the
email: aitken@halcyon.com | future of computer science ---
Snail: 8500 148th Ave NE #H1026 Redmond WA | Always has been, always will be.
===============================================================================