By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
446,421 Members | 1,127 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 446,421 IT Pros & Developers. It's quick & easy.

a question on array

P: n/a
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 '05 #1
Share this Question
Share on Google+
6 Replies


P: n/a

ju**********@yahoo.co.in 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.

Dec 8 '05 #2

P: n/a
In article <11*********************@g49g2000cwa.googlegroups. com>,
ju**********@yahoo.co.in <ju**********@yahoo.co.in> 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 (4039.22'N, 11150.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.
Dec 8 '05 #3

P: n/a
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.
Dec 8 '05 #4

P: n/a
On 7 Dec 2005 22:05:19 -0800, in comp.lang.c ,
"ju**********@yahoo.co.in" <ju**********@yahoo.co.in> 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 =----
Dec 8 '05 #5

P: n/a
Mark McIntyre <ma**********@spamcop.net> 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) ks***@mib.org <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.
Dec 8 '05 #6

P: n/a
Keith Thompson wrote:

Mark McIntyre <ma**********@spamcop.net> 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
Dec 8 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.