char array initialization: Is 'char a[] = ("a")' valid ANSI C?

  • Thread starter Petter Reinholdtsen
  • Start date
P

Petter Reinholdtsen

Is the code fragment 'char a[] = ("a");' valid ANSI C? The
problematic part is '("a")'. I am sure 'char a[] = "a";' is valid
ANSI C, but I am more unsure if it is allowed to place () around the
string literal.
 
F

Flash Gordon

Is the code fragment 'char a[] = ("a");' valid ANSI C? The
problematic part is '("a")'. I am sure 'char a[] = "a";' is valid
ANSI C, but I am more unsure if it is allowed to place () around the
string literal.

Yes it is. I can't think of any situation where it is illegal to put
brackets around an expression.
 
C

Christopher Benson-Manica

Flash Gordon said:
Yes it is. I can't think of any situation where it is illegal to put
brackets around an expression.

Did you mean to say "parentheses"? "Brackets" are '[' and ']', at
least in the parlance I'm familiar with.

On second thought, dictionary.com says "bracket" can mean
"parenthesis" in British English. Is one or the other standard, or
are we at the mercy of dialect here as in many other areas?
 
K

Keith Thompson

Christopher Benson-Manica said:
Flash Gordon said:
Yes it is. I can't think of any situation where it is illegal to put
brackets around an expression.

Did you mean to say "parentheses"? "Brackets" are '[' and ']', at
least in the parlance I'm familiar with.

On second thought, dictionary.com says "bracket" can mean
"parenthesis" in British English. Is one or the other standard, or
are we at the mercy of dialect here as in many other areas?

In my personal dialect of English, the terms are (parentheses),
[brackets], and {braces}. Other dialects may differ. I think the
term "parentheses" is unambiguous, but if there's any doubt it's best
to refer to [square brackets] and {curly braces}. Better yet, use the
characters themselves.
 
E

Eric Sosman

Keith said:
Christopher Benson-Manica said:
Yes it is. I can't think of any situation where it is illegal to put
brackets around an expression.

Did you mean to say "parentheses"? "Brackets" are '[' and ']', at
least in the parlance I'm familiar with.

On second thought, dictionary.com says "bracket" can mean
"parenthesis" in British English. Is one or the other standard, or
are we at the mercy of dialect here as in many other areas?


In my personal dialect of English, the terms are (parentheses),
[brackets], and {braces}. Other dialects may differ. I think the
term "parentheses" is unambiguous, but if there's any doubt it's best
to refer to [square brackets] and {curly braces}. Better yet, use the
characters themselves.

To avoid trouble with international keyboards and
displays, write "the characters themselves" in the form
??(square brackets:> and <%curly braces??>.

;-)
 
F

Flash Gordon

Christopher Benson-Manica said:
Flash Gordon said:
Yes it is. I can't think of any situation where it is illegal to
put brackets around an expression.

Did you mean to say "parentheses"? "Brackets" are '[' and ']', at
least in the parlance I'm familiar with.

On second thought, dictionary.com says "bracket" can mean
"parenthesis" in British English. Is one or the other standard, or
are we at the mercy of dialect here as in many other areas?

In my personal dialect of English, the terms are (parentheses),
[brackets], and {braces}. Other dialects may differ. I think the
term "parentheses" is unambiguous, but if there's any doubt it's best
to refer to [square brackets] and {curly braces}. Better yet, use the
characters themselves.

Where I grew up (Hadleigh, Essex, England) brackets was the term used in
ordinary (as opposed to technical) English, parenthesis was only used in
maths classes.

I didn't particularly think about it in the above quote, or I would have
used parenthesis, but in any case as there was an example above I would
consider my post unambiguous.
 
P

pete

Keith said:
Christopher Benson-Manica said:
Flash Gordon said:
Yes it is.
I can't think of any situation where it is illegal to put
brackets around an expression.

Did you mean to say "parentheses"? "Brackets" are '[' and ']', at
least in the parlance I'm familiar with.

On second thought, dictionary.com says "bracket" can mean
"parenthesis" in British English. Is one or the other standard, or
are we at the mercy of dialect here as in many other areas?

In my personal dialect of English, the terms are (parentheses),
[brackets], and {braces}. Other dialects may differ. I think the
term "parentheses" is unambiguous, but if there's any doubt it's best
to refer to [square brackets] and {curly braces}. Better yet, use the
characters themselves.

N869
Index
( ) (parentheses punctuator), 6.7.5.3, 6.8.4, 6.8.5
[ ] (brackets punctuator), 6.7.5.2, 6.7.8
{ } (braces punctuator), 6.7.2.2, 6.7.2.3, 6.7.8, 6.8.2
 
P

Petter Reinholdtsen

[Flash Gordon]
Yes it is. I can't think of any situation where it is illegal to put
brackets around an expression.

I agree, but the authors of the HP aCC compiler and a bug reported
against GNU C compiler disagrees. See
<URL:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11250> for the GCC
bug report. I'm trying to find out if they are correct or not.

The HP aCC compiler reject the code with an error, and a future GCC
will issue a warning when using -pedantic.

I guess I need a good ANSI C lawyer. Anyone around?
 
K

Kevin Bracey

In message <[email protected]>
Flash Gordon said:
Is the code fragment 'char a[] = ("a");' valid ANSI C? The
problematic part is '("a")'. I am sure 'char a[] = "a";' is valid
ANSI C, but I am more unsure if it is allowed to place () around the
string literal.

Yes it is. I can't think of any situation where it is illegal to put
brackets around an expression.

The problem is that that string literal isn't going in the place of an
expression. I'm pretty certain that it's illegal for basically the same
reason that these all are:

#include ("header.h")

char a[] = ({1,2});

char *a = "He" ("llo");

char a[]; a = "Hello";

The initialiser has required to be a string literal, it's not an expression.
 
O

Old Wolf

Keith Thompson said:
Christopher Benson-Manica said:
Did you mean to say "parentheses"? "Brackets" are '[' and ']', at
least in the parlance I'm familiar with.

In my personal dialect of English, the terms are (parentheses),
[brackets], and {braces}. Other dialects may differ.

Mine has:
(brackets)
[square brackets]
{braces}
Sometimes 'curly braces' is used instead of braces.
'Parentheses' is used when you mean 'brackets' but want to
sound well-educated (or snooty).
 
E

Eric Sosman

Old said:
Keith Thompson said:
Christopher Benson-Manica said:
Did you mean to say "parentheses"? "Brackets" are '[' and ']', at
least in the parlance I'm familiar with.

In my personal dialect of English, the terms are (parentheses),
[brackets], and {braces}. Other dialects may differ.


Mine has:
(brackets)
[square brackets]
{braces}
Sometimes 'curly braces' is used instead of braces.
'Parentheses' is used when you mean 'brackets' but want to
sound well-educated (or snooty).

That last, I take it, is a brackettial remark?
 
M

Michael Wojcik

N869
Index
( ) (parentheses punctuator), 6.7.5.3, 6.8.4, 6.8.5
[ ] (brackets punctuator), 6.7.5.2, 6.7.8
{ } (braces punctuator), 6.7.2.2, 6.7.2.3, 6.7.8, 6.8.2

Furthermore, N869 never refers to parentheses as "brackets". It does
sometimes use "bracketed" in reference to what the index calls
"braces", as in "minimally bracketed" initializers, but never calls
those punctuators themselves "brackets". The brackets are also
referred to as "subscripting brackets" (6.5n61) and square brackets
(6.5.2#2).

So I think we can say that in the context of C, "()" are properly
called "parentheses", "{}" are braces, and "[]" are brackets, though
we acknowledge that these terms are not so fixed in English.

Of course, people used to different terms may occasionally employ
them accidentally in a C context, so it's useful to know that English
usage varies.
 
C

Chris Croughton

Keith Thompson said:
Christopher Benson-Manica said:
Did you mean to say "parentheses"? "Brackets" are '[' and ']', at
least in the parlance I'm familiar with.

In my personal dialect of English, the terms are (parentheses),
[brackets], and {braces}. Other dialects may differ.

Mine has:
(brackets)
[square brackets]
{braces}
Sometimes 'curly braces' is used instead of braces.
'Parentheses' is used when you mean 'brackets' but want to
sound well-educated (or snooty).

I sometimes use {curly brackets} or {squiggly brackets}. I read
'parentheses' as two words, "parent heses" (and "parent sheses" are the
ones at the other end), as in Lisp where the things produce offspring
given half a chance. And 'braces' are things you use to hold trousers
up (I'm British, 'suspenders' are women's underwear)...

I've also seen ( and ) (and sometimes the square ones) called 'bra' and
'ket', I believe that was once printer's parlance but I remember at
least one compiler which used those terms internally.

Chris C
 
M

Michael Wojcik

I agree, but the authors of the HP aCC compiler and a bug reported
against GNU C compiler disagrees. See
<URL:http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11250> for the GCC
bug report. I'm trying to find out if they are correct or not.

The HP aCC compiler reject the code with an error, and a future GCC
will issue a warning when using -pedantic.

I guess I need a good ANSI C lawyer. Anyone around?

ISO 9899-1990 6.5.7 ("Initialization") says "An array of character
type may be initialized by a character string literal, optionally
enclosed in braces". (As I and others have noted in other posts, the
C standard uses "braces" for the "{}" characters, and no others.)

That looks pretty clear. There's a special rule for initializing
arrays of character type with string literals or string literals
enclosed with braces. Not with expressions that evaluate to string
literals - string literals themselves. (Actually, I don't believe a
parenthesized string literal is an expression that evaluates to a
string literal - it decays to a pointer to its first element, doesn't
it? See below.)

Note that this is a special restriction added by the Semantics
section of 6.5.7. It doesn't follow from the Syntax section, which
gives:

initializer:
assignment-expression
{ initializer-list }
{ initializer-list , }

assignment-expression is specified in 6.3.16:

assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression

(That is, it's the syntax rule that describes "chaining" assignments
like "a = b = 0;".)

A conditional-expression can be a logical-OR-expression, which can be
a logical-AND-expression, and so on, until you get to primary-
expression, which includes parenthesized expressions and string
literals as separate productions:

primary-expression:
identifer
constant
string-literal
( expression )

Since expression can be an assignment-expression, though, a parenthe-
sized string literal is still a valid primary expression, according
to the grammar.

This is actually relatively common in the C standard - the phrase
structure grammar is much more liberal than what the language
actually permits, and much of the text is devoted to listing cases
where phrases allowed by the grammar as specified are not in fact
part of the language.

Curiously, it should be legal to write:

char *cp = ("foo");

even though

char s[] = ("foo");

is not. That's because the former is a normal scalar initializer;
the string literal decays into a pointer to its first element, and
the value of that pointer is assigned to cp. The latter is an
attempt to initialze an array of char with a pointer to char, so it
fails, just as

char *cp = ("foo");
char s[] = cp;

would.

--
Michael Wojcik (e-mail address removed)

She felt increasingly (vision or nightmare?) that, though people are
important, the relations between them are not, and that in particular
too much fuss has been made over marriage; centuries of carnal
embracement, yet man is no nearer to understanding man. -- E M Forster
 
O

Old Wolf

Chris Croughton said:
Old Wolf said:
Keith Thompson said:
In my personal dialect of English, the terms are (parentheses),
[brackets], and {braces}. Other dialects may differ.

Mine has:
(brackets)
[square brackets]
{braces}
Sometimes 'curly braces' is used instead of braces.
'Parentheses' is used when you mean 'brackets' but want to
sound well-educated (or snooty).

I sometimes use {curly brackets} or {squiggly brackets}. I read
'parentheses' as two words, "parent heses" (and "parent sheses" are the
ones at the other end), as in Lisp

Interesting, I've never heard the "th" in "parentheses"
pronounced as anything other than the alveolar fricative.

(When reading your post I was wondering how to best describe
that sound, and then you gave me the answer: the sound made
instead of "s" by someone who has a Lisp. :)

For me it is: pa-REN-the-seize (with "the" like
"thick" without the -ck).
 
J

J. J. Farrell

Petter Reinholdtsen said:
Is the code fragment 'char a[] = ("a");' valid ANSI C? The
problematic part is '("a")'. I am sure 'char a[] = "a";' is valid
ANSI C, but I am more unsure if it is allowed to place () around the
string literal.

This sort of initializer for a char array must be a character
string literal, optionally enclosed in braces. ("a") is an
expression of type <pointer to char>, and hence is not a valid
initializer.
 
C

Chris Croughton

Chris Croughton said:
Old Wolf said:
In my personal dialect of English, the terms are (parentheses),
[brackets], and {braces}. Other dialects may differ.

Mine has:
(brackets)
[square brackets]
{braces}
Sometimes 'curly braces' is used instead of braces.
'Parentheses' is used when you mean 'brackets' but want to
sound well-educated (or snooty).

I sometimes use {curly brackets} or {squiggly brackets}. I read
'parentheses' as two words, "parent heses" (and "parent sheses" are the
ones at the other end), as in Lisp

Interesting, I've never heard the "th" in "parentheses"
pronounced as anything other than the alveolar fricative.

Oh, I don't pronounce it as two words except in fun (like "cow orker"
for "coworker". But I read it and internalise it as two words, then
have to put them together to get the meaning. My natural language
parser is not very sophisticated, and frequently breaks on things I say
let alone input from other people (I got it cheap from a government
surplus store 48 years ago and can't get the memory to upgrade it)...

(I also use 'squiggle' for the bitwise 'not' sign...)
(When reading your post I was wondering how to best describe
that sound, and then you gave me the answer: the sound made
instead of "s" by someone who has a Lisp. :)

Nice one!
For me it is: pa-REN-the-seize (with "the" like
"thick" without the -ck).

Or "thin" without the "n". Yes, that's the normal pronunciation. But
since when have programmers been 'normal'? <g>

Chris C
 
L

Lawrence Kirby

Petter Reinholdtsen said:
Is the code fragment 'char a[] = ("a");' valid ANSI C? The
problematic part is '("a")'. I am sure 'char a[] = "a";' is valid
ANSI C, but I am more unsure if it is allowed to place () around the
string literal.

This sort of initializer for a char array must be a character
string literal, optionally enclosed in braces. ("a") is an
expression of type <pointer to char>, and hence is not a valid
initializer.

C99 6.5.1p5:

"A parenthesized expression is a primary expression. Its type and
value are identical to those of the unparenthesied expression. It
is an lvalue, a function designator, or a void expression if the
unparenthesized expression is, respectively, an lvalue, a function
designator, or a void expression."

So ("a") is an expression of type array of 2 char, and is an lvalue.
sizeof("a") evaluates to 2 on all conforminhg C implementations.

However ("a") is not a string literal although it does contain one. String
literals are tokens (and before that pp-tokens). I.e. something that looks
specifically like "...".

Lawrence
 
L

Lawrence Kirby

ISO 9899-1990 6.5.7 ("Initialization") says "An array of character
type may be initialized by a character string literal, optionally
enclosed in braces". (As I and others have noted in other posts, the
C standard uses "braces" for the "{}" characters, and no others.)

That looks pretty clear. There's a special rule for initializing
arrays of character type with string literals or string literals
enclosed with braces. Not with expressions that evaluate to string
literals - string literals themselves. (Actually, I don't believe a
parenthesized string literal is an expression that evaluates to a
string literal - it decays to a pointer to its first element, doesn't
it? See below.)

"An expression that evaluates to a string literal" doesn't make much
sense; a string literal is a token form, not the result of an
expression.

Overall ("foo") has type "array of 4 chars". It is an array lvalue and
its contents form a valid string but it isn't a string literal.

Note that this is a special restriction added by the Semantics
section of 6.5.7. It doesn't follow from the Syntax section, which
gives:

initializer:
assignment-expression
{ initializer-list }
{ initializer-list , }

assignment-expression is specified in 6.3.16:

assignment-expression:
conditional-expression
unary-expression assignment-operator assignment-expression

(That is, it's the syntax rule that describes "chaining" assignments
like "a = b = 0;".)

Using as assignment-expression rules out the use of the comma operator at
the top level, which is a good thing in a comma separated list.
assignment-expression is also used for function call arguments, presumably
for the same reason.
A conditional-expression can be a logical-OR-expression, which can be
a logical-AND-expression, and so on, until you get to primary-
expression, which includes parenthesized expressions and string
literals as separate productions:

primary-expression:
identifer
constant
string-literal
( expression )

Since expression can be an assignment-expression, though, a parenthe-
sized string literal is still a valid primary expression, according
to the grammar.

This is actually relatively common in the C standard - the phrase
structure grammar is much more liberal than what the language
actually permits, and much of the text is devoted to listing cases
where phrases allowed by the grammar as specified are not in fact
part of the language.

Curiously, it should be legal to write:

char *cp = ("foo");
yes.

even though

char s[] = ("foo");

is not.

Is this a constraint violation or undefined behaviour? Consider
that if the latter then there is no compiler bug above.
That's because the former is a normal scalar initializer;
the string literal decays into a pointer to its first element, and
the value of that pointer is assigned to cp. The latter is an
attempt to initialze an array of char with a pointer to char, so it
fails, just as

char *cp = ("foo");
char s[] = cp;

Is the following initialiser valid?

int a[] = { { 0 } }; /* 2 levels of braces */

Lawrence
 
M

Michael Wojcik

"An expression that evaluates to a string literal" doesn't make much
sense; a string literal is a token form, not the result of an
expression.

Thanks for the correction. How about "not with expressions that
contain a string literal and evaluate to an array of char or a
pointer to char"?
Curiously, it should be legal to write:

char *cp = ("foo");
yes.

even though

char s[] = ("foo");

is not.

Is this a constraint violation or undefined behaviour? Consider
that if the latter then there is no compiler bug above.

There might not be a failure of compliance, but that doesn't mean
there's no compiler bug. QoI issues can be bugs, too.
That's because the former is a normal scalar initializer;
the string literal decays into a pointer to its first element, and
the value of that pointer is assigned to cp. The latter is an
attempt to initialze an array of char with a pointer to char, so it
fails, just as

char *cp = ("foo");
char s[] = cp;

Is the following initialiser valid?

int a[] = { { 0 } }; /* 2 levels of braces */

It appears to be. The initializer for an aggregate can be a brace-
enclosed list of values (an initializer-list). That's the outer
braces. The list of values applies to the members of the aggregate,
so what we need inside the outer braces are initializers that are
allowed for "int". Since "[t]he initializer for a scalar shall be a
single expression, optionally enclosed in braces", the inner braces
shouldn't pose any problem. Am I missing something?

It's not clear to me what point you're making here, in reference to
the text of mine that you quoted (which looks a bit suspect to me on
second reading).
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,769
Messages
2,569,581
Members
45,056
Latest member
GlycogenSupporthealth

Latest Threads

Top