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 2 of 3 — ← Prev page 1 [2] 3  Next page →

#4954

On 05/29/11 10:45 AM, Angel wrote:
> On 2011-05-28, Ian Collins<ian-news@hotmail.com>  wrote:
>> On 05/29/11 10:28 AM, Angel wrote:
>>>
>>> The error means literally what it says, you initialized your array
>>> wrongly. An array initializer must be between accolades.
>>
>> accolades?
>>
>> I guess you aren't a native English speaker.  In English an accolade is
>> some form of award or praise!
>
> Dutch, actually. And here an accolade is one of those curly brace
> thingies you put around statement blocks and array initializers. :-)
>
> According to Wikipedia, it has that meaning in English too, but only in
> the context of muscial notation. :-)
>
> https://secure.wikimedia.org/wikipedia/en/wiki/Accolade_%28notation%29#Lines

Well well, we learn something new every day, don't we!

-- 
Ian Collins

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

#4957

On 2011-05-28, Ian Collins <ian-news@hotmail.com> wrote:
>>
>> According to Wikipedia, it has that meaning in English too, but only in
>> the context of muscial notation. :-)
>>
>> https://secure.wikimedia.org/wikipedia/en/wiki/Accolade_%28notation%29#Lines
>
> Well well, we learn something new every day, don't we!

Picking up hints to write better C code, improving my English and even 
learning something about sheet music. And to think some say Internet is
nothing but a waste of time. ^^


-- 
"C provides a programmer with more than enough rope to hang himself.
C++ provides a firing squad, blindfold and last cigarette."
- seen in comp.lang.c

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

#4966

On 2011-05-28, Angel <angel+news@spamcop.net> wrote:
> Picking up hints to write better C code, improving my English and even 
> learning something about sheet music. And to think some say Internet is
> nothing but a waste of time. ^^

You're right, sheet music is important.  :P

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#4974

On Sat, 28 May 2011 18:45:27 -0400, Angel <angel+news@spamcop.net> wrote:

> [...] here an accolade is one of those curly brace
> thingies you put around statement blocks and array initializers. :-)
>
> According to Wikipedia, it has that meaning in English too, but only in
> the context of muscial notation. :-)
>
> https://secure.wikimedia.org/wikipedia/en/wiki/Accolade_%28notation%29#Lines

As a native speaker of English, who has been reading music for more than
50 years, I've never encountered this usage of "accolade".


-- 
Morris Keesan -- mkeesan@post.harvard.edu

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

#4956

"Bill Cunningham" <nospam@nspam.invalid> writes:
>     I am trying here to calculate a mean of 3 values. I do not understand 
> the errors the compiler returned I've never seen them.
>
> #include <stdio.h>
>
> void mean(double *avg, int periods)
> {
>     double val;
>     val = *avg / periods;
>     printf("%.2f\n", val);
> }
>
> int main(void)
> {
>     double a[] = 2.2, 4.2, 5.00;
>     mean(a, 3);
> }
> p.c: In function `main':
> p.c:12: invalid initializer
> p.c:12: parse error before numeric constant
>
>     What's it trying to tell me?

That you need to consult whatever C reference you're using and re-read
the section that discusses the syntax of array initializers.

-- 
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]

#4960

"Bill Cunningham" <nospam@nspam.invalid> writes:

>     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
>
>     What's it trying to tell me?

Depending on how long you've been up, it's telling you that you need
either sleep or coffee.  :)

You need braces around the initializer list:

>     double a[] = {2.2, 4.2, 5.00};

-- 
"Erwin, do you know what happened to the cat?" -- Mrs. Shroedinger

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

#5015

Le 28/05/11 21:28, Bill Cunningham a écrit :
>      I am trying here to calculate a mean of 3 values. I do not understand
> the errors the compiler returned I've never seen them.
>
> #include<stdio.h>
>
> void mean(double *avg, int periods)
> {
>      double val;
>      val = *avg / periods;
>      printf("%.2f\n", val);
> }
>
> int main(void)
> {
>      double a[] = 2.2, 4.2, 5.00;
>      mean(a, 3);
> }
> p.c: In function `main':
> p.c:12: invalid initializer
> p.c:12: parse error before numeric constant
>
>      What's it trying to tell me?
>
> Bill
>
>
>

Thanks a lot Bill.

For unknown reasons (normally I ignore your threads) I typed your code
and compiled it with lcc-win.

NO ERRORS.

WHAT?

Yes, lcc-win issued NO ERRORS AT ALL.

After a lot of work I found that I introduced a bug by eliminating a 
call to "error" when after an equals sign in an array initialization
I do not find an opening brace.

Why did I do that?

Forgot, this bug is there since at least 3-4 years...

Well, thanks for your questions.

jacob

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

#5025

On Sun, 29 May 2011 19:30:18 +0200, jacob navia <jacob@spamsink.net>
wrote:

>Le 28/05/11 21:28, Bill Cunningham a écrit :
>>      I am trying here to calculate a mean of 3 values. I do not understand
>> the errors the compiler returned I've never seen them.
>>
>> #include<stdio.h>
>>
>> void mean(double *avg, int periods)
>> {
>>      double val;
>>      val = *avg / periods;
>>      printf("%.2f\n", val);
>> }
>>
>> int main(void)
>> {
>>      double a[] = 2.2, 4.2, 5.00;
>>      mean(a, 3);
>> }
>> p.c: In function `main':
>> p.c:12: invalid initializer
>> p.c:12: parse error before numeric constant
>>
>>      What's it trying to tell me?
>>
>> Bill
>>
>>
>>
>
>Thanks a lot Bill.
>
>For unknown reasons (normally I ignore your threads) I typed your code
>and compiled it with lcc-win.
>
>NO ERRORS.
>
>WHAT?
>
>Yes, lcc-win issued NO ERRORS AT ALL.
>
>After a lot of work I found that I introduced a bug by eliminating a 
>call to "error" when after an equals sign in an array initialization
>I do not find an opening brace.
>
>Why did I do that?
>
>Forgot, this bug is there since at least 3-4 years...
>
>Well, thanks for your questions.
>
>jacob


I think I just spotted someone who doesn't use regression tests and
who doesn't have a standard set of pass/fail tests for his compiler.

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

#5027

Geoff <geoff@invalid.invalid> writes:
> On Sun, 29 May 2011 19:30:18 +0200, jacob navia <jacob@spamsink.net>
> wrote:
>
>>Le 28/05/11 21:28, Bill Cunningham a écrit :
[...]
>>>      double a[] = 2.2, 4.2, 5.00;
[...]
>>
>>Thanks a lot Bill.
>>
>>For unknown reasons (normally I ignore your threads) I typed your code
>>and compiled it with lcc-win.
>>
>>NO ERRORS.
>>
>>WHAT?
>>
>>Yes, lcc-win issued NO ERRORS AT ALL.
>>
>>After a lot of work I found that I introduced a bug by eliminating a 
>>call to "error" when after an equals sign in an array initialization
>>I do not find an opening brace.
>>
>>Why did I do that?
>>
>>Forgot, this bug is there since at least 3-4 years...
>>
>>Well, thanks for your questions.
>
>
> I think I just spotted someone who doesn't use regression tests and
> who doesn't have a standard set of pass/fail tests for his compiler.

Or someone who didn't happen to have a regression test for that
particular case.

How big a regression test suite would you need to catch all possible C
coding errors?

-- 
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]

#5028

On Sun, 29 May 2011 18:50:42 -0700, Keith Thompson <kst-u@mib.org>
wrote:

>Geoff <geoff@invalid.invalid> writes:
>> On Sun, 29 May 2011 19:30:18 +0200, jacob navia <jacob@spamsink.net>
>> wrote:
>>
>>>Le 28/05/11 21:28, Bill Cunningham a écrit :
>[...]
>>>>      double a[] = 2.2, 4.2, 5.00;
>[...]
>>>
>>>Thanks a lot Bill.
>>>
>>>For unknown reasons (normally I ignore your threads) I typed your code
>>>and compiled it with lcc-win.
>>>
>>>NO ERRORS.
>>>
>>>WHAT?
>>>
>>>Yes, lcc-win issued NO ERRORS AT ALL.
>>>
>>>After a lot of work I found that I introduced a bug by eliminating a 
>>>call to "error" when after an equals sign in an array initialization
>>>I do not find an opening brace.
>>>
>>>Why did I do that?
>>>
>>>Forgot, this bug is there since at least 3-4 years...
>>>
>>>Well, thanks for your questions.
>>
>>
>> I think I just spotted someone who doesn't use regression tests and
>> who doesn't have a standard set of pass/fail tests for his compiler.
>
>Or someone who didn't happen to have a regression test for that
>particular case.
>
Interesting point. How long has the requirement for braces around
array initialization been in existence?

>How big a regression test suite would you need to catch all possible C
>coding errors?

As big as it takes to cover all cases for which your compiler emits
warnings or errors. 

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

#5030

On 2011-05-30, Geoff <geoff@invalid.invalid> wrote:
> On Sun, 29 May 2011 18:50:42 -0700, Keith Thompson <kst-u@mib.org>
> wrote:
>>How big a regression test suite would you need to catch all possible C
>>coding errors?

> As big as it takes to cover all cases for which your compiler emits
> warnings or errors. 

That wouldn't be enough.  You have to catch all possible circumstances
under which they could arise, such as "after every other possible thing
has happened" in case some prior event affects the outcome.

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#5031

On 30 May 2011 02:54:24 GMT, Seebs <usenet-nospam@seebs.net> wrote:

>On 2011-05-30, Geoff <geoff@invalid.invalid> wrote:
>> On Sun, 29 May 2011 18:50:42 -0700, Keith Thompson <kst-u@mib.org>
>> wrote:
>>>How big a regression test suite would you need to catch all possible C
>>>coding errors?
>
>> As big as it takes to cover all cases for which your compiler emits
>> warnings or errors. 
>
>That wouldn't be enough.  You have to catch all possible circumstances
>under which they could arise, such as "after every other possible thing
>has happened" in case some prior event affects the outcome.
>
>-s

No, you only have to invoke a case that violates the rule that
triggers the error condition you are trying to test. This would have
caught the removal of the error call in question. That a compiler can
emit no errors and still be wrong is not in question. It's the testing
for errors for which the compiler is designed or REQUIRED to emit a
diagnostic that must be confirmed. That a compiler can emit secondary
errors related to or caused by the first error was proven in the OP.

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

#5035

On 2011-05-30, Geoff <geoff@invalid.invalid> wrote:
> No, you only have to invoke a case that violates the rule that
> triggers the error condition you are trying to test.

I guess it depends on whether the problem is "this kind of error is never
caught no matter what" or only "there are circumstances where this error is
not caught".

-s
-- 
Copyright 2011, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
I am not speaking for my employer, although they do rent some of my opinions.

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

#5037

Le 30/05/11 03:14, Geoff a écrit :

>
> I think I just spotted someone who doesn't use regression tests and
> who doesn't have a standard set of pass/fail tests for his compiler.

Sure, YOUR regression tests catch everything, you never make mistakes
and when you do, your sophisticated tests catch them all.


Well you are the best, far better than me.

Happy?

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

#5075

On Mon, 30 May 2011 08:46:27 +0200, jacob navia <jacob@spamsink.net>
wrote:

>Le 30/05/11 03:14, Geoff a écrit :
>
>>
>> I think I just spotted someone who doesn't use regression tests and
>> who doesn't have a standard set of pass/fail tests for his compiler.
>
>Sure, YOUR regression tests catch everything, you never make mistakes
>and when you do, your sophisticated tests catch them all.
>

I never said my tests were perfect or sophisticated.

Far from it. All programs have bugs. All compilers and regression
tests are programs. Therefore all compilers and regression tests have
bugs. 

It is the purpose of regression testing to catch bugs that were
introduced since the last time the test was run against the
application under development. No regression is perfect but if it was
designed to catch an error it ought to catch the same error on a
subsequent run. Unless the specification changed, in which case you
would be modifying the application and the test, hopefully
independently and using different algorithms for calculations where
needed.

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

#5129

Geoff <geoff@invalid.invalid> writes:
> On Mon, 30 May 2011 08:46:27 +0200, jacob navia <jacob@spamsink.net>
> wrote:
>>Le 30/05/11 03:14, Geoff a écrit :
>>> I think I just spotted someone who doesn't use regression tests and
>>> who doesn't have a standard set of pass/fail tests for his compiler.
>>
>>Sure, YOUR regression tests catch everything, you never make mistakes
>>and when you do, your sophisticated tests catch them all.
>
> I never said my tests were perfect or sophisticated.
>
> Far from it. All programs have bugs. All compilers and regression
> tests are programs. Therefore all compilers and regression tests have
> bugs. 
>
> It is the purpose of regression testing to catch bugs that were
> introduced since the last time the test was run against the
> application under development. No regression is perfect but if it was
> designed to catch an error it ought to catch the same error on a
> subsequent run. Unless the specification changed, in which case you
> would be modifying the application and the test, hopefully
> independently and using different algorithms for calculations where
> needed.

Ok, he had a bug in his regression test suite.  Ideally, he should
have caught the particular error; he didn't.

It's absurd to conclude from that one data point that he "doesn't
use regression tests".

(I'm not sure why I'm defending jacob here; he's certainly not
going to appreciate it, and he'll probably accuse me of leading
the attack.)

-- 
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]

#5032

jacob navia <ja...@spamsink.net> wrote:
> Le 28/05/11 21:28, Bill Cunningham a é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. The requirement of brace
enclosed aggregate initialisors is not within a constraint.

> After a lot of work I found that I introduced a bug

QoI issue for sure, but I guess it just highlights that it isn't
a particularly common mistake made by programmers.

Still, might be interesting to see what lcc does in the case of:

  typedef int array_t[2];
  for (array_t a = 2, 0; a[0] < 4; a[0]++)
    puts("Hello");

--
Peter

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

#5036

Le 30/05/11 06:04, Peter Nilsson a écrit :
> jacob navia<ja...@spamsink.net>  wrote:
>> Le 28/05/11 21:28, Bill Cunningham a é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. The requirement of brace
> enclosed aggregate initialisors is not within a constraint.
>
>> After a lot of work I found that I introduced a bug
>
> QoI issue for sure, but I guess it just highlights that it isn't
> a particularly common mistake made by programmers.
>
> Still, might be interesting to see what lcc does in the case of:
>
>    typedef int array_t[2];
>    for (array_t a = 2, 0; a[0]<  4; a[0]++)
>      puts("Hello");
>
> --
> Peter
The code was correctly generated as if there was braces around the
expression...

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

#5092

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?

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

#5150

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?

-- 
Alan Curry

[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