Hi all,
I found this line in a C file, but I cannot understand it!
what's the meaning of it?

cheers,
Mauro

In article <b1516126-cffd-4992-b12f-e188c34bfdfc@p69g2000hsa.googlegroups.com>,
mauro <mauro.australia@gmail.com> wrote:

>I found this line in a C file, but I cannot understand it!
>what's the meaning of it?

Are you sure it wasn't int i[3] = {10,10,10};
??
If it were then it would indicate that i was an array of 3 int
and that the initial values for the three locations were 10, 10,
and 10 (in that order.)
--
"Okay, buzzwords only. Two syllables, tops." -- Laurie Anderson

In article <fntnsi$oev$1@canopus.cc.umanitoba.ca>,
Walter Roberson <roberson@ibd.nrc-cnrc.gc.ca> wrote:
>In article <b1516126-cffd-4992-b12f-e188c34bfdfc@p69g2000hsa.googlegroups.com>,
>mauro <mauro.australia@gmail.com> wrote:

>>I found this line in a C file, but I cannot understand it!
>>what's the meaning of it?

>Are you sure it wasn't int i[3] = {10,10,10};

Or for that matter, int l[3] = {10,10,10};
which would be as described previously but for the variable l ?
(That is, lower-case L .)
--
'Roberson' is my family name; my given name is 'Walter'.

On Feb 1, 11:08 am, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
wrote:
> In article <fntnsi$oe...@canopus.cc.umanitoba.ca>,

> >Are you sure it wasn't int i[3] = {10,10,10};
>
> Or for that matter, int l[3] = {10,10,10};

no, no, it is "1" (one)!
Really the first time I see such a declaration.

On Feb 1, 2:22 am, major <oce...@despammed.com> wrote:
> On Feb 1, 11:08 am, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
> wrote:
>
> > In article <fntnsi$oe...@canopus.cc.umanitoba.ca>,
> > >Are you sure it wasn't int i[3] = {10,10,10};
>
> > Or for that matter, int l[3] = {10,10,10};
>
> no, no, it is "1" (one)!
> Really the first time I see such a declaration.

then it's incorrect, and perhaps a typo, or someone is trying to
confuse you.
This won't compile under any compiler and it's not valid under any C
standard.

mauro wrote:
> I found this line in a C file, but I cannot understand it!
> what's the meaning of it?

"this" being the subject of the post, namely:
int 1[3] = {10, 10, 10};


Can you post a bit of the surrounding code?
Maybe that was in something like


#ifdef DO_NOT_DEFINE_ME
int 1[3] = {10, 10, 10};
if (1[0]+10 == 20) puts("My compiler ignores '[' and ']'.");
#endif

In article <59b6aa02-0c02-475e-9c95-82387584e960@l1g2000hsa.googlegroups.com>,
<vippstar@gmail.com> wrote:
>On Feb 1, 2:22 am, major <oce...@despammed.com> wrote:
>> On Feb 1, 11:08 am, rober...@ibd.nrc-cnrc.gc.ca (Walter Roberson)
>> wrote:
>>
>> > In article <fntnsi$oe...@canopus.cc.umanitoba.ca>,
>> > >Are you sure it wasn't int i[3] = {10,10,10};
>>
>> > Or for that matter, int l[3] = {10,10,10};
>>
>> no, no, it is "1" (one)!
>> Really the first time I see such a declaration.

>then it's incorrect, and perhaps a typo, or someone is trying to
>confuse you.
>This won't compile under any compiler and it's not valid under any C
>standard.

Predicting what "any compiler" will do is a fools game.

Compilers are permitted to offer extensions provided that the
meaning of valid C programs is not changed. A compiler could,
if it choose, define
int 1[3] = {10,10,10};
as meaning that the values 10, 10, and 10 are to be stored starting at
absolute (virtual) address 0x1 . Or starting at absolute virtual address
0x0 + 1 * sizeof(int) .

But more likely is that the original poster misread a
lower-case-L in a bad font, or that the code is in a comment
or in an #if section that was not true on the developer's system.
My absolute virtual address musings do not seem -likely- to
ever be implemented... but ya never know.
--
"Any sufficiently advanced bug is indistinguishable from a feature."
-- Rich Kulawiec

mauro <mauro.australia@gmail.com> writes:
> I found this line in a C file, but I cannot understand it!
> what's the meaning of it?

Please include context in the body of your article, not just the
subject line. The line in question is:

int 1[3] = {10,10,10};

As others have said, the above line is not valid C; any C compiler
must issue a diagnostic (probably something like "parse error" or
"syntax error") if it processes that line in a C source file.

Can you copy-and-paste the actual line from the C file, *without*
re-typing it? Better yet, can you post a complete compilable program
that includes that line? Preferably something not too long; trim it
down to the minimum that still compiles. (Actually, a single
declaration is a valid translation unit.)

The most likely explanation is that you've mis-read something like

int l[3] = {10,10,10};

You've said that it really is the number '1', not the letter 'l', but
we can't be sure of that.

Another plausible explanation is that it's an error, and that the code
doesn't actually compile.

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

In article <878x259yx5.fsf@kvetch.smov.org>,
Keith Thompson <kst-u@mib.org> wrote:

>int 1[3] = {10,10,10};

>As others have said, the above line is not valid C; any C compiler
>must issue a diagnostic (probably something like "parse error" or
>"syntax error") if it processes that line in a C source file.

Is there a specific constraint that it violates that would
rule out the "compilers may implement extensions that do not
change the meaning of any valid C program" generality?

Yes, it is not valid syntax in standard C, but it does not,
for example, violate the constraint that the array size given
must be a positive integer constant. I don't believe there is
any specific constraint against introducing new syntax.
--
"Is there any thing whereof it may be said, See, this is new? It hath
been already of old time, which was before us." -- Ecclesiastes

roberson@ibd.nrc-cnrc.gc.ca (Walter Roberson) writes:
> In article <878x259yx5.fsf@kvetch.smov.org>,
> Keith Thompson <kst-u@mib.org> wrote:
>
>>int 1[3] = {10,10,10};
>
>>As others have said, the above line is not valid C; any C compiler
>>must issue a diagnostic (probably something like "parse error" or
>>"syntax error") if it processes that line in a C source file.
>
> Is there a specific constraint that it violates that would
> rule out the "compilers may implement extensions that do not
> change the meaning of any valid C program" generality?
>
> Yes, it is not valid syntax in standard C, but it does not,
> for example, violate the constraint that the array size given
> must be a positive integer constant. I don't believe there is
> any specific constraint against introducing new syntax.

There doesn't have to be a constraint; it's enough that it's a syntax
error. C99 5.1.1.3:

A conforming implementation shall produce at least one diagnostic
message (identified in an implementation-defined manner) if a
preprocessing translation unit or translation unit contains a
violation of any syntax rule or constraint, even if the behavior
is also explicitly specified as undefined or
implementation-defined.

There's no exception to this requirement for extensions; if an
implementation allows the line in question as part of an extension, it
still must issue the required diagnostic, at least in conforming mode.
(In a non-conforming mode, of course, the standard cannot impose any
requirements whatsoever.)

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