Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #168574 > unrolled thread

Christmas Quiz 2022

Back to article view | Back to comp.lang.c

Contents

  Christmas Quiz 2022 Roman P <invalid@example.com> - 2022-12-18 20:00 +0000
    Re: Christmas Quiz 2022 Tony Oliver <guinness.tony@gmail.com> - 2022-12-18 13:18 -0800
      Re: Christmas Quiz 2022 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-18 16:48 -0800
      Re: Christmas Quiz 2022 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-18 17:18 -0800
        Re: Christmas Quiz 2022 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-19 19:39 -0800
      Re: Christmas Quiz 2022 Niles Rogoff <eternal-september@niles.xyz> - 2022-12-27 01:22 -0800
        Re: Christmas Quiz 2022 Öö Tiib <ootiib@hot.ee> - 2022-12-27 01:58 -0800
          Re: Christmas Quiz 2022 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-27 10:25 -0800
        Re: Christmas Quiz 2022 James Kuyper <jameskuyper@alumni.caltech.edu> - 2022-12-27 05:07 -0500
          Re: Christmas Quiz 2022 scott@slp53.sl.home (Scott Lurndal) - 2022-12-27 16:06 +0000
            Re: Christmas Quiz 2022 scott@slp53.sl.home (Scott Lurndal) - 2022-12-27 17:42 +0000
            Re: Christmas Quiz 2022 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-27 13:53 -0800
      Re: Christmas Quiz 2022 Niles Rogoff <eternal-september@niles.xyz> - 2022-12-27 01:24 -0800
        Re: Christmas Quiz 2022 scott@slp53.sl.home (Scott Lurndal) - 2022-12-27 16:07 +0000
    Re: Christmas Quiz 2022 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-18 21:22 +0000
      Re: Christmas Quiz 2022 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-18 21:40 +0000
      Re: Christmas Quiz 2022 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-18 17:02 -0800
      Re: Christmas Quiz 2022 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-18 17:20 -0800
    Re: Christmas Quiz 2022 red floyd <no.spam.here@its.invalid> - 2022-12-18 13:36 -0800
    Re: Christmas Quiz 2022 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-18 13:48 -0800
      Re: Christmas Quiz 2022 Siri Cruise <chine.bleu@yahoo.com> - 2022-12-18 14:57 -0800
        Re: Christmas Quiz 2022 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-18 15:43 -0800
          Re: Christmas Quiz 2022 Lynn McGuire <lynnmcguire5@gmail.com> - 2022-12-19 23:40 -0600
        Re: Christmas Quiz 2022 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2022-12-20 14:01 -0800
    Re: Christmas Quiz 2022 Kaz Kylheku <864-117-4973@kylheku.com> - 2022-12-20 13:49 +0000
      Re: Christmas Quiz 2022 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-20 14:33 +0000
        Re: Christmas Quiz 2022 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-20 14:44 +0000
          Re: Christmas Quiz 2022 Ben Bacarisse <ben.usenet@bsb.me.uk> - 2022-12-20 14:57 +0000
            Re: Christmas Quiz 2022 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-20 15:03 +0000
              Re: Christmas Quiz 2022 David Brown <david.brown@hesbynett.no> - 2022-12-20 16:32 +0100
              Re: Christmas Quiz 2022 Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-20 15:41 +0000
                Re: Christmas Quiz 2022 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-20 10:22 -0800
                  Re: for() syntax (Was: Christmas Quiz 2022) Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2022-12-20 18:54 +0000
                    Re: for() syntax Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-20 12:08 -0800
                    Re: for() syntax (Was: Christmas Quiz 2022) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-26 06:48 -0800
                  Re: Christmas Quiz 2022 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-26 06:25 -0800
                Re: Christmas Quiz 2022 Tim Rentsch <tr.17687@z991.linuxsc.com> - 2022-12-26 06:24 -0800
                  Re: Christmas Quiz 2022 Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2022-12-26 13:05 -0800
    Re: Christmas Quiz 2022 Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-12-20 12:46 -0800
      Re: Christmas Quiz 2022 Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-20 23:49 +0200
        Re: Christmas Quiz 2022 Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-12-20 14:00 -0800
          Re: Christmas Quiz 2022 Paavo Helde <eesnimi@osa.pri.ee> - 2022-12-21 00:13 +0200
            Re: Christmas Quiz 2022 Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-12-20 14:38 -0800
      Re: Christmas Quiz 2022 Andrey Tarasevich <andreytarasevich@hotmail.com> - 2022-12-20 21:31 -0800
        Re: Christmas Quiz 2022 David Brown <david.brown@hesbynett.no> - 2022-12-21 12:02 +0100

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

#168580

In article <tno1qh$21o4$2@dont-email.me>,
 "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:

> On 12/18/2022 12:00 PM, Roman P wrote:
> > 1) What happens when you divide an int variable by 0?
> [...]
> 
> Undefined behavior.

https://www.youtube.com/watch?v=JOiZP8FS5Ww

Saved by zero.

-- 
:-<> Siri Seal of Disavowal #000-001. Disavowed. Denied. Deleted.    @
'I desire mercy, not sacrifice.'                                    /|\
Discordia: not just a religion but also a parody. This post         / \
I am an Andrea Chen sockpuppet.                  insults Islam.  Mohammed

[toc] | [prev] | [next] | [standalone]

#168583

On 12/18/2022 2:57 PM, Siri Cruise wrote:
> In article <tno1qh$21o4$2@dont-email.me>,
>   "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
> 
>> On 12/18/2022 12:00 PM, Roman P wrote:
>>> 1) What happens when you divide an int variable by 0?
>> [...]
>>
>> Undefined behavior.
> 
> https://www.youtube.com/watch?v=JOiZP8FS5Ww
> 
> Saved by zero.
> 

No shit! lol. :^)

I have worked on some stuff that would detect a divide by zero condition 
and altered it before it occurred. It would log the condition, then 
change the denominator.

[toc] | [prev] | [next] | [standalone]

#168605

On 12/18/2022 5:43 PM, Chris M. Thomasson wrote:
> On 12/18/2022 2:57 PM, Siri Cruise wrote:
>> In article <tno1qh$21o4$2@dont-email.me>,
>>   "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
>>
>>> On 12/18/2022 12:00 PM, Roman P wrote:
>>>> 1) What happens when you divide an int variable by 0?
>>> [...]
>>>
>>> Undefined behavior.
>>
>> https://www.youtube.com/watch?v=JOiZP8FS5Ww
>>
>> Saved by zero.
>>
> 
> No s***! lol. :^)
> 
> I have worked on some stuff that would detect a divide by zero condition 
> and altered it before it occurred. It would log the condition, then 
> change the denominator.

We set the result of all divisions by zero to be zero.  Not perfect but 
usually is a initialization problem.

Lynn

[toc] | [prev] | [next] | [standalone]

#168624

On 12/18/2022 2:57 PM, Siri Cruise wrote:
> In article <tno1qh$21o4$2@dont-email.me>,
>   "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
> 
>> On 12/18/2022 12:00 PM, Roman P wrote:
>>> 1) What happens when you divide an int variable by 0?
>> [...]
>>
>> Undefined behavior.
> 
> https://www.youtube.com/watch?v=JOiZP8FS5Ww
> 
> Saved by zero.
> 

the null lines:

https://youtu.be/MC4yCPbdbT4
(lord of the null lines)

[toc] | [prev] | [next] | [standalone]

#168607

On 2022-12-18, Roman P <invalid@example.com> wrote:
> 6) What are the three parts of a for statement and which of them are 
> required?

Check your fingers; I count nine:

  for ( init ; test ; step ) stmt
  1   2  3   4   5  6  7   8  9

-- 
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

[toc] | [prev] | [next] | [standalone]

#168609

Kaz Kylheku <864-117-4973@kylheku.com> writes:

> On 2022-12-18, Roman P <invalid@example.com> wrote:
>> 6) What are the three parts of a for statement and which of them are 
>> required?
>
> Check your fingers; I count nine:
>
>   for ( init ; test ; step ) stmt
>   1   2  3   4   5  6  7   8  9

or possibly 8:

    for ( declaration test ; step ) stmt
    1   2      3       4   5  6   7  8

depending on what you include in "init".

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#168610

On Tue, 20 Dec 2022 14:33:36 +0000, Ben Bacarisse wrote:

> Kaz Kylheku <864-117-4973@kylheku.com> writes:
> 
>> On 2022-12-18, Roman P <invalid@example.com> wrote:
>>> 6) What are the three parts of a for statement and which of them are
>>> required?
>>
>> Check your fingers; I count nine:
>>
>>   for ( init ; test ; step ) stmt 1   2  3   4   5  6  7   8  9
> 
> or possibly 8:
> 
>     for ( declaration test ; step ) stmt 1   2      3       4   5  6   7
>      8
> 
> depending on what you include in "init".

The C11 draft standard defines the for statement as
  for ( clause-1 ; expression-2 ; expression-3 ) statement
where
  clause-1 may be a declaration or an expression.

The notable point is that the semicolon between clause-1
and expression-2 is /not/ part of clause-1, but is, instead
part of the for statement itself.

Because of this, I don't believe that your count can be correct.
But, I'm willing to be educated on this :-)


-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#168611

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Tue, 20 Dec 2022 14:33:36 +0000, Ben Bacarisse wrote:
>
>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>> 
>>> On 2022-12-18, Roman P <invalid@example.com> wrote:
>>>> 6) What are the three parts of a for statement and which of them are
>>>> required?
>>>
>>> Check your fingers; I count nine:
>>>
>>>   for ( init ; test ; step ) stmt 1   2  3   4   5  6  7   8  9
>> 
>> or possibly 8:
>> 
>>     for ( declaration test ; step ) stmt 1   2      3       4   5  6   7
>>      8
>> 
>> depending on what you include in "init".
>
> The C11 draft standard defines the for statement as
>   for ( clause-1 ; expression-2 ; expression-3 ) statement

I was reading N1570 that is (I think) a draft of C11.  What is your
source?

> where
>   clause-1 may be a declaration or an expression.

In N1570, a declaration includes a semicolon but an expression does not
so I can't see how that can work.

> The notable point is that the semicolon between clause-1
> and expression-2 is /not/ part of clause-1, but is, instead
> part of the for statement itself.

But that does not help if the grammar for a declaration still includes a
semicolon.  I wonder what all the relevant parts of the draft you are
referring to look like when taken together.

> Because of this, I don't believe that your count can be correct.
> But, I'm willing to be educated on this :-)

Well, I did add (but then deleted) that the count depends on how the
grammar is structured.  I should look at a more recent draft that will
have taken the confirmed C11 text as a starting point.  I might do that
later, but I am in a rush!

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#168612

On Tue, 20 Dec 2022 14:57:56 +0000, Ben Bacarisse wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> 
>> On Tue, 20 Dec 2022 14:33:36 +0000, Ben Bacarisse wrote:
>>
>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>> 
>>>> On 2022-12-18, Roman P <invalid@example.com> wrote:
>>>>> 6) What are the three parts of a for statement and which of them are
>>>>> required?
>>>>
>>>> Check your fingers; I count nine:
>>>>
>>>>   for ( init ; test ; step ) stmt 1   2  3   4   5  6  7   8  9
>>> 
>>> or possibly 8:
>>> 
>>>     for ( declaration test ; step ) stmt 1   2      3       4   5  6  
>>>     7
>>>      8
>>> 
>>> depending on what you include in "init".
>>
>> The C11 draft standard defines the for statement as
>>   for ( clause-1 ; expression-2 ; expression-3 ) statement
> 
> I was reading N1570 that is (I think) a draft of C11.  What is your
> source?

N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x
6.8.5.3 The for statement
Paragraph 1: The statement
  for ( clause-1 ; expression-2 ; expression-3 ) statement
behaves as follows: ...


>> where
>>   clause-1 may be a declaration or an expression.
> 
> In N1570, a declaration includes a semicolon but an expression does not
> so I can't see how that can work.

>> The notable point is that the semicolon between clause-1 and
>> expression-2 is /not/ part of clause-1, but is, instead part of the for
>> statement itself.
> 
> But that does not help if the grammar for a declaration still includes a
> semicolon.  I wonder what all the relevant parts of the draft you are
> referring to look like when taken together.
> 
>> Because of this, I don't believe that your count can be correct.
>> But, I'm willing to be educated on this :-)
> 
> Well, I did add (but then deleted) that the count depends on how the
> grammar is structured.  I should look at a more recent draft that will
> have taken the confirmed C11 text as a starting point.  I might do that
> later, but I am in a rush!

Perhaps I've got an outdated copy of the draft standard, and the semi-
colon question was asked and answered in a later release.

Your explanation sounds valid to me. 'Tis a puzzle to be resolved later.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#168613

On 20/12/2022 16:03, Lew Pitcher wrote:
> On Tue, 20 Dec 2022 14:57:56 +0000, Ben Bacarisse wrote:
> 
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>
>>> On Tue, 20 Dec 2022 14:33:36 +0000, Ben Bacarisse wrote:
>>>
>>>> Kaz Kylheku <864-117-4973@kylheku.com> writes:
>>>>
>>>>> On 2022-12-18, Roman P <invalid@example.com> wrote:
>>>>>> 6) What are the three parts of a for statement and which of them are
>>>>>> required?
>>>>>
>>>>> Check your fingers; I count nine:
>>>>>
>>>>>    for ( init ; test ; step ) stmt 1   2  3   4   5  6  7   8  9
>>>>
>>>> or possibly 8:
>>>>
>>>>      for ( declaration test ; step ) stmt 1   2      3       4   5  6
>>>>      7
>>>>       8
>>>>
>>>> depending on what you include in "init".
>>>
>>> The C11 draft standard defines the for statement as
>>>    for ( clause-1 ; expression-2 ; expression-3 ) statement
>>
>> I was reading N1570 that is (I think) a draft of C11.  What is your
>> source?
> 
> N1570 Committee Draft — April 12, 2011 ISO/IEC 9899:201x
> 6.8.5.3 The for statement
> Paragraph 1: The statement
>    for ( clause-1 ; expression-2 ; expression-3 ) statement
> behaves as follows: ...
> 

And the "as follows" bit includes "If clause-1 is a declaration..." and 
"If clause-1 is an expression..."


> 
>>> where
>>>    clause-1 may be a declaration or an expression.
>>
>> In N1570, a declaration includes a semicolon but an expression does not
>> so I can't see how that can work.
> 
>>> The notable point is that the semicolon between clause-1 and
>>> expression-2 is /not/ part of clause-1, but is, instead part of the for
>>> statement itself.
>>
>> But that does not help if the grammar for a declaration still includes a
>> semicolon.  I wonder what all the relevant parts of the draft you are
>> referring to look like when taken together.
>>
>>> Because of this, I don't believe that your count can be correct.
>>> But, I'm willing to be educated on this :-)
>>
>> Well, I did add (but then deleted) that the count depends on how the
>> grammar is structured.  I should look at a more recent draft that will
>> have taken the confirmed C11 text as a starting point.  I might do that
>> later, but I am in a rush!
> 
> Perhaps I've got an outdated copy of the draft standard, and the semi-
> colon question was asked and answered in a later release.
> 
> Your explanation sounds valid to me. 'Tis a puzzle to be resolved later.
> 

I happen to have draft N2479 of C2x open on my desktop.  (I don't think 
it is the latest draft, but I don't tidy my desktop very often!)  In 
"6.7 Declarations", declarations still have the semi-colon as part of 
their grammar, just like in C11.

It looks like a bug in the standard, and it was still there in that 
later draft.

[toc] | [prev] | [next] | [standalone]

#168614

On Tue, 20 Dec 2022 15:03:36 +0000, Lew Pitcher wrote:

> On Tue, 20 Dec 2022 14:57:56 +0000, Ben Bacarisse wrote:
[snip]
>>> The notable point is that the semicolon between clause-1 and
>>> expression-2 is /not/ part of clause-1, but is, instead part of the
>>> for statement itself.
>> 
>> But that does not help if the grammar for a declaration still includes
>> a semicolon.  I wonder what all the relevant parts of the draft you are
>> referring to look like when taken together.
>> 
>>> Because of this, I don't believe that your count can be correct.
>>> But, I'm willing to be educated on this :-)
>> 
>> Well, I did add (but then deleted) that the count depends on how the
>> grammar is structured.  I should look at a more recent draft that will
>> have taken the confirmed C11 text as a starting point.  I might do that
>> later, but I am in a rush!
> 
> Perhaps I've got an outdated copy of the draft standard, and the semi-
> colon question was asked and answered in a later release.
> 
> Your explanation sounds valid to me. 'Tis a puzzle to be resolved later.

Oops... I found it.

Under 6.8.5 Iteration statements
Syntax
  ...
  for ( expression ; expression ; expression ) statement
  for ( declaration expression ; expression ) statement

(all expressions are marked optional)

Crisis averted. You are indeed correct, and I've learned something
new today.  :-)

But, that doesn't explain why 6.8.5.3 ("the for statement") shows
the syntax it does. Perhaps the draft missed something in resolving
the text between 6.8.5 and 6.8.5.3.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#168617

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
> On Tue, 20 Dec 2022 15:03:36 +0000, Lew Pitcher wrote:
>
>> On Tue, 20 Dec 2022 14:57:56 +0000, Ben Bacarisse wrote:
> [snip]
>>>> The notable point is that the semicolon between clause-1 and
>>>> expression-2 is /not/ part of clause-1, but is, instead part of the
>>>> for statement itself.
>>> 
>>> But that does not help if the grammar for a declaration still includes
>>> a semicolon.  I wonder what all the relevant parts of the draft you are
>>> referring to look like when taken together.
>>> 
>>>> Because of this, I don't believe that your count can be correct.
>>>> But, I'm willing to be educated on this :-)
>>> 
>>> Well, I did add (but then deleted) that the count depends on how the
>>> grammar is structured.  I should look at a more recent draft that will
>>> have taken the confirmed C11 text as a starting point.  I might do that
>>> later, but I am in a rush!
>> 
>> Perhaps I've got an outdated copy of the draft standard, and the semi-
>> colon question was asked and answered in a later release.
>> 
>> Your explanation sounds valid to me. 'Tis a puzzle to be resolved later.
>
> Oops... I found it.
>
> Under 6.8.5 Iteration statements
> Syntax
>   ...
>   for ( expression ; expression ; expression ) statement
>   for ( declaration expression ; expression ) statement
>
> (all expressions are marked optional)
>
> Crisis averted. You are indeed correct, and I've learned something
> new today.  :-)
>
> But, that doesn't explain why 6.8.5.3 ("the for statement") shows
> the syntax it does. Perhaps the draft missed something in resolving
> the text between 6.8.5 and 6.8.5.3.

Summary: You've found a bug in the standard, and not just in the draft.

Yes, the grammar is defined in 6.8.5 "Iteration statements".  The text in
6.8.5.3 "The for statement" talks about the semantics of for statements:

    The statement
    
        for ( clause-1 ; expression-2 ; expression-3 ) statement

    behaves as follows: [...]
    If clause-1 is a declaration, [...]

The problem is that if clause-1 is a declaration, it includes its own
trailing semicolon, which contradicts the grammar in 6.8.5.

The ability to have a declaration in the header of a for statement was
introduced in C99 (borrrowed from C++).  In C90, the "Iteration
statements" and "The for statement" sections were consistent, and the
grammar was

    for ( expression[opt] ; expression[opt] ; expression[opt ) statement

(I use square brackets to denote a subscript.)

My guess is that when the grammar was updated for C99, the author of the
update initially tried to have a unified grammar, replacing the first
expression by "clause-1" which could be either an expression or a
declaration.  They then realized that semicolon caused a problem and
updated 6.8.5 accordingly, but forgot to update 6.8.5.3.

This error occurs in the published C99 and C11 standards and in drafts
of C17 and C23 (N3054).

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#168618 — Re: for() syntax (Was: Christmas Quiz 2022)

On Tue, 20 Dec 2022 10:22:05 -0800, Keith Thompson wrote:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Tue, 20 Dec 2022 15:03:36 +0000, Lew Pitcher wrote:
>>
>>> On Tue, 20 Dec 2022 14:57:56 +0000, Ben Bacarisse wrote:
>> [snip]
>>>>> The notable point is that the semicolon between clause-1 and
>>>>> expression-2 is /not/ part of clause-1, but is, instead part of the
>>>>> for statement itself.
>>>> 
>>>> But that does not help if the grammar for a declaration still
>>>> includes a semicolon.  I wonder what all the relevant parts of the
>>>> draft you are referring to look like when taken together.
>>>> 
>>>>> Because of this, I don't believe that your count can be correct.
>>>>> But, I'm willing to be educated on this :-)
>>>> 
>>>> Well, I did add (but then deleted) that the count depends on how the
>>>> grammar is structured.  I should look at a more recent draft that
>>>> will have taken the confirmed C11 text as a starting point.  I might
>>>> do that later, but I am in a rush!
>>> 
>>> Perhaps I've got an outdated copy of the draft standard, and the semi-
>>> colon question was asked and answered in a later release.
>>> 
>>> Your explanation sounds valid to me. 'Tis a puzzle to be resolved
>>> later.
>>
>> Oops... I found it.
>>
>> Under 6.8.5 Iteration statements Syntax
>>   ...
>>   for ( expression ; expression ; expression ) statement for (
>>   declaration expression ; expression ) statement
>>
>> (all expressions are marked optional)
>>
>> Crisis averted. You are indeed correct, and I've learned something new
>> today.  :-)
>>
>> But, that doesn't explain why 6.8.5.3 ("the for statement") shows the
>> syntax it does. Perhaps the draft missed something in resolving the
>> text between 6.8.5 and 6.8.5.3.
> 
> Summary: You've found a bug in the standard, and not just in the draft.
> 
> Yes, the grammar is defined in 6.8.5 "Iteration statements".  The text
> in 6.8.5.3 "The for statement" talks about the semantics of for
> statements:
> 
>     The statement
>     
>         for ( clause-1 ; expression-2 ; expression-3 ) statement
> 
>     behaves as follows: [...]
>     If clause-1 is a declaration, [...]
> 
> The problem is that if clause-1 is a declaration, it includes its own
> trailing semicolon, which contradicts the grammar in 6.8.5.
> 
> The ability to have a declaration in the header of a for statement was
> introduced in C99 (borrrowed from C++).  In C90, the "Iteration
> statements" and "The for statement" sections were consistent, and the
> grammar was
> 
>     for ( expression[opt] ; expression[opt] ; expression[opt ) statement
> 
> (I use square brackets to denote a subscript.)
> 
> My guess is that when the grammar was updated for C99, the author of the
> update initially tried to have a unified grammar, replacing the first
> expression by "clause-1" which could be either an expression or a
> declaration.  They then realized that semicolon caused a problem and
> updated 6.8.5 accordingly, but forgot to update 6.8.5.3.
> 
> This error occurs in the published C99 and C11 standards and in drafts
> of C17 and C23 (N3054).

Correct me if I'm wrong, but I believe that this "bug in the standard"
goes a bit deeper than we've noticed.

Consider (from N1570)

  6.7 Declarations
    Syntax
      declaration:
        declaration-specifiers init-declarator-list[opt] ;
        static_assert-declaration

      declaration-specifiers:
        storage-class-specifier declaration-specifiers[opt]
        type-specifier declaration-specifiers[opt]
        type-qualifier declaration-specifiers[opt]
        function-specifier declaration-specifiers[opt]
        alignment-specifier declaration-specifiers[opt]

      init-declarator-list:
        init-declarator
        init-declarator-list , init-declarator

      init-declarator:
        declarator
        declarator = initializer

And
  6.8.5 Iteration statements
    Syntax
      iteration-statement:
        while ( expression ) statement
        do statement while ( expression ) ;
        for ( expression[opt] ; expression[opt] ; expression[opt] ) statement
        for ( declaration expression[opt] ; expression[opt] ) statement

(Like your post, square brackets here denotes a subscript) 

Does not the second form of the for() statement
    for ( declaration expression[opt] ; expression[opt] ) statement
permit the declaration part to /not/ have an initializer? As in
    for ( int i; i>0; ++i) continue;

While it looks "legal" to me, it certainly seems suspect. I would
have expected the standard to /require/ that the "declaration" part
of the for() statement include an initializer.

-- 
Lew Pitcher
"In Skills, We Trust"

[toc] | [prev] | [next] | [standalone]

#168619 — Re: for() syntax

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Tue, 20 Dec 2022 10:22:05 -0800, Keith Thompson wrote:
>
>> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>>> On Tue, 20 Dec 2022 15:03:36 +0000, Lew Pitcher wrote:
>>>
>>>> On Tue, 20 Dec 2022 14:57:56 +0000, Ben Bacarisse wrote:
>>> [snip]
>>>>>> The notable point is that the semicolon between clause-1 and
>>>>>> expression-2 is /not/ part of clause-1, but is, instead part of the
>>>>>> for statement itself.
>>>>> 
>>>>> But that does not help if the grammar for a declaration still
>>>>> includes a semicolon.  I wonder what all the relevant parts of the
>>>>> draft you are referring to look like when taken together.
>>>>> 
>>>>>> Because of this, I don't believe that your count can be correct.
>>>>>> But, I'm willing to be educated on this :-)
>>>>> 
>>>>> Well, I did add (but then deleted) that the count depends on how the
>>>>> grammar is structured.  I should look at a more recent draft that
>>>>> will have taken the confirmed C11 text as a starting point.  I might
>>>>> do that later, but I am in a rush!
>>>> 
>>>> Perhaps I've got an outdated copy of the draft standard, and the semi-
>>>> colon question was asked and answered in a later release.
>>>> 
>>>> Your explanation sounds valid to me. 'Tis a puzzle to be resolved
>>>> later.
>>>
>>> Oops... I found it.
>>>
>>> Under 6.8.5 Iteration statements Syntax
>>>   ...
>>>   for ( expression ; expression ; expression ) statement for (
>>>   declaration expression ; expression ) statement
>>>
>>> (all expressions are marked optional)
>>>
>>> Crisis averted. You are indeed correct, and I've learned something new
>>> today.  :-)
>>>
>>> But, that doesn't explain why 6.8.5.3 ("the for statement") shows the
>>> syntax it does. Perhaps the draft missed something in resolving the
>>> text between 6.8.5 and 6.8.5.3.
>> 
>> Summary: You've found a bug in the standard, and not just in the draft.
>> 
>> Yes, the grammar is defined in 6.8.5 "Iteration statements".  The text
>> in 6.8.5.3 "The for statement" talks about the semantics of for
>> statements:
>> 
>>     The statement
>>     
>>         for ( clause-1 ; expression-2 ; expression-3 ) statement
>> 
>>     behaves as follows: [...]
>>     If clause-1 is a declaration, [...]
>> 
>> The problem is that if clause-1 is a declaration, it includes its own
>> trailing semicolon, which contradicts the grammar in 6.8.5.
>> 
>> The ability to have a declaration in the header of a for statement was
>> introduced in C99 (borrrowed from C++).  In C90, the "Iteration
>> statements" and "The for statement" sections were consistent, and the
>> grammar was
>> 
>>     for ( expression[opt] ; expression[opt] ; expression[opt ) statement
>> 
>> (I use square brackets to denote a subscript.)
>> 
>> My guess is that when the grammar was updated for C99, the author of the
>> update initially tried to have a unified grammar, replacing the first
>> expression by "clause-1" which could be either an expression or a
>> declaration.  They then realized that semicolon caused a problem and
>> updated 6.8.5 accordingly, but forgot to update 6.8.5.3.
>> 
>> This error occurs in the published C99 and C11 standards and in drafts
>> of C17 and C23 (N3054).
>
> Correct me if I'm wrong, but I believe that this "bug in the standard"
> goes a bit deeper than we've noticed.

[snip]

> Does not the second form of the for() statement
>     for ( declaration expression[opt] ; expression[opt] ) statement
> permit the declaration part to /not/ have an initializer? As in
>     for ( int i; i>0; ++i) continue;

Yes, it does.

> While it looks "legal" to me, it certainly seems suspect. I would
> have expected the standard to /require/ that the "declaration" part
> of the for() statement include an initializer.

Probably not an unreasonable expectation, but in fact the standard does
not require an initializer.  (If it did, it would probably have been
expressed as a constraint, not as a grammar rule.)

There is a constraint in 6.8.5:

    The declaration part of a for statement shall only declare
    identifiers for objects having storage class auto or register.

which is why gcc rejected my attempt to use a typedef declaration.

I can't think of any *good* reason for the declaration not to include an
initializer, but the language doesn't require one (and there may well be
good reasons I haven't thought of).

Note that the feature came from C++, which lets you define constructors
that are invoked implicitly, so an initializer might not be needed.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#168640 — Re: for() syntax (Was: Christmas Quiz 2022)

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> [...concerning the syntax of for() statements...]
>
> Consider (from N1570)
>
>   6.7 Declarations
>     Syntax
>       declaration:
>         declaration-specifiers init-declarator-list[opt] ;
>         static_assert-declaration
>
>       declaration-specifiers:
>         storage-class-specifier declaration-specifiers[opt]
>         type-specifier declaration-specifiers[opt]
>         type-qualifier declaration-specifiers[opt]
>         function-specifier declaration-specifiers[opt]
>         alignment-specifier declaration-specifiers[opt]
>
>       init-declarator-list:
>         init-declarator
>         init-declarator-list , init-declarator
>
>       init-declarator:
>         declarator
>         declarator = initializer
>
> And
>   6.8.5 Iteration statements
>     Syntax
>       iteration-statement:
>         while ( expression ) statement
>         do statement while ( expression ) ;
>         for ( expression[opt] ; expression[opt] ; expression[opt] ) statement
>         for ( declaration expression[opt] ; expression[opt] ) statement
>
> (The square brackets here denotes a subscript)
>
> Does not the second form of the for() statement
>     for ( declaration expression[opt] ; expression[opt] ) statement
> permit the declaration part to /not/ have an initializer?  As in
>     for ( int i; i>0; ++i) continue;

Yes, it does, and clearly that is deliberate.

> While it looks "legal" to me, it certainly seems suspect.  I would
> have expected the standard to /require/ that the "declaration" part
> of the for() statement include an initializer.

Consider the following for() statement, which is allowed by the C
standard:

    for(  int i = 0, j, k;  i < N;  i++  )  ...

Would you insist that 'j' and 'k' also have initializers?

It seems obvious that the syntax for for() statements simply
reused the syntax for _declaration_ so as not to complicate the
language.  Whether declaring a non-initialized variable is useful
or not (and there are cases where it can be useful), that is not
sufficiently important to complicate the language by adding more
syntax (or a constraint).

Remember Flon's Law:  there has never been, nor will there ever
be, a programming language in which it is the least bit difficult
to write bad programs.

What I think is funnier is that the for() statement below is also
allowed (as of C11):

    for(
        _Static_assert( 1 > 0, "fooled you!" );
        c = getchar(),  c != EOF;
        /* nothing */
    ){
        ...
    }

Here again, the negative consequence of allowing a _Static_assert
in a for() statement is outweighed by the cost of expanding the
syntax.  Special cases are anathema to ease of remembering and
ease of understanding.  Natural languages with lots of irregular
verbs are harder to learn than those with few irregular verbs.
The same idea applies to programming languages.

[toc] | [prev] | [next] | [standalone]

#168638

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:

> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>
>> On Tue, 20 Dec 2022 15:03:36 +0000, Lew Pitcher wrote:
>>
>>> On Tue, 20 Dec 2022 14:57:56 +0000, Ben Bacarisse wrote:
>>
>> [snip]
>>
>>>>> The notable point is that the semicolon between clause-1 and
>>>>> expression-2 is /not/ part of clause-1, but is, instead part of the
>>>>> for statement itself.
>>>>
>>>> But that does not help if the grammar for a declaration still includes
>>>> a semicolon.  I wonder what all the relevant parts of the draft you are
>>>> referring to look like when taken together.
>>>>
>>>>> Because of this, I don't believe that your count can be correct.
>>>>> But, I'm willing to be educated on this :-)
>>>>
>>>> Well, I did add (but then deleted) that the count depends on how the
>>>> grammar is structured.  I should look at a more recent draft that will
>>>> have taken the confirmed C11 text as a starting point.  I might do that
>>>> later, but I am in a rush!
>>>
>>> Perhaps I've got an outdated copy of the draft standard, and the semi-
>>> colon question was asked and answered in a later release.
>>>
>>> Your explanation sounds valid to me.  'Tis a puzzle to be resolved later.
>>
>> Oops... I found it.
>>
>> Under 6.8.5 Iteration statements
>> Syntax
>>   ...
>>   for ( expression ; expression ; expression ) statement
>>   for ( declaration expression ; expression ) statement
>>
>> (all expressions are marked optional)
>>
>> Crisis averted.  You are indeed correct, and I've learned something
>> new today.  :-)
>>
>> But, that doesn't explain why 6.8.5.3 ("the for statement") shows
>> the syntax it does.  Perhaps the draft missed something in resolving
>> the text between 6.8.5 and 6.8.5.3.
>
> Summary:  You've found a bug in the standard, and not just in the draft.
> [...]

Not a bug.  Please see my last response to Lew Pitcher
in this thread.

[toc] | [prev] | [next] | [standalone]

#168637

Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:

> On Tue, 20 Dec 2022 15:03:36 +0000, Lew Pitcher wrote:
>
>> On Tue, 20 Dec 2022 14:57:56 +0000, Ben Bacarisse wrote:
>
> [snip]
>
>>>> The notable point is that the semicolon between clause-1 and
>>>> expression-2 is /not/ part of clause-1, but is, instead part of
>>>> the for statement itself.
>>>
>>> But that does not help if the grammar for a declaration still
>>> includes a semicolon.  I wonder what all the relevant parts of the
>>> draft you are referring to look like when taken together.
>>>
>>>> Because of this, I don't believe that your count can be correct.
>>>> But, I'm willing to be educated on this :-)
>>>
>>> Well, I did add (but then deleted) that the count depends on how
>>> the grammar is structured.  I should look at a more recent draft
>>> that will have taken the confirmed C11 text as a starting point.
>>> I might do that later, but I am in a rush!
>>
>> Perhaps I've got an outdated copy of the draft standard, and the
>> semicolon question was asked and answered in a later release.
>>
>> Your explanation sounds valid to me.  'Tis a puzzle to be resolved
>> later.
>
> Oops... I found it.
>
> Under 6.8.5 Iteration statements
> Syntax
>   ...
>   for ( expression ; expression ; expression ) statement
>   for ( declaration expression ; expression ) statement
>
> (all expressions are marked optional)
>
> Crisis averted.  You are indeed correct, and I've learned something
> new today.  :-)
>
> But, that doesn't explain why 6.8.5.3 ("the for statement") shows
> the syntax it does.  Perhaps the draft missed something in resolving
> the text between 6.8.5 and 6.8.5.3.

This line

    for ( clause-1 ; expression-2 ; expression-3 ) statement

in 6.8.5.3 p1 is not syntax.  It may /look/ like syntax, but it
isn't;  it is simply a template to assist the discussion later in
the same paragraph and subsequent paragraph (and also in various
footnotes).  How do we know it isn't syntax?  For starters, it
isn't labeled 'Syntax', as are all other syntax excerpts in the C
standard.  (Disclaimer:  I'm pretty sure this is true but I
didn't check every one.)  Also, none of clause-1, expression-2,
and expression-3 are defined non-terminals.  They are there to
serve as reference points for the subsequent discussion, not to
to be part of the C syntax.

So it seems clear that this non-syntax line is present as a
deliberate choice, put there to aid the discussion of semantics
but not as part of the C syntax.

[toc] | [prev] | [next] | [standalone]

#168643

Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Lew Pitcher <lew.pitcher@digitalfreehold.ca> writes:
>> On Tue, 20 Dec 2022 15:03:36 +0000, Lew Pitcher wrote:
>>> On Tue, 20 Dec 2022 14:57:56 +0000, Ben Bacarisse wrote:
>>
>> [snip]
>>
>>>>> The notable point is that the semicolon between clause-1 and
>>>>> expression-2 is /not/ part of clause-1, but is, instead part of
>>>>> the for statement itself.
>>>>
>>>> But that does not help if the grammar for a declaration still
>>>> includes a semicolon.  I wonder what all the relevant parts of the
>>>> draft you are referring to look like when taken together.
>>>>
>>>>> Because of this, I don't believe that your count can be correct.
>>>>> But, I'm willing to be educated on this :-)
>>>>
>>>> Well, I did add (but then deleted) that the count depends on how
>>>> the grammar is structured.  I should look at a more recent draft
>>>> that will have taken the confirmed C11 text as a starting point.
>>>> I might do that later, but I am in a rush!
>>>
>>> Perhaps I've got an outdated copy of the draft standard, and the
>>> semicolon question was asked and answered in a later release.
>>>
>>> Your explanation sounds valid to me.  'Tis a puzzle to be resolved
>>> later.
>>
>> Oops... I found it.
>>
>> Under 6.8.5 Iteration statements
>> Syntax
>>   ...
>>   for ( expression ; expression ; expression ) statement
>>   for ( declaration expression ; expression ) statement
>>
>> (all expressions are marked optional)
>>
>> Crisis averted.  You are indeed correct, and I've learned something
>> new today.  :-)
>>
>> But, that doesn't explain why 6.8.5.3 ("the for statement") shows
>> the syntax it does.  Perhaps the draft missed something in resolving
>> the text between 6.8.5 and 6.8.5.3.
>
> This line
>
>     for ( clause-1 ; expression-2 ; expression-3 ) statement
>
> in 6.8.5.3 p1 is not syntax.  It may /look/ like syntax, but it
> isn't;  it is simply a template to assist the discussion later in
> the same paragraph and subsequent paragraph (and also in various
> footnotes).  How do we know it isn't syntax?  For starters, it
> isn't labeled 'Syntax', as are all other syntax excerpts in the C
> standard.  (Disclaimer:  I'm pretty sure this is true but I
> didn't check every one.)  Also, none of clause-1, expression-2,
> and expression-3 are defined non-terminals.  They are there to
> serve as reference points for the subsequent discussion, not to
> to be part of the C syntax.
>
> So it seems clear that this non-syntax line is present as a
> deliberate choice, put there to aid the discussion of semantics
> but not as part of the C syntax.

I don't think that's nearly as clear as you think it is.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for XCOM Labs
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#168620

On 12/18/2022 12:00 PM, Roman P wrote:
> 1) What happens when you divide an int variable by 0?
> 2) What happens when you divide a double variable by 0?

Undefined behavior.

Nevertheless: what does "divide" mean in this context? There's more than 
one way to perform arithmetic division in C and C++.

> 3) What happens when you overflow an int variable, that is, set it to a
> value beyond its range?

"Set"? What does "set" mean in this context?

Behavior of variables in out-of-range situations depends critically on 
_how_ you attempt to produce an out-of-range value in it. For example, 
assignment is one thing, while side effect of `++` is a completely 
different thing.

> 4) What is the difference between x = y++; and x = ++y;?

Quite possibly, none. There's no reason to believe this code has any 
observable behavior.

> 6) What are the three parts of a for statement and which of them are
> required?

Even under superficial observation, for-statement has way more than 
three parts.

> 8) Does the following statement compile?
> 
> for ( ; ; ) ;

In C++: no way to say. An infinite loop that has no observable behavior 
produces undefined behavior. Possible manifestations of undefined 
behavior include failure to compile.

> 9) What does the underscore _ represent in a switch expression?

Nonsensical question. There's no such thing as "switch expression" 
neither in C nor in C++.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#168622

20.12.2022 22:46 Andrey Tarasevich kirjutas:

>> 4) What is the difference between x = y++; and x = ++y;?
> 
> Quite possibly, none. There's no reason to believe this code has any 
> observable behavior.

I guess he got you there. The value of x is observable. Too well-defined 
question?

[toc] | [prev] | [next] | [standalone]

Page 2 of 3 — ← Prev page 1 [2] 3  Next page →

Back to top | Article view | comp.lang.c

csiph-web