Array of Integers ?

[Ben Bacarisse]

On 11/08/2011 04:45 PM, Ben Bacarisse wrote:
...

This is unlike the behaviour of many other types in C. Given

int i = 42;
struct point { int x, y; } p = { 1, 2 };
int ia[5] = { 1, 2, 3, 4, 5 };

the expression 'i' denotes the value of i, and the expression 'p'
denotes the value of p. You can't do this with an array. The
expression 'ia' does not denote the array named ia -- it is an
expression of type pointer to int.

It's a moot point whether the sub-expression 'ia' denotes the array in
the expression 'sizeof ia'. I'd go with "no" since the sub-expression
is not evaluated.

How about in &ia?

Well, it isn't a value, so it can't be an array value. Unadorned, the
term "value" does not include lvalues (see footnote 53 of 6.3.2.1 p1).

C does have lvalues of array types, but these are not some special kind
of value. In C, the "l" in "lvalue" is not a modifier. lvalues are
*expressions* and they get evaluated -- they are not themselves the
result of an evaluation (again, see 6.3.2.1 p1).

 

[Ben Bacarisse]

What about the following...

http://67.40.109.61/torek/c/expr.html

And I quote..

"Array objects have a special, fundamental rule in C. This rule is
essentially arbitrary, and simply must be memorized. It falls out
from a key fact: C does not have array values. (There is one
exception to this, which I will save for later.) C does have array
objects -- just the values are missing. For instance, int a[5];
declares an ordinary array containing five ints. Logically, the
‘value’ of this array ought to be the five int values stored in that
array -- but it is not. Instead, the ‘value’ of the array is a
pointer to the first element of that array. "

The point being that, if I understand correctly, C does not have
'array of integers'. Instead, at least according to the former
comp.lang.c regular on here, the language has 'array objects'.

I find the quoted text misleading at best.

C does have array values; it just doesn't let you manipulate them
directly in most cases. The standard's definition of the word
"value" (C99 3.17) is "precise meaning of the contents of an object
when interpreted as having a speciï¬c type". Nothing in that
definition excludes arrays.

That definition is effectively useless. Functions, for example, are
said to return values. What object is being interpreted to get the
value returned by afunction? In the expression '1 + 1.0' something (it
is a value?) of type int is converted to a value of type double by the
usual arithmetic conversions, but there are no objects involved here.
The same goes for (int)1.0.

Some operators seem to try hard to avoid talking about values. For
example, '1 + 2' has a result but not a value. Others talk about "the
value of the result", further complicating matters.

Given:

int arr[5];

the value of arr consists of the values of its 5 elements,
interpreted as having type "int[5]". When you store something
into an array object, that object has a value, and that value is
an array value.

I disagree, though I expect to regret it! The footnote on 6.3.2.1 p1
seems to make it clear that the unqualified term "value" means what
other languages call an rvalue and 'arr' is not one of those.

The relevant rule (stated in C99 6.3.2.1p3) is that an expression
of array type is implicitly converted to a (non-lvalue) pointer to
the array object's first element -- *unless* the array expression
is the operand of a unary "&" (address-of) or of "sizeof", or is
a string literal in an initializer used to initialize an array;
in those cases, an array expression really is an array expression.

Note that when we refer to "an array", we generally mean "an object
of array type", or equivalently "an array object".

arr, as defined above is an array object (of type int[5]). Like any
array object, it is an array of objects (those objects happen to
be of type int). More precisely, it's an array of integers (an
array of longs, or of chars, would also be an array of integers).
Even more precisely, it's an array of ints.

The sub-expression 'arr' is an lvalue. I.e. it is an kind of
/expression/, not a particular kind of /value/. When used on its own,
this lvalue, this expression, is converted to a pointer to the array.
At no point is there a value (read rvalue) in existence; the expression
is converted, not its value.

In the case of '&arr', the lvalue expression is, of course, not
converted. Section 6.3.2.1 p1 says that when an lvalue is evaluated it
simply "designates an object". Given 'int x;', the expression '&x' does
not, at any stage, involve a value of type "int object". The
sub-expression 'x' simply designates an int object and it is this object
whose address is taken. The same is true of '&arr'. There is no value
of array type involved at any stage.

I think the use of the term "designate" both in 6.3.2.1 p1 and in the
description of the & operator is deliberate and significant. It means
that lvalue expressions of array type never need to be said to have a
value.

 

[Keith Thompson]

What about the following...

http://67.40.109.61/torek/c/expr.html

And I quote..

"Array objects have a special, fundamental rule in C. This rule is
essentially arbitrary, and simply must be memorized. It falls out
from a key fact: C does not have array values. (There is one
exception to this, which I will save for later.) C does have array
objects -- just the values are missing. For instance, int a[5];
declares an ordinary array containing five ints. Logically, the
‘value’ of this array ought to be the five int values stored in that
array -- but it is not. Instead, the ‘value’ of the array is a
pointer to the first element of that array. "

The point being that, if I understand correctly, C does not have
'array of integers'. Instead, at least according to the former
comp.lang.c regular on here, the language has 'array objects'.

I find the quoted text misleading at best.

C does have array values; it just doesn't let you manipulate them
directly in most cases. The standard's definition of the word
"value" (C99 3.17) is "precise meaning of the contents of an object
when interpreted as having a specific type". Nothing in that
definition excludes arrays.

That definition is effectively useless. Functions, for example, are
said to return values. What object is being interpreted to get the
value returned by afunction? In the expression '1 + 1.0' something (it
is a value?) of type int is converted to a value of type double by the
usual arithmetic conversions, but there are no objects involved here.
The same goes for (int)1.0.

The problem with the definition is that it's incomplete (like a
number of other definitions in the standard). What it describes
is certainly an *example* of a value, but surely the evaluation of
an expression also results in a *value*. Indeed the definition of
"expression" (6.5p1) is "a sequence of operators and operands that
speciï¬es computation of a value, or that designates an object
or a function, or that generates side effects, or that performs a
combination thereof". (Which, taken literally, implies that 42 isn't
an expression, since it contains neither operators nor operands.)

But what I conclude from that definition is that any object with
valid contents has a "value", which is the meaning of its contents
when interpreted as having a specific type.

Some operators seem to try hard to avoid talking about values. For
example, '1 + 2' has a result but not a value. Others talk about "the
value of the result", further complicating matters.

Given:

int arr[5];

the value of arr consists of the values of its 5 elements,
interpreted as having type "int[5]". When you store something
into an array object, that object has a value, and that value is
an array value.

I disagree, though I expect to regret it! The footnote on 6.3.2.1 p1
seems to make it clear that the unqualified term "value" means what
other languages call an rvalue and 'arr' is not one of those.

The footnote says:

What is sometimes called "rvalue" is in this International
Standard described as the "value of an expression".

That's not the unqualified term; it's the value *of an expression*.

The only consistent interpretation I can come up with is:

The Standard's definition of "value" is incomplete.

Any object in which something valid has been stored (handwaving meant to
exclude trap representations and perhaps indeterminate values) has a
"value", which is the "precise meaning of the contents of an object
when interpreted as having a specific type".

Any expression which (a) is not of function type, (b) is not an
lvalue, and (c) is not of void type yields a *value* when it's
evaluated. This is not covered by the definition of "value" in 3.17,
but it is covered by the definition of "expression" in 6.5p1.

6.3.2.1p2 ties these together:

Except when it is the operand of the sizeof operator, the unary &
operator, the ++ operator, the -- operator, or the left operand
of the . operator or an assignment operator, an lvalue that does
not have array type is converted to the value stored in the
designated object (and is no longer an lvalue). If the lvalue
has qualiï¬ed type, the value has the unqualiï¬ed version of
the type of the lvalue; otherwise, the value has the type of
the lvalue. If the lvalue has an incomplete type and does not
have array type, the behavior is undefined.

This says that evaluating the name of an object yields the value of
the object (and likewise for more complex lvalues). You can't get
the value of an array object by evaluating its name. That doesn't,
IMHO, imply that the array object doesn't have a value, and in fact
the incomplete definition of "value" in 3.17 implies that an array
object *does* have a value.

I'd be happier if the standard stated this more directly.

[...]

The sub-expression 'arr' is an lvalue. I.e. it is an kind of
/expression/, not a particular kind of /value/. When used on its own,
this lvalue, this expression, is converted to a pointer to the array.
At no point is there a value (read rvalue) in existence; the expression
is converted, not its value.

Array values do not show up during expression evaluation. But (I
argue) they do exist in array objects.

[...]

I think the use of the term "designate" both in 6.3.2.1 p1 and in the
description of the & operator is deliberate and significant. It means
that lvalue expressions of array type never need to be said to have a
value.

I agree with that.

 

[Ben Bacarisse]

The standard says
"An initializer specifies the initial value stored in an object."

Which leads me to believe
that an initializer for an array,
specifies the initial value stored in the array.

Does that mean that it *is* an array value? Maybe. I get the feeling
that wording like "specifies" and "designates" are deliberately
non-specific.

Initialisers specify values in some very indirect ways. {0} can specify
the initial value of any object (at least I can't think of an exception)
so it's rather unnatural to think of these things as denoting values of
some type or other.

 

[Keith Thompson]

Does that mean that it *is* an array value? Maybe. I get the feeling
that wording like "specifies" and "designates" are deliberately
non-specific.

No, an initializer is a syntactic construct that appears in source
code, while a value is something that exists in a running program.
It "specifies" that value in the sense that it tells the compiler
to generate code that will create that value when the program
is executed.

Initialisers specify values in some very indirect ways. {0} can specify
the initial value of any object (at least I can't think of an exception)
so it's rather unnatural to think of these things as denoting values of
some type or other.

Given:

int arr[5] = { 0 };

the initializer "{ 0 }" specifies the initial value of arr. This is
a value of type int[5], consisting of 5 values of type int, all 0.

The value that an initializer specifies can be determined only
in context. Given that context, the value that it specifies is
unambiguous.

 

[Ben Bacarisse]

It doesn't matter whether the verb is "specify" or "designates".
The point is that the thing being either specified or designated,
is the value being stored in the array.
The point is that the array has a value stored in it.

Okay, okay, I give in! C has array values.

Now, what does that tell us about C? Nothing useful, because we can't
compute with the values like we can with, say, struct values. In fact
these values can never appear during the execution of a program -- they
can't be "denoted" (to borrow a phrase from a related field). The now
indisputable existence of array values is, for me, and accident of
wording, not a fundamental property of the language like the existence
of int values.

 

[Stefan Ram]

Correction: The behavior of a program that attempts to modify a
string literal is undefined.

A string literal is part of the source code.

The source code usually is not there when a program is running.

So what would be an attempt to modify a string literal?

#include <stdio.h>

int main( void ){ puts( "Modify a string literal!" ); }

Now, when someone reads this, he must go and modify a string
literal in some source code.

 

[Keith Thompson]

A string literal is part of the source code.

The source code usually is not there when a program is running.

[...]

Yes, I was using a verbal shorthand. (And I've made enough similar
criticisms that it's a fair point.)

A string literal in source code corresponds to an array with static
storage duration that exists during program execution (C99 6.4.5).
The behavior of a program that attempts to modify that array is
undefined.

An example:

"hello"[0] = 'H';

A more realistic example:

void foo(char *s) { s[0] = 'h'; }
...
foo("hello");

 

[Phil Carmody]

No, that quote says that C has no array values, not that it has no
arrays.

If an argument is being pinned on the implication of the word "value",
then where is the normative definition of "value"? A quick grep shows
it's not in n869, for example.

Phil

 

[Keith Thompson]

If an argument is being pinned on the implication of the word "value",
then where is the normative definition of "value"? A quick grep shows
it's not in n869, for example.

C99 3.17: "precise meaning of the contents of an object when
interpreted as having a speciï¬c type".

As I discussed elsethread, this is an incomplete definitions;
it's clear that expressions can also yield values.

 

[Phil Carmody]

C99 3.17: "precise meaning of the contents of an object when
interpreted as having a speciÞc type".

As I discussed elsethread, this is an incomplete definitions;
it's clear that expressions can also yield values.

Ah, yes, that will teach me to grep, rather than pulling up a GUI pdf viewer. Many thanks.

Compound literals can be arrays and have values too, I'm surprised nobody's used them
as an example yet.

Phil

 

[Ben Bacarisse]

Compound literals can be arrays and have values too, I'm surprised
nobody's used them as an example yet.

They have an array value only the literal sense that, being arrays and
containing bits, they can be said to have a value (as per 3.17). A
compound literal like

(int [3]){1,2,3}

is an lvalue expression so, unless you put & or sizeof in front of it,
it gets converted to an expression of pointer type.

Compound literals of struct types are different: they denote proper
values (I can't think of a better term -- values you can refer to and
use). They too are lvalue expressions, but they get converted to a
value of the appropriate type when they are used.

 

[Keith Thompson]

Compound literals can be arrays and have values too, I'm surprised
nobody's used them as an example yet.

They have an array value only the literal sense that, being arrays and
containing bits, they can be said to have a value (as per 3.17). A
compound literal like

(int [3]){1,2,3}

is an lvalue expression so, unless you put & or sizeof in front of it,
it gets converted to an expression of pointer type.

Compound literals of struct types are different: they denote proper
values (I can't think of a better term -- values you can refer to and
use). They too are lvalue expressions, but they get converted to a
value of the appropriate type when they are used.

The way I prefer to think of it is that array values are just as
"proper" as any other values. The only thing "improper" about
them is that the language doesn't let you refer to them as a whole.
Though of course arr yields a value that's *part of* the value
of the array value of arr.

 

[Phil Carmody]

They have an array value only the literal sense that, being arrays and
containing bits, they can be said to have a value (as per 3.17).

Indeed. It's amusing to see the how the different perspectives change
people's perception of this issue. I think Keith has worded my view most
coherently. I thought I was providing another example of how we look at
things and now see it's amusingly dismissable as just being another
example of how others look at things differently!

Phil

 

[Tim Rentsch]

Does that mean that it *is* an array value? Maybe. I get the feeling
that wording like "specifies" and "designates" are deliberately
non-specific.

No, an initializer is a syntactic construct that appears in source
code, while a value is something that exists in a running program.
[snip elaboration]

Actually, programs don't hold values - what they hold are
representations of values. A value is a "meaning" or abstract
notion like the number 3. There aren't any 3's in a running
program; a program may have one or more bit patterns that are
used to represent the number 3, but it doesn't store the actual
number, which is just an abstract concept.

 

[Tim Rentsch]

[...]
What about the following...

http://67.40.109.61/torek/c/expr.html

And I quote..

"Array objects have a special, fundamental rule in C. This rule is
essentially arbitrary, and simply must be memorized. It falls out
from a key fact: C does not have array values. (There is one
exception to this, which I will save for later.) C does have array
objects -- just the values are missing. For instance, int a[5];
declares an ordinary array containing five ints. Logically, the
'value' of this array ought to be the five int values stored in that
array -- but it is not. Instead, the 'value' of the array is a
pointer to the first element of that array. "

The point being that, if I understand correctly, C does not have
'array of integers'. Instead, at least according to the former
comp.lang.c regular on here, the language has 'array objects'.

I find the quoted text misleading at best.

C does have array values; it just doesn't let you manipulate them
directly in most cases. The standard's definition of the word
"value" (C99 3.17) is "precise meaning of the contents of an object
when interpreted as having a specific type". Nothing in that
definition excludes arrays.

That definition is effectively useless. Functions, for example, are
said to return values. What object is being interpreted to get the
value returned by afunction? In the expression '1 + 1.0' something (it
is a value?) of type int is converted to a value of type double by the
usual arithmetic conversions, but there are no objects involved here.
The same goes for (int)1.0.

The problem with the definition is that it's incomplete (like a
number of other definitions in the standard). What it describes
is certainly an *example* of a value, but surely the evaluation of
an expression also results in a *value*. [snip..snip..snip]

The only consistent interpretation I can come up with is:

The Standard's definition of "value" is incomplete.

Any object in which something valid has been stored (handwaving meant to
exclude trap representations and perhaps indeterminate values) has a
"value", which is the "precise meaning of the contents of an object
when interpreted as having a specific type". [snip elaboration]

Let me suggest a different and IMO more useful way of thinking
about this.

A value is the /meaning/ of an object (considered as a particular
type). The key word here is /meaning/ - a 'value' is an
abstraction, an idea, not something that can be held in a
program, but a point in an abstract value space that follows
certain rules (eg, mathematical addition, etc).

It's true that bit patterns stored in objects are used to
represent values (again, under a particuilar type). However, the
value itself -- the "meaning" -- is something that does not
depend on any object for its existence: an unchanging, abstract
idea (such as, for example, the number 3).

When the Standard says an expression yields a certain value, what
that means is the program produces something whose "meaning" is
the same if the abstract value were stored into an object that
has the same type as that of the value. (All values in C
programs are effectively indexed by what type they are.) More
concretely, an expression like

21 + 21

yields the same value (ie, the same meaning) as is held by
the variable 'x' (an object) after

int x = 42;

Viewed from this perspective, what is produced by evaluating an
expression has the same meaning as some bit pattern stored in an
object. Because it has the same meaning, it is the same value.
To say that another way, objects do hold patterns of bits that
represent values, but values don't depend on objects for their
existence -- if something has the same meaning as a certain bit
pattern would if held in an object, then that is the same value
as the object would have, whether an object is present or not.
(As always, subject to the necessary qualifications about types.)

I agree that the text of the Standard takes certain linguistic
liberties -- eg, saying an expression yields a value (which is
quite nonsensical, whatever expressions produce it certainly
isn't a 'meaning') -- that sometimes are frustrating or
confusing. However, I don't think the problem in this case is
that the definition is incomplete; rather, there is some
looseness in the language that describes how expressions work,
glossing over the distinction between abstract values and what
is produced in an actual program that represents such values.
Because the distinction usually isn't important, the Standard
largely ignores it. Is that a big problem? Personally I would
say no: most people understand it without having to think too
hard, and that's probably more important than trying to be
completely precisely accurate if that comes with some loss in
readability or ease of understanding.

I would of course support a proposed change that results in text
that is more precise and equally readable. I just haven't seen
one yet.

 

[Keith Thompson]

Ben Bacarisse wrote:
C does have array values; it just doesn't let you manipulate them
directly in most cases. The standard's definition of the word
"value" (C99 3.17) is "precise meaning of the contents of an object
when interpreted as having a specific type". Nothing in that
definition excludes arrays.

That definition is effectively useless.

The standard says
"An initializer specifies the initial value stored in an object."

Which leads me to believe
that an initializer for an array,
specifies the initial value stored in the array.

Does that mean that it *is* an array value? Maybe. I get the feeling
that wording like "specifies" and "designates" are deliberately
non-specific.

No, an initializer is a syntactic construct that appears in source
code, while a value is something that exists in a running program.
[snip elaboration]

Actually, programs don't hold values - what they hold are
representations of values. A value is a "meaning" or abstract
notion like the number 3. There aren't any 3's in a running
program; a program may have one or more bit patterns that are
used to represent the number 3, but it doesn't store the actual
number, which is just an abstract concept.

<shameless_handwave>I was talking about the *abstract* running
program.</shameless_handwave>