Re: contiguity of arrays

From: Wojtek Lerch (Wojtek_L_at_yahoo.ca)
Date: 10/05/04 

Date: Tue, 5 Oct 2004 10:31:37 -0400

"David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote in message
news:s6p8d.210978$hZ3.162938@fe2.news.blueyonder.co.uk...
> Wojtek Lerch wrote:
>> "David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote in message
>> news:SV68d.154584$U04.107170@fe1.news.blueyonder.co.uk...
>>>Wojtek Lerch wrote:
>>>>"David Hopwood" <david.nospam.hopwood@blueyonder.co.uk> wrote:
>>>>
>>>>>to perform an access via a given pointer, say of type T, you need to be
>>>>>able to infer that it currently points to a region that *can* hold an
>>>>>object
>>>>>of type T. The memory allocation functions are a special case that
>>>>>return
>>>>>pointers to regions able to hold objects of any type.
>>>>
>>>>That is not a very accurate wording: regions of memory don't hold
>>>>objects, they are objects.
>>>
>>>No. Objects are typed; memory regions aren't.
>>
>> No. Objects are regions of memory; lvalues that designate objects are
>> typed. "When an object is said to have a particular type, the type is
>> specified by the lvalue used to designate the object."
>
> That isn't actually consistent with how the standard uses the term
> "object".

No, the standard doesn't seem consistently pedantic about consistency, does
it. In some cases, it says "the type" of an object when talking about the
object's declared type.

> If you search for "object" you'll see that in most cases the usage depends
> on objects (and *not* just lvalue expressions) having a type. For example:

That's because in most cases, objects are talked about in the context of a
declaration or an expression.

> # 3.2
> # alignment
> # requirement that objects of a particular type be located [...]

Nothing wrong here: objects (i.e. regions of memory) accessed through an
lvalue of a particular type must be aligned appropriately to the type.

> # 3.5
> # bit
> # unit of data storage in the execution environment large enough to
> # hold an object that may have one of two values

I don't think they really meant an "object" here. A C object can't be
smaller than eight bits, can it?

> [memory regions cannot have values; objects can only have values because
> they have a type]

The contents of memory regions (i.e. objects) represent values when
interpreted according to a type.

> # 3.7.3
> # wide character
> # bit representation that fits in an object of type wchar_t [...]

This is not really a good definition, is it?... A wide character is not a
bit representation. It's an integer value of type wchar_t.

> # 3.15
> # parameter [...]
> # object [...] that acquires a value on entry to the function
>
> [again, objects can only have values because they have a type]

The contents of objects represent values. The standard often says "value"
when it really means "contents". For instance, 6.5p7 says, "An object shall
have its stored value accessed only by an lvalue expression that has one of
the following types..."

> # 5.1.2 Execution environments
> # [...] All objects with static storage duration shall be /intialized/
> (set
> # to their initial values) before program startup. [...]
>
> [there is no lvalue expression involved in this case]

No, but they have a declared type.

> etc., etc.

Don't forget about this one:

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

>>>>An allocated object can be given any effective type by using an lvalue
>>>>of
>>>>that type to store a value in the object.
>>>
>>>More accurately, an allocated region can be accessed as an object of any
>>>given effective type, by using an lvalue expression that designates an
>>>object of
>>>that type to store a value in that object.
>>
>> Even more accurately, the effective type of an allocated object can be
>> *changed* to any given type by using an lvalue of that type to store a
>> value
>> in the object.
>
> This is not a more accurate statement of the same thing; it's an entirely
> different semantics. C implementations actually implement what I said.

Maybe; I have to admit that I don't understand what you mean by "object".
If it's not a region of memory, or an lvalue that designates a region of
memory, or a value, then what is it?

Relevant Pages

  • Re: contiguity of arrays
    ... > No, the standard doesn't seem consistently pedantic about consistency, does ... Yes, and sometimes in the context of more than one declaration or expression, ... definition itself is not consistent with "object" being the same thing as ... a region of memory. ...
    (comp.lang.c)
  • Re: contiguity of arrays
    ... A declared object has an identifier and a declared type. ... >> an lvalue of a particular type must be aligned appropriately to the type. ... > interpret the standard as it is currently written. ... What does the standard call regions of memory? ...
    (comp.lang.c)
  • Re: address of functions return value
    ... register int r; ... If p eventually holds the address of an int object in memory, ... *p will be an lvalue. ... I can't provide chapter and verse, because the standard gets this ...
    (comp.lang.c)
  • Re: A solution for the allocation failures problem
    ... Can you find anything in the standard which *allows* this behaviour? ... it defines how your C program is supposed to behave. ... previously allocated memory available for further allocation. ... says the memory will be made available for further allocation. ...
    (comp.lang.c)
  • Re: Target market for Intellasys.
    ... I would like to see a full speed general purpose embedded serial interconnect IO bus standard. ... Looking through serial memory I found something like a maximum of 70mhz speed which is pretty useless if it was the only bus in a cutting edge design. ... All other control mode levels also have this ability, to allow developer to instigate their own versions of the features not defined in that level, as they wish, if they wish. ...
    (comp.lang.forth)