Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #112475 > unrolled thread
| Started by | bartc <bc@freeuk.com> |
|---|---|
| First post | 2017-06-18 17:15 +0100 |
| Last post | 2017-06-19 12:34 -0700 |
| Articles | 20 on this page of 111 — 14 participants |
Back to article view | Back to comp.lang.c
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
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
| From | Nick Bowler <nbowler@draconx.ca> |
|---|---|
| Date | 2017-06-20 18:36 +0000 |
| Message-ID | <oibpv0$oar$2@dont-email.me> |
| In reply to | #112719 |
On Tue, 20 Jun 2017 18:31:14 +0000, Ike Naar wrote: > On 2017-06-20, James R. Kuyper <jameskuyper@verizon.net> wrote: >> The standard does not define the term "operand". > > In 6.4.6p2, the term 'operand' appears in italics in the phrase > 'An /operand/ is an entity on which an operator acts'. Doesn't this > count as a definition? Yes, it does. The standard most definitely contains a definition of this term. This is easily confirmed by referring to the index, which indicates the sections in which term definitions are located by boldface.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-06-20 14:45 -0400 |
| Message-ID | <b798a3a2-35b8-53cf-b89a-3a1d99530b31@verizon.net> |
| In reply to | #112719 |
On 06/20/2017 02:31 PM, Ike Naar wrote: > On 2017-06-20, James R. Kuyper <jameskuyper@verizon.net> wrote: >> The standard does not define the term "operand". > > In 6.4.6p2, the term 'operand' appears in italics in the phrase > 'An /operand/ is an entity on which an operator acts'. Doesn't this > count as a definition? No, that counts - I just did a sloppy search when I was looking for that definition. So, as a primary-expression, "zero" contains no operators, and therefore no operands, and therefore (incorrectly) fails to violate the restrictions imposed by 6.6p6.
[toc] | [prev] | [next] | [standalone]
| From | Nick Bowler <nbowler@draconx.ca> |
|---|---|
| Date | 2017-06-20 17:14 +0000 |
| Message-ID | <oibl5s$d5s$3@dont-email.me> |
| In reply to | #112704 |
On Tue, 20 Jun 2017 16:35:12 +0000, Ike Naar wrote:
> Okay, 0 does qualify as a constant expression (it can be derived
> grammatically from a constant-expression (6.6), it evaluates to a
> constant that is in the range of representable values for its type
> (6.6p4)), but the question is whether it only has operands that
> are integer constants etc. (6.6p6).
>
> Does the expression 0 have operands at all? Acording to 6.4.6p2,
> an operand is defined as an entity on which an operator acts.
>
> But the expression 0 does not have an operator, so how can it have
> something on which the nonexisting operator acts?
>
> I'm starting to get confused. I am pretty sure the intention of the
> standard is that 0 is a null pointer constant, but does it follow
> from the words?
I think the text does have some wording problems but even a strict
reading of the text as it is written would seem to indicate 0 is an
integer constant expression.
0 is an integer constant expression because:
- it is a constant expression (for the reasons described above)
- it has integer type (int)
- it does not contain any operators, and therefore does not contain
any operands, thus vacuously satisfies all the restrictions on
operators and operands in 6.6p6.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-20 11:55 -0700 |
| Message-ID | <lnpodycwvb.fsf@kst-u.example.com> |
| In reply to | #112704 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2017-06-19, Keith Thompson <kst-u@mib.org> wrote:
>> Manfred <invalid@invalid.add> writes:
>> [...]
>>> This may be true as long as the standard is strictly read (I take your
>>> word for it), but I think there is a big difference in terms of the
>>> rationale behind it:
>>> C is a strongly typed language (less than C++, but more than many other
>>> languages), which means that it has well-defined rules for what is the
>>> type of a constant or expression, and it also has well-defined rules for
>>> how types are converted (cast, either implicitly or explicitly) from one
>>> to another.
>>
>> A terminology quibble: A conversion may be either implicit or explicit.
>> A cast is an explicit conversion. There is no such thing as an implicit
>> cast.
>>
>>> Now, 0 is an exception to this rule, in that it can be /either/ a
>>> integer constant, /or/ a null pointer constant.
>>
>> 0 *is* an integer constant, and it *is* a null pointer constant.
>
> It surely is an /integer constant/ (see 6.4.4.1), but, after having
> been exposed to the wondrous wordings of 6.6p6, one starts to wonder
> whether 0 is a /null pointer constant/. In order to qualify as such, it
> must, at least, qualify as an /integer constant expression/.
>
> Okay, 0 does qualify as a constant expression (it can be derived
> grammatically from a constant-expression (6.6), it evaluates to a
> constant that is in the range of representable values for its type
> (6.6p4)), but the question is whether it only has operands that
> are integer constants etc. (6.6p6).
>
> Does the expression 0 have operands at all? Acording to 6.4.6p2,
> an operand is defined as an entity on which an operator acts.
>
> But the expression 0 does not have an operator, so how can it have
> something on which the nonexisting operator acts?
>
> I'm starting to get confused. I am pretty sure the intention of the
> standard is that 0 is a null pointer constant, but does it follow
> from the words?
An expression can have things other than operands; it can also have
operators (and maybe other things I haven't checked). So as long as all
the operands qualify, even if there are none, it should qualify as an
integer constant expression.
The intent, I think, is quite obvious.
A better worded definition of "constant expression" would apply the
requirements to the "leaf nodes" of the expression, and in particular
to the constant 0 when it's the entire expression. Expressing that
in standardese is left as an exercise for the committee.
But if we look at the definition of "expression" (6.5p1):
An *expression* is a sequence of operators and operands that
specifies computation of a value, or that designates an object
or a function, or that generates side effects, or that performs
a combination thereof.
and take it literally, then 0 isn't even an expression; it has
no operators, and therefore no operands. Again, the intent is
obvious; the wording of the definition IMHO needs to be cleaned up.
(The counterargument to that is that nobody is actually confused
by it; no compiler is going to reject `x = 0;` on the grounds that
`0` isn't an expression.)
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Nick Bowler <nbowler@draconx.ca> |
|---|---|
| Date | 2017-06-20 19:23 +0000 |
| Message-ID | <oibsnd$oar$4@dont-email.me> |
| In reply to | #112724 |
On Tue, 20 Jun 2017 11:55:20 -0700, Keith Thompson wrote: [...] > But if we look at the definition of "expression" (6.5p1): > > An *expression* is a sequence of operators and operands that > specifies computation of a value, or that designates an object > or a function, or that generates side effects, or that performs > a combination thereof. > > and take it literally, then 0 isn't even an expression; it has > no operators, and therefore no operands. So there are actually two definitions of the term expression in the standard, the other is in 6.5.17 (where it appears on the left side of a syntax rule). By the syntax rule, 0 is as an expression. The italics in 6.5p1 are probably a mistake.
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-06-20 15:39 -0400 |
| Message-ID | <95e2b3e7-7d6d-44bf-229f-c462e2cb9573@verizon.net> |
| In reply to | #112727 |
On 06/20/2017 03:23 PM, Nick Bowler wrote: > On Tue, 20 Jun 2017 11:55:20 -0700, Keith Thompson wrote: > [...] >> But if we look at the definition of "expression" (6.5p1): >> >> An *expression* is a sequence of operators and operands that >> specifies computation of a value, or that designates an object >> or a function, or that generates side effects, or that performs >> a combination thereof. >> >> and take it literally, then 0 isn't even an expression; it has >> no operators, and therefore no operands. > > So there are actually two definitions of the term expression in the > standard, the other is in 6.5.17 (where it appears on the left side > of a syntax rule). By the syntax rule, 0 is as an expression. > > The italics in 6.5p1 are probably a mistake. I doubt it. I think the definition contains a mistake, but I'm fairly sure that making it a definition was entirely intentional.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-06-21 13:44 +0000 |
| Message-ID | <CKu2B.58804$OD2.32262@fx44.iad> |
| In reply to | #112730 |
ram@zedat.fu-berlin.de (Stefan Ram) writes: > Distribution through any means other than regular usenet > > channels is forbidden. It is forbidden to publish this > > article in the world wide web. It is forbidden to change > > URIs of this article into links. It is forbidden to remove > > this notice or to transfer the body without this notice. >X-No-Archive: Yes >Archive: no >X-No-Archive-Readme: "X-No-Archive" is only set, because this prevents some > > services to mirror the article via the web (HTTP). But Stefan Ram > > hereby allows to keep this article within a Usenet archive server > > with only NNTP access without any time limitation. >X-No-Html: yes >Content-Language: en >Bytes: 2974 >X-Received-Bytes: 2992 >X-Received-Body-CRC: 1086390303 > >"James R. Kuyper" <jameskuyper@verizon.net> writes: >>On 06/20/2017 03:23 PM, Nick Bowler wrote: >>>On Tue, 20 Jun 2017 11:55:20 -0700, Keith Thompson wrote: >>>>An *expression* is a sequence of operators and operands that >>>>specifies computation of a value, or that designates an object >>>>or a function, or that generates side effects, or that performs >>>>a combination thereof. >>I doubt it. I think the definition contains a mistake, but I'm fairly >>sure that making it a definition was entirely intentional. > > (In ASCII, we usually render italics using slashes, not with > asterisks.) Speak for yourself, please. It's far more likely for someone to apply _emphasis_ to plain ASCII, rather than /emphasis/.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2017-06-21 13:49 +0000 |
| Message-ID | <sPu2B.58806$OD2.2422@fx44.iad> |
| In reply to | #112773 |
scott@slp53.sl.home (Scott Lurndal) writes: >ram@zedat.fu-berlin.de (Stefan Ram) writes: >>"James R. Kuyper" <jameskuyper@verizon.net> writes: >>>On 06/20/2017 03:23 PM, Nick Bowler wrote: >>>>On Tue, 20 Jun 2017 11:55:20 -0700, Keith Thompson wrote: >>>>>An *expression* is a sequence of operators and operands that >>>>>specifies computation of a value, or that designates an object >>>>>or a function, or that generates side effects, or that performs >>>>>a combination thereof. >>>I doubt it. I think the definition contains a mistake, but I'm fairly >>>sure that making it a definition was entirely intentional. >> >> (In ASCII, we usually render italics using slashes, not with >> asterisks.) > >Speak for yourself, please. It's far more likely for >someone to apply _emphasis_ to plain ASCII, rather than >/emphasis/. > Or for the \fIunix folks\fI....
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-21 23:57 -0700 |
| Message-ID | <kfnpodw5x2k.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #112730 |
ram@zedat.fu-berlin.de (Stefan Ram) writes:
> "James R. Kuyper" <jameskuyper@verizon.net> writes:
>
>> On 06/20/2017 03:23 PM, Nick Bowler wrote:
>>
>>> On Tue, 20 Jun 2017 11:55:20 -0700, Keith Thompson wrote:
>>>
>>>> An *expression* is a sequence of operators and operands that
>>>> specifies computation of a value, or that designates an object
>>>> or a function, or that generates side effects, or that performs
>>>> a combination thereof.
>>
>> I doubt it. I think the definition contains a mistake, but I'm fairly
>> sure that making it a definition was entirely intentional.
>
> (In ASCII, we usually render italics using slashes, not with
> asterisks.)
>
> One might say that >>the English word "expression"<< and >>the
> non-terminal symbol "expression"<< are two different concepts.
>
> However, the quoted sentence is not a good definition. For
> example, after
>
> void f(){}
>
> , the expression >>f()<< does neither specify the computation
> of a value nor does it have an effect.
The 'f()' in 'void f(){}' is not an expression. By itself 'f()'
satisfied the syntax rules for the expression non-terminal, but
in the context of the whole program 'f()' is not an expression
here. Rather it is a declarator.
[toc] | [prev] | [next] | [standalone]
| From | Philip Lantz <prl@canterey.us> |
|---|---|
| Date | 2017-06-28 20:04 -0700 |
| Message-ID | <MPG.33be0e28a08dfc73147@news.eternal-september.org> |
| In reply to | #112821 |
Tim Rentsch wrote:
> Stefan Ram writes:
> > James R. Kuyper writes:
> >> Nick Bowler wrote:
> >>> Keith Thompson wrote:
> >>>
> >>>> An *expression* is a sequence of operators and operands that
> >>>> specifies computation of a value, or that designates an object
> >>>> or a function, or that generates side effects, or that performs
> >>>> a combination thereof.
> >>
> >> I doubt it. I think the definition contains a mistake, but I'm fairly
> >> sure that making it a definition was entirely intentional.
> >
> > (In ASCII, we usually render italics using slashes, not with
> > asterisks.)
> >
> > One might say that >>the English word "expression"<< and >>the
> > non-terminal symbol "expression"<< are two different concepts.
> >
> > However, the quoted sentence is not a good definition. For
> > example, after
> >
> > void f(){}
> >
> > , the expression >>f()<< does neither specify the computation
> > of a value nor does it have an effect.
>
> The 'f()' in 'void f(){}' is not an expression. By itself 'f()'
> satisfied the syntax rules for the expression non-terminal, but
> in the context of the whole program 'f()' is not an expression
> here. Rather it is a declarator.
He didn't say "in", he said "after".
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-07-10 08:38 -0700 |
| Message-ID | <kfninj0uwt0.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #112821 |
Philip Lantz <prl@canterey.us> writes:
[Please excuse the broken threading, my news client got confused
and messed things up irrecoverably :(]
> Tim Rentsch wrote:
>
>> Stefan Ram writes:
>>
>>> James R. Kuyper writes:
>>>
>>>> Nick Bowler wrote:
>>>>
>>>>> Keith Thompson wrote:
>>>>>
>>>>>> An *expression* is a sequence of operators and operands that
>>>>>> specifies computation of a value, or that designates an object
>>>>>> or a function, or that generates side effects, or that performs
>>>>>> a combination thereof.
>>>>
>>>> I doubt it. I think the definition contains a mistake, but I'm fairly
>>>> sure that making it a definition was entirely intentional.
>>>
>>> (In ASCII, we usually render italics using slashes, not with
>>> asterisks.)
>>>
>>> One might say that >>the English word "expression"<< and >>the
>>> non-terminal symbol "expression"<< are two different concepts.
>>>
>>> However, the quoted sentence is not a good definition. For
>>> example, after
>>>
>>> void f(){}
>>>
>>> , the expression >>f()<< does neither specify the computation
>>> of a value nor does it have an effect.
>>
>> The 'f()' in 'void f(){}' is not an expression. By itself 'f()'
>> satisfied the syntax rules for the expression non-terminal, but
>> in the context of the whole program 'f()' is not an expression
>> here. Rather it is a declarator.
>
> He didn't say "in", he said "after".
I see. The funny phrasing threw me off - using "the" in "the
expression f()" made me think he was referring to an already
written "f()", and there was only one of those, and it isn't
an expression. Better would be "a subsequent expression f()".
But it's not necessary to go to so much trouble. An expression
like "(void)0" doesn't satisfy the given definition either.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-20 12:39 -0700 |
| Message-ID | <lninjqcutd.fsf@kst-u.example.com> |
| In reply to | #112727 |
Nick Bowler <nbowler@draconx.ca> writes:
> On Tue, 20 Jun 2017 11:55:20 -0700, Keith Thompson wrote:
> [...]
>> But if we look at the definition of "expression" (6.5p1):
>>
>> An *expression* is a sequence of operators and operands that
>> specifies computation of a value, or that designates an object
>> or a function, or that generates side effects, or that performs
>> a combination thereof.
>>
>> and take it literally, then 0 isn't even an expression; it has
>> no operators, and therefore no operands.
>
> So there are actually two definitions of the term expression in the
> standard, the other is in 6.5.17 (where it appears on the left side
> of a syntax rule). By the syntax rule, 0 is as an expression.
>
> The italics in 6.5p1 are probably a mistake.
I'm sure the italics are deliberate. It's clearly intended to be
the definition of the term "expression". The problem is that it's
inconsistent with the implicit definition in the grammar.
And there are aspects that are not directly reflected in the grammar.
For example, `(T)0` is an expression if and only if T is a type name,
and the determination of whether T is a type name or not is not fully
specified by the grammar.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | bartc <bc@freeuk.com> |
|---|---|
| Date | 2017-06-20 20:53 +0100 |
| Message-ID | <_2f2B.3566$oU1.2317@fx14.am4> |
| In reply to | #112731 |
On 20/06/2017 20:39, Keith Thompson wrote:
> And there are aspects that are not directly reflected in the grammar.
> For example, `(T)0` is an expression if and only if T is a type name,
> and the determination of whether T is a type name or not is not fully
> specified by the grammar.
What else can (T)0 be? Assuming T represents an identifier rather than
an arbitrary type spec.
The grammar specifies the shape of the code, but plenty of things will
need checking. So in 'goto L', then L is an identifier that should be a
label name, or will be defined as 'L:' later on. It doesn't go into
scope either.
Some things /are/ ambiguous as the same 'shape' of code can mean two
things, depending on the symbol table. For example:
a(b); // define variable b of type a
a(b); // call function a with argument b
a*b; // define variable b as pointer to a
a*b; // multiply a by b then discard the result
But I don't think that (a)b is one of them. I think this can only mean
cast b to type a, and a must be a type.
--
baretc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-20 13:07 -0700 |
| Message-ID | <lnefuectip.fsf@kst-u.example.com> |
| In reply to | #112732 |
bartc <bc@freeuk.com> writes:
> On 20/06/2017 20:39, Keith Thompson wrote:
>> And there are aspects that are not directly reflected in the grammar.
>> For example, `(T)0` is an expression if and only if T is a type name,
>> and the determination of whether T is a type name or not is not fully
>> specified by the grammar.
>
> What else can (T)0 be? Assuming T represents an identifier rather than
> an arbitrary type spec.
A syntax error.
[...]
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Nick Bowler <nbowler@draconx.ca> |
|---|---|
| Date | 2017-06-20 20:50 +0000 |
| Message-ID | <oic1qs$oar$5@dont-email.me> |
| In reply to | #112731 |
On Tue, 20 Jun 2017 12:39:42 -0700, Keith Thompson wrote:
> Nick Bowler <nbowler@draconx.ca> writes:
>> On Tue, 20 Jun 2017 11:55:20 -0700, Keith Thompson wrote:
>> [...]
>>> But if we look at the definition of "expression" (6.5p1):
>>>
>>> An *expression* is a sequence of operators and operands that
>>> specifies computation of a value, or that designates an object
>>> or a function, or that generates side effects, or that performs
>>> a combination thereof.
>>>
>>> and take it literally, then 0 isn't even an expression; it has
>>> no operators, and therefore no operands.
>>
>> So there are actually two definitions of the term expression in the
>> standard, the other is in 6.5.17 (where it appears on the left side
>> of a syntax rule). By the syntax rule, 0 is as an expression.
>>
>> The italics in 6.5p1 are probably a mistake.
>
> I'm sure the italics are deliberate. It's clearly intended to be
> the definition of the term "expression". The problem is that it's
> inconsistent with the implicit definition in the grammar.
It's not really "implicit" -- definitions from syntax rules have
the same status as the other ways that terms can be defined per 3p1.
I don't know the intent of the authors but one of the two definitions
for expression is obviously wrong. It's hard to say that was the
intended definition.
Sadly, this is not the only instance of multiple definitions in the
standard, I did a quick flip through and found two, I expect there
are more:
6.4p1: token is defined in the left side of a syntax rule.
6.4p3: token is defined by italicised text.
In this case, I think the definition of token in 6.4p1 is the right one.
6.2.1p1: enumeration constant is defined by italicised text
6.4.4.3p1: enumeration constant is defined in the left side of a
syntax rule.
I'm not sure about this one.
> And there are aspects that are not directly reflected in the grammar.
> For example, `(T)0` is an expression if and only if T is a type name,
> and the determination of whether T is a type name or not is not fully
> specified by the grammar.
This doesn't affect the meaning of the terms, though. The syntax rules
do not stand in isolation, all of the text of the standard must be
considered.
Specifically, the definition of "typedef name" in 6.7.8p1 (from the left
hand side of a syntax rule) cannot be considered independent of 6.7.8p3
which explains /which/ identifiers count as typedef names.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-20 15:35 -0700 |
| Message-ID | <lna852cmnl.fsf@kst-u.example.com> |
| In reply to | #112739 |
Nick Bowler <nbowler@draconx.ca> writes:
> On Tue, 20 Jun 2017 12:39:42 -0700, Keith Thompson wrote:
>> Nick Bowler <nbowler@draconx.ca> writes:
>>> On Tue, 20 Jun 2017 11:55:20 -0700, Keith Thompson wrote:
>>> [...]
>>>> But if we look at the definition of "expression" (6.5p1):
>>>>
>>>> An *expression* is a sequence of operators and operands that
>>>> specifies computation of a value, or that designates an object
>>>> or a function, or that generates side effects, or that performs
>>>> a combination thereof.
>>>>
>>>> and take it literally, then 0 isn't even an expression; it has
>>>> no operators, and therefore no operands.
>>>
>>> So there are actually two definitions of the term expression in the
>>> standard, the other is in 6.5.17 (where it appears on the left side
>>> of a syntax rule). By the syntax rule, 0 is as an expression.
>>>
>>> The italics in 6.5p1 are probably a mistake.
>>
>> I'm sure the italics are deliberate. It's clearly intended to be
>> the definition of the term "expression". The problem is that it's
>> inconsistent with the implicit definition in the grammar.
>
> It's not really "implicit" -- definitions from syntax rules have
> the same status as the other ways that terms can be defined per 3p1.
Good point.
> I don't know the intent of the authors but one of the two definitions
> for expression is obviously wrong. It's hard to say that was the
> intended definition.
It's strictly incorrect whether it's a definition or not. I'm
reasonably certain the use of italics was deliberate, that it was
intended to be the definition of "expression", and that it was intended
to be consistent with the syntactic definition. It fell down on the
last point, but it would be the same error even if it were not a
definition but merely a general statement about expressions.
[snip]
>> And there are aspects that are not directly reflected in the grammar.
>> For example, `(T)0` is an expression if and only if T is a type name,
>> and the determination of whether T is a type name or not is not fully
>> specified by the grammar.
>
> This doesn't affect the meaning of the terms, though. The syntax rules
> do not stand in isolation, all of the text of the standard must be
> considered.
One could have a language whose syntax definition is internally
consistent and exhaustive. C is not such a language, largely
because of typedef names.
> Specifically, the definition of "typedef name" in 6.7.8p1 (from the left
> hand side of a syntax rule) cannot be considered independent of 6.7.8p3
> which explains /which/ identifiers count as typedef names.
--
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"
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-21 00:26 -0700 |
| Message-ID | <kfn37at7qde.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #112704 |
Ike Naar <ike@iceland.freeshell.org> writes:
> On 2017-06-19, Keith Thompson <kst-u@mib.org> wrote:
>
>> Manfred <invalid@invalid.add> writes:
>> [...]
>>
>>> This may be true as long as the standard is strictly read (I take your
>>> word for it), but I think there is a big difference in terms of the
>>> rationale behind it:
>>> C is a strongly typed language (less than C++, but more than many other
>>> languages), which means that it has well-defined rules for what is the
>>> type of a constant or expression, and it also has well-defined rules for
>>> how types are converted (cast, either implicitly or explicitly) from one
>>> to another.
>>
>> A terminology quibble: A conversion may be either implicit or explicit.
>> A cast is an explicit conversion. There is no such thing as an implicit
>> cast.
>>
>>> Now, 0 is an exception to this rule, in that it can be /either/ a
>>> integer constant, /or/ a null pointer constant.
>>
>> 0 *is* an integer constant, and it *is* a null pointer constant.
>
> It surely is an /integer constant/ (see 6.4.4.1), but, after having
> been exposed to the wondrous wordings of 6.6p6, one starts to wonder
> whether 0 is a /null pointer constant/. In order to qualify as such, it
> must, at least, qualify as an /integer constant expression/.
>
> Okay, 0 does qualify as a constant expression (it can be derived
> grammatically from a constant-expression (6.6), it evaluates to a
> constant that is in the range of representable values for its type
> (6.6p4)), but the question is whether it only has operands that
> are integer constants etc. (6.6p6).
>
> Does the expression 0 have operands at all? Acording to 6.4.6p2,
> an operand is defined as an entity on which an operator acts.
>
> But the expression 0 does not have an operator, so how can it have
> something on which the nonexisting operator acts?
>
> I'm starting to get confused. I am pretty sure the intention of the
> standard is that 0 is a null pointer constant, but does it follow
> from the words?
In comp.lang.c there is a game some people like to play, which
might be called "let's pretend the meaning of English words
and phrases used in the Standard is single-valued (and by the
way uses the values that I think it should)". Usually it's
easy to tell when people are playing it, because there are
giveaway phrases like "literal meaning" or "strictly speaking"
or "what the words actually say" in the comments. It's a fun
game, and I play it myself on occasion. However, please don't
fall into the trap of making it more than it is, because even
though it's fun to play it doesn't match how the authors of
the Standard interpret the text.
In an expression-statement like '0;', there is no doubt that '0'
is an expression and also an operand within that expression.
There is no explicit operator in this particular expression but
if there were '0' would surely be something being operated on
rather than something doing the operating. Or one might say that
there is an implicit operation of converting the value of zero to
the (void) type; note the parenthetical remark in 6.4.6 p2:
"other forms of operator also exist in some contexts"). Either
way, '0' is an operand, and by itself serves as an expression if
that is necessary for the surrounding context.
For 6.6 p6, it might seem like "operand" is being used in a way
that is not consistent with its definition. What is actually
going on is more subtle. In most cases where the Standard uses
"operand" there is an abuse of language going on. Consider an
expression like '1+2*3'. The operator '+' does not "act on" the
expression '2*3'. Rather the operation of addition "acts on" the
result of evaluating '2*3'. There is an inherent ambiguity
between results at runtime and their corresponding syntactic
forms at translation time. The word "operand" has to do double
duty, and one of those is ("strictly speaking") an abuse of
language relative to its definition. In 6.6 p6 "operand" is used
in the sense of what might be called "static operands" - those
parts of an expression where the computation does not involve
operators performed at runtime. Yes, that sense is not the same
as the sense of most of its other uses, but both are an abuse
of language considered in relation to its definition "taken
literally".
Taking all this into account, there are just a few conclusions:
There is no doubt that 0 by itself is an expression, and an
integer constant expression;
Text in the Standard definitely could stand some improvement
to make that more obvious; and
If you want to play the game, there is a lot more that can be
said, but at the end of the day you'll end up right back here,
so usually it's better just to give statements like the last
two and then move on.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2017-06-21 09:54 -0700 |
| Message-ID | <ln60fpcmcs.fsf@kst-u.example.com> |
| In reply to | #112756 |
Tim Rentsch <txr@alumni.caltech.edu> writes:
[...]
> In comp.lang.c there is a game some people like to play, which
> might be called "let's pretend the meaning of English words
> and phrases used in the Standard is single-valued (and by the
> way uses the values that I think it should)". Usually it's
> easy to tell when people are playing it, because there are
> giveaway phrases like "literal meaning" or "strictly speaking"
> or "what the words actually say" in the comments. It's a fun
> game, and I play it myself on occasion. However, please don't
> fall into the trap of making it more than it is, because even
> though it's fun to play it doesn't match how the authors of
> the Standard interpret the text.
To some extent, sure, it can be a game, but that's not all it is.
For example, when I point out that the definition of "expression"
is flawed, I'm not arguing that 0 really isn't an expression.
Rather, I'm advocating a change to the wording of the standard to
reflect its intent -- and meanwhile, I accept the need to use a bit
of common sense, using the obvious intent behind the words rather
than the literal words themselves to determine what is and is not
an expression.
> In an expression-statement like '0;', there is no doubt that '0'
> is an expression and also an operand within that expression.
Could it be that you're playing the game yourself?
We have two inconsistent definitions, a definition of "expression"
that requires it to include "operands", and a definition of
"operand", "an entity on which an operator acts". The latter seems
clear, unambiguous, and consistent with the usual English meaning of
the word -- which suggests that it's the definition of "expression"
that needs to be fixed.
I have no doubt that 0 is an expression. I do not believe that, if it
appears as a full expression, it is an "operand", nor do I think it's
useful to invent a mythical implicit "operator" to make it one.
On the other hand, the term "operand" could be redefined, but I
don't think that's the simplest and clearest solution.
I'd like a definition of "expression" that does not require it to
contain operators and/or operands. Simply deferring to the grammar
is one way to do that.
[...]
> For 6.6 p6, it might seem like "operand" is being used in a way
> that is not consistent with its definition.
The definition of "constant expression" also needs some work, I think.
On the other hand, I've read that definition before and not noticed
the problems; I subconsciously glossed over the inconsistencies.
> What is actually
> going on is more subtle. In most cases where the Standard uses
> "operand" there is an abuse of language going on. Consider an
> expression like '1+2*3'. The operator '+' does not "act on" the
> expression '2*3'. Rather the operation of addition "acts on" the
> result of evaluating '2*3'. There is an inherent ambiguity
> between results at runtime and their corresponding syntactic
> forms at translation time.
Yes, glossing over the distinction between constructs that appear
in C source and/or at compile time vs. constructs that exist at run
time is very common, and may be nearly inevitable. Describing the
language in a way that always makes that distinction clearly might
be an interesting challange. Doing so in a way that's legible to
a typical reader would be even more so.
[snip]
--
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"
[toc] | [prev] | [next] | [standalone]
| From | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-06-21 13:09 -0400 |
| Message-ID | <b87a43fc-9359-bb09-1ad6-628c5f3f1858@verizon.net> |
| In reply to | #112806 |
On 06/21/2017 12:54 PM, Keith Thompson wrote: > Tim Rentsch <txr@alumni.caltech.edu> writes: ... >> In an expression-statement like '0;', there is no doubt that '0' >> is an expression and also an operand within that expression. > > Could it be that you're playing the game yourself? > > We have two inconsistent definitions, a definition of "expression" > that requires it to include "operands", and a definition of > "operand", "an entity on which an operator acts". The latter seems > clear, unambiguous, and consistent with the usual English meaning of > the word -- which suggests that it's the definition of "expression" > that needs to be fixed. > > I have no doubt that 0 is an expression. I do not believe that, if it > appears as a full expression, it is an "operand", nor do I think it's > useful to invent a mythical implicit "operator" to make it one. The only time a null pointer constant is ever meaningfully different from what it would be if there were no such concept is when it's a operand: an operand of a cast, an equality comparison, or a ?: operator. However, 6.6p6 says "An integer constant expression ... shall only have operands...". To me, "have operands" implies that the operator that corresponds to those operands must itself be part of the integer constant expression (ICE). That the ICE is itself an operand of some other operator doesn't matter: the ICE does NOT have itself as an operand, because that operator isn't part of the ICE.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2017-06-22 00:53 -0700 |
| Message-ID | <kfnh8z85ugg.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #112809 |
"James R. Kuyper" <jameskuyper@verizon.net> writes: > On 06/21/2017 12:54 PM, Keith Thompson wrote: > >> Tim Rentsch <txr@alumni.caltech.edu> writes: > > ... > >>> In an expression-statement like '0;', there is no doubt that '0' >>> is an expression and also an operand within that expression. >> >> Could it be that you're playing the game yourself? >> >> We have two inconsistent definitions, a definition of "expression" >> that requires it to include "operands", and a definition of >> "operand", "an entity on which an operator acts". The latter seems >> clear, unambiguous, and consistent with the usual English meaning of >> the word -- which suggests that it's the definition of "expression" >> that needs to be fixed. >> >> I have no doubt that 0 is an expression. I do not believe that, if it >> appears as a full expression, it is an "operand", nor do I think it's >> useful to invent a mythical implicit "operator" to make it one. > > The only time a null pointer constant is ever meaningfully different > from what it would be if there were no such concept is when its a > operand: an operand of a cast, an equality comparison, or a ?: > operator. [...] That isn't quite right. There is also the case when it is used as an initializer, in which case there may be no operator in sight (ie, for the null pointer constant itself).
[toc] | [prev] | [next] | [standalone]
Page 4 of 6 — ← Prev page 1 2 3 [4] 5 6 Next page →
Back to top | Article view | comp.lang.c
csiph-web