-6

The term object is defined by the C11 Standard section 3.15:

object

region of data storage in the execution environment, the contents of which can represent values

Given the following code:

int x;

int y[10];

struct my_struct {
  int a;
  int b;
};
struct my_struct z;

In the code above, x, y, and z are different objects? The members of z are the same object? The elements of y are the same object?

StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
sidney
  • 1,241
  • 15
  • 32
  • 3
    1) Yes. 2,3) Yes but they're also distinct subobjects. – Petr Skocik Oct 16 '17 at 09:01
  • Yes. No. No. Yes because `x`, `y` and `z` are different "objects". No because the members of the structure are in turn separate objects. And finally the last no because the elements of `y` are also separate objects. The important part of the quote is "the contents of which can represent **values**". For example, `y[0]` and `y[1]` can represent an `int` value, but they are *different*, therefore different objects. – Some programmer dude Oct 16 '17 at 09:03
  • To further clarify: for the purposes of alias analysis, you should consider accesses to subobjects through their parent object as accesses to the parent object as well, because that's what compiler do. (See my question: https://stackoverflow.com/questions/42352681/strict-aliasing-and-overlay-inheritance). – Petr Skocik Oct 16 '17 at 09:23

4 Answers4

3

In the code above, x, y, and z are different objects?

Yes, they occupy completely separate regions of storage.

The members of z are the same object?

No, z.a and z.b are two distinct objects. One can say that they are sub-objects of z since the storage of each is contained in the storage of the whole, but it's not the exact same region of storage. The size of the region also plays a part.

The elements of y are the same object?

No, each element of y is a separate object. But by the same reasoning as above, one can consider them sub-objects of y.

StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
3

The meaning of the term object in the C standard is simply: a variable allocated in memory. As it turns out, it is the same definition of an object as used in languages with OO support.

Usually, objects have a certain type (to be useful), see the rest of the text in 3.15:

NOTE When referenced, an object may be interpreted as having a particular type; see 6.3.2.1.


In the code above, x, y, and z are different objects?

Yes, because they are different variables.

The members of z are the same object?

They are part of the z object but are at the same time different sub-objects. a and b are different objects, but when the struct is referred to as whole, they are part of the same struct object.

Lundin
  • 195,001
  • 40
  • 254
  • 396
1

Graphically:

   +–––+
x: |   |
   +–––+

   +–––+
y: |   | y[0]
   +–––+
   |   | y[1]
   +–––+
    ...
   +–––+
   |   | y[9]
   +–––+

   +–––+
z: |   | a
   +–––+
   |   | b
   +–––+

Each of x, y, and z are objects. So are each y[i], z.a, and z.b.

John Bode
  • 119,563
  • 19
  • 122
  • 198
1

The C Standard uses the term "object" to describe at least three different concepts: a sequence of consecutively-addressed bytes which are exclusively allocated for a particular purpose, any combination of address and type which could be used to identify an allocation or portion thereof, regardless of whether it actually is used, or a combination of address and type that have been or will be used within some context to access storage or derive another object [same definition] that has been or will be used in such fashion. The distinction between the these definitions didn't matter in the language described by K&R's book The C Programming Language, but the Standard added rules which make it necessary to distinguish those meanings, without offering the terminology necessary to draw such distinctions.

When N1570 p6.5p7 of the C Standard says that an object may only have its stored value accessed via lvalues of certain types, it's unclear what exactly it means by "object". If it was referring to the second sense of "object", almost any access to anything made with a non-character-type lvalue would invoke UB. It would probably make more sense to use the third sense of "object" when interpreting that text, but such "objects" would have an active lifetime that differs from that of the underlying storage.

In your example, there are three allocations--x, y, and z. If sizeof (int) is 4 and sizeof z is 8, then after unsigned char *p = (unsigned char*)&z.b, there would exist an object of type unsigned char identified by *p, but the Standard is unclear whether the pointer conversion would have caused an unsigned char object to exist where none had previously, or merely merely yielded a pointer to an unsigned char object that was created when z was created and will exist as long as z does.

supercat
  • 77,689
  • 9
  • 166
  • 211