a question on array

Discussion in 'C Programming' started by junky_fellow@yahoo.co.in, Dec 8, 2005.

  1. Guest

    Hi all,

    Consider a piece of code:

    char arr[10];
    char *ptr;

    arr = ptr; <----- On compilation, I get an error for this
    line.

    My question is this, does the compilation fails because
    1) arr is not a modifiable lvalue,
    or
    2) because of conversion rule, that says that "arr" is converted to
    pointer to
    char and is not an lvalue ?

    Thanx in advance for any help ...
    , Dec 8, 2005
    #1
    1. Advertising

  2. Saif Guest

    wrote:
    > Hi all,
    >
    > Consider a piece of code:
    >
    > char arr[10];
    > char *ptr;
    >
    > arr = ptr; <----- On compilation, I get an error for this
    > line.
    >
    > My question is this, does the compilation fails because
    > 1) arr is not a modifiable lvalue,
    > or
    > 2) because of conversion rule, that says that "arr" is converted to
    > pointer to
    > char and is not an lvalue ?
    >

    Array name is never a modifiable lvalue.
    Saif, Dec 8, 2005
    #2
    1. Advertising

  3. Chris Torek Guest

    In article <>,
    <> wrote:
    [given]
    > char arr[10];
    > char *ptr;
    > arr = ptr;
    >... does the compilation fail because
    >1) arr is not a modifiable lvalue,
    >or
    >2) because of conversion rule, that says that "arr" is converted to
    >pointer to
    >char and is not an lvalue ?


    The code fragment above (when converted to a complete translation
    unit) produces a diagnostic from any conformant compiler. The
    diagnostic is required by the C standard. The clauses in the
    C standard that requires this essentially boil down to the first
    reason, that "arr" is not a "modifiable lvalue". In that sense,
    we could say that the "compilation fails" because of reason 1.

    However, the C Standard never requires compilation to fail at all.
    It only requires "at least one diagnostic" if the translation unit
    violates a constraint (as in this case). So this is *not* the
    reason the compilation fails after all. The compilation fails
    because the compiler-writer chose to have that particular diagnostic
    *also* suppress compilation.

    Moreover, the C standard merely requires *a* diagnostic. If the
    compiler manages to come up with a diagnostic, even through some
    arguably "wrong" method, this satisfies the requirements in the C
    standard.

    Imagine for a moment, that the compiler works via divine miracles
    and inspiration. That is, there is no code, and not even a computer,
    involved in compiling. You simply copy the program onto a floppy,
    put the floppy on an altar, pray, and when you remove the floppy
    and put it back into a computer later, you now have any executable
    that may have been miraculously conceived.

    This particular translation unit, when prayed, produces an ominous
    thunderclap. This is the method by which a diagnostic is delivered
    from this compiler.

    Did the God or gods in question cause the thunderclap for the "right
    reason" as per the C standard, or did they not really understand
    (or perhaps care) *why* a diagnostic was required, yet produce a
    thunderclap anwyay? How will you tell?

    Returning to reality (as it were), suppose a compiler applied the
    idea given in reason 2, converting the (non-modifiable) lvalue
    "arr" to an rvalue, and then emit the diagnostic because the left
    hand side of the assignment had an rvalue (rather than a non-modifiable
    lvalue). The diagnostic came out, as required by the C standard.
    How will you tell whether the diagnostic came out because of the
    "wrong" reason (reason 2) instead of the "right" one (reason 1)?
    If the diagnostic consists only of a beep -- the computer's equivalent
    of the thunderclap -- you cannot even guess whether the compiler-writer
    wrote:

    diagnostic("non-modifiable lvalue as LHS of = operator");

    or:

    diagnostic("rvalue as LHS of = operator");

    since the string itself never comes out, only the beep. (If the
    string given as the argument here comes out, you *can* guess. But
    then you do not know whether the programmer was malicious, either
    -- suppose the compiler contains code like this:

    if (!assignment_compatible(lhs, rhs))
    /* C standard only requires a diagnostic, not a sensible one */
    diagnostic("invalid operand to sizeof");

    or, for subtraction:

    if (is_ptr(arg1)) {
    if (is_integer(arg2)) {
    /* ptr - integer: result has same type as arg1 */
    result_type = arg1_type;
    ...
    } else {
    /* only other value you can subtract from a pointer is another
    pointer of compatible type */
    if (!is_ptr(arg2) || !types_compatible(arg1_type, arg2_type))
    diagnostic("did anyone ever tell you your nose is green?");
    /* ptr - ptr: result is ptrdiff_t */
    result_type = ptrdiff_type;
    ...
    }
    } else ...

    just to cause weird error messages?)
    --
    In-Real-Life: Chris Torek, Wind River Systems
    Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
    email: forget about it http://web.torek.net/torek/index.html
    Reading email is like searching for food in the garbage, thanks to spammers.
    Chris Torek, Dec 8, 2005
    #3
  4. Skarmander Guest

    Chris Torek wrote:
    <snip>
    > Imagine for a moment, that the compiler works via divine miracles
    > and inspiration.


    I've known a few compilers for which this appears pretty accurate.

    > That is, there is no code, and not even a computer, involved in
    > compiling. You simply copy the program onto a floppy, put the floppy on
    > an altar, pray, and when you remove the floppy and put it back into a
    > computer later, you now have any executable that may have been
    > miraculously conceived.
    >

    Ah. Batch processing.

    > This particular translation unit, when prayed, produces an ominous
    > thunderclap. This is the method by which a diagnostic is delivered from
    > this compiler.
    >

    While that complies with the letter of the standard, it clearly violates the
    spirit: "The intent is that an implementation should identify the nature of,
    and where possible localize, each violation." A thunderclap alone arguably
    does not meet these reasonable constraints.

    > Did the God or gods in question cause the thunderclap for the "right
    > reason" as per the C standard, or did they not really understand
    > (or perhaps care) *why* a diagnostic was required, yet produce a
    > thunderclap anwyay? How will you tell?
    >

    "Of course, an implementation is free to produce any number of diagnostics
    as long as a valid program is still correctly translated." As many
    thunderclaps as desired may be produced, but at least those that are
    produced in response to a standards violation ought to come with some
    detail. Still, this is a QoI issue, and it is not wise to argue with the gods.

    S.
    Skarmander, Dec 8, 2005
    #4
  5. On 7 Dec 2005 22:05:19 -0800, in comp.lang.c ,
    "" <> wrote:

    >Hi all,
    >
    > Consider a piece of code:
    >
    > char arr[10];
    > char *ptr;
    >
    > arr = ptr; <----- On compilation, I get an error for this


    you can't assign to an array.

    >My question is this, does the compilation fails because
    >1) arr is not a modifiable lvalue,


    yes.

    >2) because of conversion rule, that says that "arr" is converted to
    >pointer to char and is not an lvalue ?


    No.

    An array is converted to a pointer to its first element in a small
    number of highly specific cases, vis when its an argument to a
    function.

    ----== Posted via Newsfeeds.Com - Unlimited-Unrestricted-Secure Usenet News==----
    http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
    ----= East and West-Coast Server Farms - Total Privacy via Encryption =----
    Mark McIntyre, Dec 8, 2005
    #5
  6. Mark McIntyre <> writes:
    [...]
    > An array is converted to a pointer to its first element in a small
    > number of highly specific cases, vis when its an argument to a
    > function.


    An expression of array type is converted to a (non-lvalue) pointer to
    its first element in all contexts other than an operand of unary "&"
    or "sizeof", or a string literal in an initializer.

    I wouldn't call that "a small number of highly specific cases".

    --
    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, Dec 8, 2005
    #6
  7. pete Guest

    Keith Thompson wrote:
    >
    > Mark McIntyre <> writes:
    > [...]
    > > An array is converted to a pointer to its first element in a small
    > > number of highly specific cases, vis when its an argument to a
    > > function.

    >
    > An expression of array type is converted to a (non-lvalue) pointer to
    > its first element in all contexts other than an operand of unary "&"
    > or "sizeof", or a string literal in an initializer.
    >
    > I wouldn't call that "a small number of highly specific cases".


    I would call that "always except in 3 highly specific cases".

    --
    pete
    pete, Dec 8, 2005
    #7
    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. Joseph Turian
    Replies:
    11
    Views:
    503
    Joseph Turian
    Jan 19, 2005
  2. Fabio
    Replies:
    0
    Views:
    300
    Fabio
    Nov 5, 2008
  3. Mara Guida

    const and array of array (of array ...)

    Mara Guida, Sep 2, 2009, in forum: C Programming
    Replies:
    3
    Views:
    472
    David RF
    Sep 3, 2009
  4. Tom
    Replies:
    3
    Views:
    197
    salsablr
    Dec 20, 2004
  5. Tuan  Bui
    Replies:
    14
    Views:
    461
    it_says_BALLS_on_your forehead
    Jul 29, 2005
Loading...

Share This Page