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

Discussion in 'C Programming' started by Petter Reinholdtsen, Nov 1, 2004.

  1. 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.
    Petter Reinholdtsen, Nov 1, 2004
    #1
    1. Advertising

  2. Petter Reinholdtsen

    Flash Gordon Guest

    On Mon, 01 Nov 2004 17:13:10 +0100
    Petter Reinholdtsen <> wrote:

    > 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.
    --
    Flash Gordon
    Sometimes I think shooting would be far too good for some people.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Nov 1, 2004
    #2
    1. Advertising

  3. Flash Gordon <> spoke thus:

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

    --
    Christopher Benson-Manica | I *should* know what I'm talking about - if I
    ataru(at)cyberspace.org | don't, I need to know. Flames welcome.
    Christopher Benson-Manica, Nov 1, 2004
    #3
  4. Christopher Benson-Manica <> writes:
    > Flash Gordon <> spoke thus:
    >
    >> 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.

    --
    Keith Thompson (The_Other_Keith) <http://www.ghoti.net/~kst>
    San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
    We must do something. This is something. Therefore, we must do this.
    Keith Thompson, Nov 1, 2004
    #4
  5. Petter Reinholdtsen

    Eric Sosman Guest

    Keith Thompson wrote:
    > Christopher Benson-Manica <> writes:
    >
    >>Flash Gordon <> spoke thus:
    >>
    >>
    >>>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??>.

    ;-)

    --
    Eric Sosman, Nov 1, 2004
    #5
  6. Petter Reinholdtsen

    Flash Gordon Guest

    On Mon, 01 Nov 2004 19:26:27 GMT
    Keith Thompson <> wrote:

    > Christopher Benson-Manica <> writes:
    > > Flash Gordon <> spoke thus:
    > >
    > >> 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.
    --
    Flash Gordon
    Sometimes I think shooting would be far too good for some people.
    Although my email address says spam, it is real and I read it.
    Flash Gordon, Nov 1, 2004
    #6
  7. Petter Reinholdtsen

    pete Guest

    Keith Thompson wrote:
    >
    > Christopher Benson-Manica <> writes:
    > > Flash Gordon <> spoke thus:
    > >
    > >> 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

    --
    pete
    pete, Nov 2, 2004
    #7
  8. [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?
    Petter Reinholdtsen, Nov 2, 2004
    #8
  9. Petter Reinholdtsen

    Kevin Bracey Guest

    In message <-gordon.me.uk>
    Flash Gordon <> wrote:

    > On Mon, 01 Nov 2004 17:13:10 +0100
    > Petter Reinholdtsen <> wrote:
    >
    > > 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.

    --
    Kevin Bracey, Principal Software Engineer
    Tematic Ltd Tel: +44 (0) 1223 503464
    182-190 Newmarket Road Fax: +44 (0) 1728 727430
    Cambridge, CB5 8HE, United Kingdom WWW: http://www.tematic.com/
    Kevin Bracey, Nov 2, 2004
    #9
  10. Petter Reinholdtsen

    Old Wolf Guest

    Keith Thompson <> wrote:
    > Christopher Benson-Manica <> writes:
    > >
    > > 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).
    Old Wolf, Nov 2, 2004
    #10
  11. Petter Reinholdtsen

    Eric Sosman Guest

    [OT] Re: char array initialization: Is 'char a[] = ("a")' valid ANSIC?

    Old Wolf wrote:
    > Keith Thompson <> wrote:
    >
    >>Christopher Benson-Manica <> writes:
    >>
    >>>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?

    --
    Eric Sosman, Nov 2, 2004
    #11
  12. In article <>, pete <> writes:
    > > Christopher Benson-Manica <> writes:
    > > >
    > > > 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?

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

    --
    Michael Wojcik

    If Mokona means for us to eat this, I, a gentle person, will become
    angry! -- Umi (CLAMP & unknown translator), _Magic Knight Rayearth_
    Michael Wojcik, Nov 2, 2004
    #12
  13. On 2 Nov 2004 12:35:46 -0800, Old Wolf
    <> wrote:

    > Keith Thompson <> wrote:
    >> Christopher Benson-Manica <> writes:
    >> >
    >> > 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
    Chris Croughton, Nov 3, 2004
    #13
  14. In article <>, Petter Reinholdtsen <> writes:
    >
    > 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

    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
    Michael Wojcik, Nov 3, 2004
    #14
  15. Petter Reinholdtsen

    Old Wolf Guest

    Chris Croughton <> wrote:
    > Old Wolf <> wrote:
    > > Keith Thompson <> wrote:
    > >>
    > >> 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).
    Old Wolf, Nov 3, 2004
    #15
  16. Petter Reinholdtsen <> wrote in message news:<>...
    > 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.
    J. J. Farrell, Nov 4, 2004
    #16
  17. On 3 Nov 2004 13:53:44 -0800, Old Wolf
    <> wrote:

    > Chris Croughton <> wrote:
    >> Old Wolf <> wrote:
    >> > Keith Thompson <> wrote:
    >> >>
    >> >> 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
    Chris Croughton, Nov 15, 2004
    #17
  18. On Wed, 03 Nov 2004 19:21:28 -0800, J. J. Farrell wrote:

    > Petter Reinholdtsen <> wrote in message news:<>...
    >> 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
    Lawrence Kirby, Nov 16, 2004
    #18
  19. On Wed, 03 Nov 2004 20:30:51 +0000, Michael Wojcik wrote:

    >
    > In article <>, Petter Reinholdtsen <> writes:
    >>
    >> 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.)


    "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
    Lawrence Kirby, Nov 16, 2004
    #19
  20. In article <>, Lawrence Kirby <> writes:
    > On Wed, 03 Nov 2004 20:30:51 +0000, Michael Wojcik wrote:
    > > In article <>, Petter Reinholdtsen <> writes:
    > >>
    > >> 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.

    > >
    > > 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".
    > >
    > > 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.

    >
    > "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).

    --
    Michael Wojcik

    A coding theorist is someone who doesn't think Alice is crazy. -- John Gordon
    Michael Wojcik, Nov 18, 2004
    #20
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. toton
    Replies:
    5
    Views:
    932
    Victor Bazarov
    Sep 28, 2006
  2. Replies:
    1
    Views:
    482
  3. Replies:
    11
    Views:
    1,067
    Keith Thompson
    Apr 28, 2008
  4. aaragon
    Replies:
    2
    Views:
    614
    James Kanze
    Nov 2, 2008
  5. Frank Iannarilli

    pre-ansi to ansi c++ conversion?

    Frank Iannarilli, Jul 21, 2009, in forum: C++
    Replies:
    2
    Views:
    410
Loading...

Share This Page