Are constants and string literals considered "data objects" in c?

[kobu.selva]

I was recently part of a little debate on the issue of whether
constants and string literals are considered "data objects" in C. I'm
more confused now than before.

I was always under the understanding that only "named" storage
areas(from the standard) were data objects. Since constants and string
literals don't have lvalues, they can't be data objects. Yet, I was
shown the first page of chapter 2 in K&R2, which states that variables
AND constants are data objects.

Does anyone have any opinions on this?

 

[pete]

I was recently part of a little debate on the issue of whether
constants and string literals are considered "data objects" in C. I'm
more confused now than before.

I was always under the understanding that only "named" storage
areas(from the standard) were data objects.
Since constants and string
literals don't have lvalues, they can't be data objects. Yet, I was
shown the first page of chapter 2 in K&R2, which states that variables
AND constants are data objects.

That's not a strict definition of "object".
Constants aren't objects.

N869
3.15
[#1] object
region of data storage in the execution environment, the
contents of which can represent values

String literals refer to arrays.
Arrays are objects.

 

[infobahn]

I was recently part of a little debate on the issue of whether
constants and string literals are considered "data objects" in C. I'm
more confused now than before.

I was always under the understanding that only "named" storage
areas(from the standard) were data objects.

Not so. The Standard says that an object is a "region of data
storage in the execution environment, the contents of which can
represent values". Nothing in there about "named" storage areas.

Since constants and string
literals don't have lvalues, they can't be data objects.

Yes, they can. Objects need not be writable at runtime. You'd
be hard-pressed to justify calling 6 an object, but string
literals are arrays of char which are guaranteed to stick around
for the life of the program, so it's hard to argue that they're
not objects.

 

[Chris Torek]

I was recently part of a little debate on the issue of whether
constants and string literals are considered "data objects" in C. I'm
more confused now than before.

I was always under the understanding that only "named" storage
areas(from the standard) were data objects. ...

Does anyone have any opinions on this?

The C standard has an opinion, and as such, it is pretty much
final

3.15 Object

[#1] A region of data storage in the execution environment,
the contents of which can represent values. Except for
bit-fields, objects are composed of contiguous sequences of
one or more bytes, the number, order, and encoding of which
are either explicitly specified or implementation-defined.
When referenced, an object may be interpreted as having a
particular type; see 6.2.2.1.

Of course, this C99 draft text says "objects", not "data objects",
but since the definition of "object" is "a region of data storage",
prefixing it with the word "data" appears to be benign, albeit
redundant.

Given this definition, a string literal that produces an array clearly
produces an object (or "data object", if you like the extra word):

const char *p = "hello";

even though the object itself has no name.

Ordinary constants, on the other hand, are not "region of data
storage":

void f(void) {
int i = 3;
...

The constant 3 is not a "region of data storage", nor is it composed
of a "contiguous sequence of one or more bytes", especially if one
happens to be compiling on a SPARC:

mov #3, %l1 ! 3 does not appear as a separate value anywhere

(a "mov" instruction is a pseudo-instruction built out of a bitwise
"or" instruction, in this case, "or"ing %g0 with the signed immediate
13-bit constant that occupies the "simm13" field of the 32-bit
instruction word), or a 680x0:

moveq #3, d4 ! again, 3 does not appear as a separate value

(here the constant 3 is once again embedded within a bitfield in
the instruction word -- and in this case, because the bitfield is
only 3 bits wide, one cannot even isolate a byte with value 3).

(I add the last parenthetical remark because if you dump the
32-bit SPARC instruction as four separate bytes, one of them
*does* have the value 13. But if we just change the line to
read:

int i = 500;

-- which uses a single "mov #500, %l1" instruction -- we find there
is no 16-bit word containing 500, so this is something of a red
herring anyway.)

The named variable i, of course, *is* a "region of data storage"
and is therefore an object. If we take its address and decompose
it into a sequence of "unsigned char"s, we will find the machine's
representation of whatever "int" value i holds at the moment.

 

[italy]

I was recently part of a little debate on the issue of whether
constants and string literals are considered "data objects" in C. I'm
more confused now than before.

I was always under the understanding that only "named" storage
areas(from the standard) were data objects. Since constants and string
literals don't have lvalues, they can't be data objects. Yet, I was
shown the first page of chapter 2 in K&R2, which states that variables
AND constants are data objects.

Does anyone have any opinions on this?

A data object in C is simply any region of memory that's obtained
during run-time execution. An object is synmonous to a data object. A
string constant(or string literal) does take a region of memory, but
the string itself is static.(strings are immutable in C).

 

[Jack Klein]

I was recently part of a little debate on the issue of whether
constants and string literals are considered "data objects" in C. I'm
more confused now than before.

I was always under the understanding that only "named" storage
areas(from the standard) were data objects. Since constants and string
literals don't have lvalues, they can't be data objects. Yet, I was
shown the first page of chapter 2 in K&R2, which states that variables
AND constants are data objects.

Does anyone have any opinions on this?

Aside from several excellent and correct answers that you have already
received, consider this as well.

There are only two things in C that pointers can point to, namely
objects and functions.

The mere fact that you can send a string literal to printf(), for
example, means that you can have a pointer to the (first character of)
the string literal.

The mere fact that you can write code like this:

const int ci = 10;
const int *cip = &ci;

So string literals and constants must be objects, since you can take
their address and have pointers point to them, and they certainly are
not functions.

 

[Michael Mair]

Aside from several excellent and correct answers that you have already
received, consider this as well.

There are only two things in C that pointers can point to, namely
objects and functions.

The mere fact that you can send a string literal to printf(), for
example, means that you can have a pointer to the (first character of)
the string literal.

The mere fact that you can write code like this:

const int ci = 10;
const int *cip = &ci;

So string literals and constants must be objects, since you can take
their address and have pointers point to them, and they certainly are
not functions.

Addendum (Jack knows this, just to clarify): Here, we are talking
not about "constant" but about "const qualified"; constants in the
C sense are something different and you cannot take the address
of, say, the constant value 4.2e1 or an enumeration constant.

Cheers
Michael