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

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

error in code

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

Contents

  error in code "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-28 15:28 -0400
    Re: error in code pozz <pozzugno@gmail.com> - 2011-05-28 21:49 +0200
      Re: error in code "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-28 16:12 -0400
        Re: error in code Shao Miller <sha0.miller@gmail.com> - 2011-05-28 15:33 -0500
          Re: error in code "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-28 17:12 -0400
            Re: error in code Geoff <geoff@invalid.invalid> - 2011-05-28 14:26 -0700
            Re: error in code Shao Miller <sha0.miller@gmail.com> - 2011-05-28 16:29 -0500
            Re: error in code Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-28 17:26 -0600
        Re: error in code Geoff <geoff@invalid.invalid> - 2011-05-28 14:20 -0700
          Re: error in code "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-29 02:16 -0400
        Re: error in code Lew Pitcher <lpitcher@teksavvy.com> - 2011-05-28 16:35 -0400
          Re: error in code "Bill Cunningham" <nospam@nspam.invalid> - 2011-05-29 15:50 -0400
          Re: error in code Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-29 20:39 -0600
    Re: error in code Geoff <geoff@invalid.invalid> - 2011-05-28 13:46 -0700
    Re: error in code Nobody <nobody@nowhere.com> - 2011-05-28 23:06 +0100
      Re: error in code Ian Collins <ian-news@hotmail.com> - 2011-05-29 10:10 +1200
    Re: error in code Ian Collins <ian-news@hotmail.com> - 2011-05-29 10:09 +1200
    Re: error in code Angel <angel+news@spamcop.net> - 2011-05-28 22:28 +0000
      Re: error in code Ian Collins <ian-news@hotmail.com> - 2011-05-29 10:37 +1200
        Re: error in code Angel <angel+news@spamcop.net> - 2011-05-28 22:45 +0000
          Re: error in code Ian Collins <ian-news@hotmail.com> - 2011-05-29 10:48 +1200
            Re: error in code Angel <angel+news@spamcop.net> - 2011-05-28 22:56 +0000
              Re: error in code Seebs <usenet-nospam@seebs.net> - 2011-05-29 00:38 +0000
          Re: error in code "Morris Keesan" <mkeesan@post.harvard.edu> - 2011-05-28 23:11 -0400
    Re: error in code Keith Thompson <kst-u@mib.org> - 2011-05-28 15:54 -0700
    Re: error in code Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2011-05-28 17:23 -0600
    Re: error in code jacob navia <jacob@spamsink.net> - 2011-05-29 19:30 +0200
      Re: error in code Geoff <geoff@invalid.invalid> - 2011-05-29 18:14 -0700
        Re: error in code Keith Thompson <kst-u@mib.org> - 2011-05-29 18:50 -0700
          Re: error in code Geoff <geoff@invalid.invalid> - 2011-05-29 19:10 -0700
            Re: error in code Seebs <usenet-nospam@seebs.net> - 2011-05-30 02:54 +0000
              Re: error in code Geoff <geoff@invalid.invalid> - 2011-05-29 20:35 -0700
                Re: error in code Seebs <usenet-nospam@seebs.net> - 2011-05-30 06:15 +0000
        Re: error in code jacob navia <jacob@spamsink.net> - 2011-05-30 08:46 +0200
          Re: error in code Geoff <geoff@invalid.invalid> - 2011-05-30 18:50 -0700
            Re: error in code Keith Thompson <kst-u@mib.org> - 2011-05-31 10:49 -0700
      Re: error in code Peter Nilsson <airia@acay.com.au> - 2011-05-29 21:04 -0700
        Re: error in code jacob navia <jacob@spamsink.net> - 2011-05-30 08:44 +0200
        Re: error in code Tim Rentsch <txr@alumni.caltech.edu> - 2011-05-31 01:35 -0700
          Re: error in code pacman@kosh.dhis.org (Alan Curry) - 2011-05-31 23:36 +0000
            Re: error in code Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 03:01 -0700
              Re: error in code Keith Thompson <kst-u@mib.org> - 2011-06-01 08:08 -0700
                Re: error in code Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-01 12:50 -0700
                  Re: error in code Keith Thompson <kst-u@mib.org> - 2011-06-01 13:26 -0700
                    Re: error in code Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-02 18:10 -0700
                      Re: error in code jacob navia <jacob@spamsink.net> - 2011-06-03 11:55 +0200
                        Re: error in code Tim Rentsch <txr@alumni.caltech.edu> - 2011-06-03 19:37 -0700
                          Re: error in code jacob navia <jacob@spamsink.net> - 2011-06-04 08:13 +0200
        Re: error in code Nisse Engström <news.NOSPAM.idf0Z@luden.se> - 2011-06-01 09:02 +0200

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

#5168

pacman@kosh.dhis.org (Alan Curry) writes:

> In article <kfnr57fp8ro.fsf@x-alumni2.alumni.caltech.edu>,
> Tim Rentsch  <txr@alumni.caltech.edu> wrote:
>>Peter Nilsson <airia@acay.com.au> writes:
>>
>>> jacob navia <ja...@spamsink.net> wrote:
>>>> Le 28/05/11 21:28, Bill Cunningham a @C3{A9}crit :
>>>> >      double a[] = 2.2, 4.2, 5.00;
>>> ...
>>>> > p.c: In function `main':
>>>> > p.c:12: invalid initializer
>>>> > p.c:12: parse error before numeric constant
>>>>
>>>> ...lcc-win issued NO ERRORS AT ALL.
>>>
>>> Even if you claimed conformance, it's not required to. It
>>> follows the context free grammar.  [snip]
>>
>>Sure looks like a syntax error to me.  You have a
>>derivation to offer?
>
> I also think it's a syntax error, but take a look at this more subtle case:
>
>   int i=1, j=2;
>
>   int main(void)
>   {
>     int a[] = i, j;
>   }
>
> It's invalid because the array initializer doesn't have braces. But that's
> not a requirement of the grammar. In n1256.pdf, the clause that it violates
> is 6.7.8.16, under the heading of "Semantics", not "Constraints".
>
> And it can be made valid by putting braces around just the i, which makes a
> single-element a[] and a local j shadowing the global j:
>     int a[] = {i}, j;
> or by putting braces around both, making a 2-element a[]:
>     int a[] = {i, j};
>
> A compiler that accepts the form without braces must be choosing one of those
> interpretations. Which one?

If no diagnostic message is issued, the first one.

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

#5191

Tim Rentsch <txr@alumni.caltech.edu> writes:
> pacman@kosh.dhis.org (Alan Curry) writes:
[...]
>> I also think it's a syntax error, but take a look at this more subtle case:
>>
>>   int i=1, j=2;
>>
>>   int main(void)
>>   {
>>     int a[] = i, j;
>>   }
>>
>> It's invalid because the array initializer doesn't have braces. But that's
>> not a requirement of the grammar. In n1256.pdf, the clause that it violates
>> is 6.7.8.16, under the heading of "Semantics", not "Constraints".
>>
>> And it can be made valid by putting braces around just the i, which makes a
>> single-element a[] and a local j shadowing the global j:
>>     int a[] = {i}, j;
>> or by putting braces around both, making a 2-element a[]:
>>     int a[] = {i, j};
>>
>> A compiler that accepts the form without braces must be choosing one of those
>> interpretations. Which one?
>
> If no diagnostic message is issued, the first one.

How do you arrive at that conclusion?

If no diagnostic message is issued, the compiler is non-conforming.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#5226

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
>> pacman@kosh.dhis.org (Alan Curry) writes:
> [...]
>>> I also think it's a syntax error, but take a look at this more subtle case:
>>>
>>>   int i=1, j=2;
>>>
>>>   int main(void)
>>>   {
>>>     int a[] = i, j;
>>>   }
>>>
>>> It's invalid because the array initializer doesn't have braces. But that's
>>> not a requirement of the grammar. In n1256.pdf, the clause that it violates
>>> is 6.7.8.16, under the heading of "Semantics", not "Constraints".
>>>
>>> And it can be made valid by putting braces around just the i, which makes a
>>> single-element a[] and a local j shadowing the global j:
>>>     int a[] = {i}, j;
>>> or by putting braces around both, making a 2-element a[]:
>>>     int a[] = {i, j};
>>>
>>> A compiler that accepts the form without braces must be choosing one of those
>>> interpretations. Which one?
>>
>> If no diagnostic message is issued, the first one.
>
> How do you arrive at that conclusion?

Because if 'j' is part of the initializer for 'a[]' rather than a
separate declarator there is a syntax violation.

> If no diagnostic message is issued, the compiler is non-conforming.

Did you miss Alan Curry's comment?  The missing braces around {i}
is only undefined behavior, not a constraint violation, and there
is no syntax violation.

I should acknowledge that the UB here actually does grant
sufficient freedom to permit the second interpretation.  However,
any implementation that knowingly provides an extension to omit
the braces for array initializers would be rather perverse in
making that choice, going as does against the grain of the
syntactic analysis necessary to avoid a diagnostic.

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

#5230

Tim Rentsch <txr@alumni.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> writes:
>> Tim Rentsch <txr@alumni.caltech.edu> writes:
>>> pacman@kosh.dhis.org (Alan Curry) writes:
>> [...]
>>>> I also think it's a syntax error, but take a look at this more subtle case:
>>>>
>>>>   int i=1, j=2;
>>>>
>>>>   int main(void)
>>>>   {
>>>>     int a[] = i, j;
>>>>   }
>>>>
>>>> It's invalid because the array initializer doesn't have braces. But that's
>>>> not a requirement of the grammar. In n1256.pdf, the clause that it violates
>>>> is 6.7.8.16, under the heading of "Semantics", not "Constraints".
>>>>
>>>> And it can be made valid by putting braces around just the i, which makes a
>>>> single-element a[] and a local j shadowing the global j:
>>>>     int a[] = {i}, j;
>>>> or by putting braces around both, making a 2-element a[]:
>>>>     int a[] = {i, j};
>>>>
>>>> A compiler that accepts the form without braces must be choosing one of those
>>>> interpretations. Which one?
>>>
>>> If no diagnostic message is issued, the first one.
>>
>> How do you arrive at that conclusion?
>
> Because if 'j' is part of the initializer for 'a[]' rather than a
> separate declarator there is a syntax violation.
>
>> If no diagnostic message is issued, the compiler is non-conforming.
>
> Did you miss Alan Curry's comment?  The missing braces around {i}
> is only undefined behavior, not a constraint violation, and there
> is no syntax violation.

You're right.

And I think I see some sloppy wording in 6.7.8.16p13:

    The initializer for a structure or union object that has
    automatic storage duration shall be either an initializer list
    as described below, or a single expression that has compatible
    structure or union type. In the latter case, the initial value of
    the object, including unnamed members, is that of the expression.

But an initializer-list doesn't include the '{' and '}' delimiters.
For example, given
    struct foo obj = { 10, 20 };
the initializer-list is ``10, 20'', *not* ``{ 10, 20 }''.  p13 seems
to be referring to ``{ 10, 20 }'' as an "initializer list".

> I should acknowledge that the UB here actually does grant
> sufficient freedom to permit the second interpretation.  However,
> any implementation that knowingly provides an extension to omit
> the braces for array initializers would be rather perverse in
> making that choice, going as does against the grain of the
> syntactic analysis necessary to avoid a diagnostic.

Which makes me wonder why the standard didn't just make it a
constraint violation.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"

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

#5330

Keith Thompson <kst-u@mib.org> writes:

> Tim Rentsch <txr@alumni.caltech.edu> writes:
[snip]

>> I should acknowledge that the UB here actually does grant
>> sufficient freedom to permit the second interpretation.  However,
>> any implementation that knowingly provides an extension to omit
>> the braces for array initializers would be rather perverse in
>> making that choice, going as does against the grain of the
>> syntactic analysis necessary to avoid a diagnostic.
>
> Which makes me wonder why the standard didn't just make it a
> constraint violation.

Speculating:  to tolerate some pre-ANSI implementations
without forcing conforming implementations to have to
accept omitting the braces in such cases.  (There are
other plausible reasons but this one seems to me the
most probable.)

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

#5345

Le 03/06/11 03:10, Tim Rentsch a écrit :
> Keith Thompson<kst-u@mib.org>  writes:
>
>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
> [snip]
>
>>> I should acknowledge that the UB here actually does grant
>>> sufficient freedom to permit the second interpretation.  However,
>>> any implementation that knowingly provides an extension to omit
>>> the braces for array initializers would be rather perverse in
>>> making that choice, going as does against the grain of the
>>> syntactic analysis necessary to avoid a diagnostic.
>>
>> Which makes me wonder why the standard didn't just make it a
>> constraint violation.
>
> Speculating:  to tolerate some pre-ANSI implementations
> without forcing conforming implementations to have to
> accept omitting the braces in such cases.  (There are
> other plausible reasons but this one seems to me the
> most probable.)

The bug I had was just in the absence of a diagnostic...
The compiler assumed it had seen an opening brace and
everything worked up to the ";". Since it never saw
the opening brace, braces weren't unbalanced and it did
not complain either at the end of the construct.

This bug was introduced in the context of my efforts
to implement the C99 array initialization.

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

#5409

jacob navia <jacob@spamsink.net> writes:

> Le 03/06/11 03:10, Tim Rentsch a @C3{A9}crit :
>> Keith Thompson<kst-u@mib.org>  writes:
>>
>>> Tim Rentsch<txr@alumni.caltech.edu>  writes:
>> [snip]
>>
>>>> I should acknowledge that the UB here actually does grant
>>>> sufficient freedom to permit the second interpretation.  However,
>>>> any implementation that knowingly provides an extension to omit
>>>> the braces for array initializers would be rather perverse in
>>>> making that choice, going as does against the grain of the
>>>> syntactic analysis necessary to avoid a diagnostic.
>>>
>>> Which makes me wonder why the standard didn't just make it a
>>> constraint violation.
>>
>> Speculating:  to tolerate some pre-ANSI implementations
>> without forcing conforming implementations to have to
>> accept omitting the braces in such cases.  (There are
>> other plausible reasons but this one seems to me the
>> most probable.)
>
> The bug I had was just in the absence of a diagnostic...
> The compiler assumed it had seen an opening brace and
> everything worked up to the ";". Since it never saw
> the opening brace, braces weren't unbalanced and it did
> not complain either at the end of the construct.
>
> This bug was introduced in the context of my efforts
> to implement the C99 array initialization.

That seems strange since the earlier posted example
is a syntax error in both C99 and C90.

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

#5417

Le 04/06/11 04:37, Tim Rentsch a écrit :
>> This bug was introduced in the context of my efforts
>> to implement the C99 array initialization.
>
> That seems strange since the earlier posted example
> is a syntax error in both C99 and C90.

Yes, but I commented out the call to
	error("Missing opening brace");

Why did I do that in 2008?

I do not remember, but I was doing the C99 array initialization
stuff, and I may have commented out two lines instead of one,
who knows.

Some bugs are really difficult to figure out, mostly because you
just did NONSENSE you see?

:-)

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

#5160

On Tue, 31 May 2011 16:50:10 -0700, Keith Thompson wrote:

> Peter Nilsson <airia@acay.com.au> writes:
>>
>> Even if you claimed conformance, it's not required to. It
>> follows the context free grammar. The requirement of brace
>> enclosed aggregate initialisors is not within a constraint.
> 
> It's a syntax error.  An initializer is either an initializer-list
> enclosed in curly braces (possibly followed by a final comma),
> or an assignment-expression.  ``2.2, 4.2, 5.00'' is not an
> assignment-expression.

The comma operator is parsed right-to-left. The expression
``double a[] = 2.2, 4.2, 5.00'' contains three assignment-
expressions: ``5.00'', ``4.2'' and ``double a[] = 2.2''.

/Nisse

[toc] | [prev] | [standalone]

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

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

csiph-web