Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #112839
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Newsgroups | comp.lang.c |
| Subject | Re: Null pointer constant |
| Date | 2017-06-22 10:12 -0700 |
| Organization | None to speak of |
| Message-ID | <lnr2ycaqux.fsf@kst-u.example.com> (permalink) |
| References | (12 earlier) <kfnwp876wj5.fsf@x-alumni2.alumni.caltech.edu> <lny3smd5qx.fsf@kst-u.example.com> <kfny3sl6afc.fsf@x-alumni2.alumni.caltech.edu> <ln1sqdclr8.fsf@kst-u.example.com> <kfntw385xa7.fsf@x-alumni2.alumni.caltech.edu> |
Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>
>>> Keith Thompson <kst-u@mib.org> writes:
>>
>> [...]
>>
>>>> One could argue that the intent is that an implementation may
>>>> accept other forms of constant expression *without a diagnostic*.
>>>
>>> I agree; one could so argue. I think it would be hard to
>>> make the argument convincing, but certainly one could be made.
>>>
>>>> If not, 6.6p10 "An implementation may accept other forms of
>>>> constant expressions." would seem to be redundant, since it's
>>>> already covered by the permission to provide extensions.
>>>
>>> I don't think 6.6 p10 is redundant, because only some of the
>>> restrictions on various forms of constant expressions are
>>> constraints. In 6.6 p6, for example, there are restrictions
>>> on integer constant expressions that are not constraints.
>>> The allowance in 6.6 p10 could be used to establish other
>>> forms of integer constant expressions but which still did
>>> not violate the constraints in 6.6 p3.
>>
>> Hmm. Straying a bit into more quibbling, 6.6p6, defining "integer
>> constant expression", uses the word "shall" repeatedly:
>>
>> An *integer constant expression* shall have integer type and shall
>> only have operands that are integer constants, ...
>>
>> The standard defines what it means by "shall" (4p1-2), and since
>> 6.6p6 is not a constraint it implies that violating it causes
>> undefined behavior. Which would mean that `case 0.0:` does not
>> require a diagnostic, but does have undefined behavior.
>
> That isn't how I read it. There are two kinds of "shall"s,
> either a requirement on an implementation or a requirement on a
> program. The "shall"s in 6.6 p6 are clearly meant to be for
> implementations, not programs. Not meeting an implementation
> requirement means the implementation is not conforming, and the
> Standard doesn't have anything to say about non-conforming
> implementations except that they are not conforming.
Hmm. I don't see it.
First, I'll take a closer look at 4p1-2:
1. In this International Standard, "shall" is to be interpreted as a
requirement on an implementation or on a program; conversely, "shall
not" is to be interpreted as a prohibition.
2 If a "shall" or "shall not" requirement that appears outside of a
constraint or runtime-constraint is violated, the behavior is
undefined.
Would you agree that that last statement applies only to shalls
and shall nots that are requirements on programs? (I wouldn't mind
that being stated explicitly.) A requirement on an implementation
is one that an implementation must satisfy to be conforming. If an
implementation is not conforming, the standard has nothing further
to say about it.
A "shall" can apply either to an implementation or to a program.
6.6p5: "If a floating expression is evaluated in the translation
environment, the arithmetic range and precision shall be at
least as great as if the expression were being evaluated in the
execution environment." That's pretty clearly a requirement on
the implementation.
6.6p6: "An *integer constant expression* shall have integer type
and shall only have operands that are integer constants, [snip]".
That's the definition of "integer constant expression"; it tells
us what is an ICE and what is not an ICE. If it's a requirement
on the implementation, it's not clear what it requires. There are
already requirements elsewhere for the implementation to diagnose
a failure to use an ICE where one is required (actually stated as
a requirement on programs).
Most other definitions of terms don't use "shall" this way.
Why should this one? I think it would be clearer if written as:
"An *integer constant expression* is a constant expression that has
integer type and only has operands that are integer constants, ...".
Annex J is informative, not normative. J.2p1 lists instances of
undefined behavior. One of the cases is:
An expression that is required to be an integer constant
expression does not have an integer type; has operands that
are not integer constants, [snip]
It makes no sense to me that, for example, a case label:
case "foo":
has undefined behavior rather than being an error that must be
diagnosed. It appears that whoever wrote annex J assumed that the
"shalls" in 6.6 are requirements on a program. (I'm assuming that
violation of a requirement on an implementation doesn't result in
undefined behavior.) I wonder whether 6.6 and J were written by
different people.
[...]
> By the way, note a key difference between 6.6 p10 and extensions.
> Any extension must be documented, but AFAIK any new forms of
> various kinds of constant expressions accepted under 6.6 p10 do
> /not/ have to be documented.
Which seems odd. It would be silly for an implementation to
support other forms of constant expression and not document them.
I'd say this is an oversight; any additional forms should IMHO
be implementation-defined.
> (There is also the difference that a
> new form of constant expression /as an extension/ would probably
> require some sort of diagnostic, which 6.6 p10 can circumvent in
> many cases.)
How so? I note that you recently cited DR #032,
http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_032.html, which
says that an implementation that accepts (1, 2) as a constant
expression must still diagnose it as a constraint violation.
I have a possibly related question (I'm not sure yet whether the answer
has any actual effect). Can an expression that appears in a context
that doesn't require a constant expression be a constant expression?
For example, the definition of "null pointer constant" (which is not
mentioned in the grammar) is such that 0 is a null pointer constant
whether it appears in a pointer context or not. Given
int i = 0;
`i` is by definition an NPC, but the fact that it's an NPC is of
no relevance. At least that's what I've always assumed.
On the other hand, given
int i = 2 + 3*4;
`2 + 3` has the form of an additive-expression, but it isn't one,
nor is it an expression.
"constant-expression" is defined in the grammar, though most of the
definition is in the English wording in 6.6. Given the assignment
i = 42;
42 has the form of a constant-expression and meets the requirements,
but it doesn't parse as a constant-expression in the grammar.
As I started to write this, I was thinking that an expression isn't a
constant-expression unless it appears on a context that requires one --
but then in this declaration at block scope:
int *p = 0;
since the context doesn't require a constant expression, 0 wouldn't
be a constant expression, therefore it wouldn't be an integer
constant expression, and therefore it wouldn't be a null pointer
constant. Oops.
Resolving all this requires a lamentable application of common sense.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Back to comp.lang.c | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Null pointer constant bartc <bc@freeuk.com> - 2017-06-18 17:15 +0100
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-18 11:20 -0700
Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-18 19:23 +0100
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-18 20:57 +0100
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-18 13:38 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 04:35 -0700
Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-19 18:08 +0000
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 21:05 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:12 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 21:08 -0700
Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 00:34 +0100
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 04:45 -0700
Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 13:55 +0200
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 13:16 +0100
Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 16:58 +0100
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-18 20:58 +0000
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 00:11 +0100
Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 03:21 +0200
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 10:11 +0100
Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 12:38 +0200
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 13:05 +0100
Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 14:39 +0200
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-19 11:06 -0400
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 15:51 +0000
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-19 12:22 -0400
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 17:29 +0000
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-19 13:45 -0400
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:31 -0700
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 15:10 +0000
Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 16:53 +0100
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-19 13:06 -0400
Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 20:03 +0100
Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 22:37 +0200
Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-19 22:10 +0100
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 14:25 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 22:46 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 08:43 -0700
Re: Null pointer constant supercat@casperkitty.com - 2017-06-20 09:17 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-21 00:56 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-21 10:07 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-21 23:52 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-22 10:12 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-22 17:33 -0700
Re: Null pointer constant supercat@casperkitty.com - 2017-06-23 08:54 -0700
Re: Null pointer constant Manfred <invalid@invalid.add> - 2017-06-20 00:00 +0200
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 15:27 -0700
Re: Null pointer constant supercat@casperkitty.com - 2017-06-19 16:38 -0700
Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-20 01:14 +0100
Re: Null pointer constant Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-06-20 12:03 +0100
Re: Null pointer constant Manfred <noname@invalid.add> - 2017-06-20 13:16 +0200
Re: Null pointer constant jameskuyper@verizon.net - 2017-06-20 05:34 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 08:49 -0700
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-20 16:35 +0000
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 13:07 -0400
Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 17:29 +0000
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 13:55 -0400
Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 18:06 +0000
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 14:42 -0400
Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 19:10 +0000
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-20 18:31 +0000
Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 18:36 +0000
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 14:45 -0400
Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 17:14 +0000
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 11:55 -0700
Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 19:23 +0000
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-20 15:39 -0400
Re: Null pointer constant scott@slp53.sl.home (Scott Lurndal) - 2017-06-21 13:44 +0000
Re: Null pointer constant scott@slp53.sl.home (Scott Lurndal) - 2017-06-21 13:49 +0000
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-21 23:57 -0700
Re: Null pointer constant Philip Lantz <prl@canterey.us> - 2017-06-28 20:04 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-07-10 08:38 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 12:39 -0700
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-20 20:53 +0100
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 13:07 -0700
Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-20 20:50 +0000
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-20 15:35 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-21 00:26 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-21 09:54 -0700
Re: Null pointer constant "James R. Kuyper" <jameskuyper@verizon.net> - 2017-06-21 13:09 -0400
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-22 00:53 -0700
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-21 18:09 +0100
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-22 00:50 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 10:24 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 22:32 -0700
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 19:40 +0100
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:08 -0700
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 20:32 +0100
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:48 -0700
Re: Null pointer constant jameskuyper@verizon.net - 2017-06-19 13:08 -0700
Re: Null pointer constant Nick Bowler <nbowler@draconx.ca> - 2017-06-19 20:40 +0000
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 22:01 +0100
Re: Null pointer constant supercat@casperkitty.com - 2017-06-19 14:15 -0700
Re: Null pointer constant jameskuyper@verizon.net - 2017-06-19 14:25 -0700
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 21:06 +0000
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 14:28 -0700
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 21:35 +0000
Re: Null pointer constant supercat@casperkitty.com - 2017-06-19 14:48 -0700
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-20 15:38 +0000
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 15:16 -0700
Re: Null pointer constant supercat@casperkitty.com - 2017-06-19 14:29 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 15:18 -0700
Re: Null pointer constant Tim Rentsch <txr@alumni.caltech.edu> - 2017-06-19 22:48 -0700
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-20 15:09 +0100
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 10:19 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 10:15 -0700
Re: Null pointer constant David Brown <david.brown@hesbynett.no> - 2017-06-19 22:44 +0200
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:24 -0700
Re: Null pointer constant Ike Naar <ike@iceland.freeshell.org> - 2017-06-19 08:21 +0000
Re: Null pointer constant bartc <bc@freeuk.com> - 2017-06-19 10:17 +0100
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 10:04 -0700
Re: Null pointer constant Keith Thompson <kst-u@mib.org> - 2017-06-19 12:34 -0700
csiph-web