C objects

[junky_fellow]

What is a C object ?

If i have some function "func()" in my C program, then
can i say that "func()" is a C object ?
or if i have some function pointer (ptr) which contains the address
of function "func()", can i say that ptr is pointing to some C object ?

Is a C object always associated with some "data" ?

thanx in advance for any help .....

[RCollins]

E. Robert Tisdale wrote:

Mike Wahler wrote:

E. Robert Tisdale wrote:

Mike Wahler wrote:

E. Robert Tisdale wrote:

> A data object must be initialized to a valid value
> of an object of that type before you can call it an object --
Not true.

> it must be constructed.
"Constructe d" doesn't have a meaning in C.

int main(int argc, char* argv[]) {
int i; // is 'i' an object? The language standard says it is
return 0;
}
Whatever value 'i' has must be a valid int.

Right. But 'i' isn't required to represent a value.
That's what 'uninitialized' means.

typedef struct X {
int* p;
} X;

int main(int argc, char* argv[]) {
X x; // is 'x' a valid object?

Yes. But it doesn't represent any meaningful value.

Then your definition of *type* makes no sense.
A type defines *all* of the values that an object may have.
You seem to be saying that an "uninitiali zed" object
may have [redundant] meaningless values.
By your definition, the values that a type may have
is determined by its representation
which means that data abstraction is not possible in C.

I think, in this case, "unitialize d" might mean "unknown".
For example:

void foo(void) {
int i; /* uninitialized value here */

printf("i=%d\n" , i);
}

(ignoring the undefined behaviour for now) will print
out some unknown decimal value.

You are interpreting the C standards documents too literally.
And just like the fundamentalists
who interpret Holy Scripture too literally,
you eventually encounter contradictions to logic and common sense.

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[RCollins]

Joe Wright wrote:

E. Robert Tisdale wrote:

Keith Thompson wrote:

E. Robert Tisdale writes:

pete wrote:

> junky_fellow wrote:
>
>
>> Is a C object always associated with some "data"?
>
>
>
> Normally, yes, though I suppose you could malloc some memory and
> free it immediately if you wanted to, without involving any data.

No.

malloc() doesn't create objects.
It returns a pointer of type void*.
A data object must be initialized to a valid value
of an object of that type before you can call it an object --
it must be constructed.


C99 3.14 defines the term "object":

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

The term "object" refers to the *region*, not to the data it may
contain.

It *must* be an object of some type.
The type specifies *all* of the values that that object may have.

Please Mr. Tisdale, consider this ..

unsigned int *ui;
ui = malloc(sizeof *ui);

... Assuming malloc() was successful, is ui[0] an object? Of course it
is. Was it created by the declaration of ui? No, declarations don't
define or create objects. I guess malloc() did it.

What if *ui (since it is un-initialized) contains a trap representation?
Is it still considered an int object?

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[Joe Wright]

RCollins wrote:

Joe Wright wrote:

E. Robert Tisdale wrote:

Keith Thompson wrote:

E. Robert Tisdale writes:

> pete wrote:
>
>> junky_fellow wrote:
>>
>>
>>> Is a C object always associated with some "data"?
>>
>>
>>
>>
>> Normally, yes, though I suppose you could malloc some memory and
>> free it immediately if you wanted to, without involving any data.
>
>
>
>
> No.
>
> malloc() doesn't create objects.
> It returns a pointer of type void*.
> A data object must be initialized to a valid value
> of an object of that type before you can call it an object --
> it must be constructed.

C99 3.14 defines the term "object":

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

The term "object" refers to the *region*, not to the data it may
contain.


It *must* be an object of some type.
The type specifies *all* of the values that that object may have.

Please Mr. Tisdale, consider this ..

unsigned int *ui;
ui = malloc(sizeof *ui);

... Assuming malloc() was successful, is ui[0] an object? Of course it
is. Was it created by the declaration of ui? No, declarations don't
define or create objects. I guess malloc() did it.

What if *ui (since it is un-initialized) contains a trap representation?
Is it still considered an int object?

Sure, why not?

--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[RCollins]

Joe Wright wrote:

RCollins wrote:

Joe Wright wrote:

E. Robert Tisdale wrote:

Keith Thompson wrote:

> E. Robert Tisdale writes:
>
>> pete wrote:
>>
>>> junky_fellow wrote:
>>>
>>>
>>>> Is a C object always associated with some "data"?
>>>
>>>
>>>
>>>
>>>
>>> Normally, yes, though I suppose you could malloc some memory and
>>> free it immediately if you wanted to, without involving any data.
>>
>>
>>
>>
>>
>> No.
>>
>> malloc() doesn't create objects.
>> It returns a pointer of type void*.
>> A data object must be initialized to a valid value
>> of an object of that type before you can call it an object --
>> it must be constructed.
>
>
>
>
>
>
> C99 3.14 defines the term "object":
>
> object
> region of data storage in the execution environment,
> the contents of which can represent values
>
> The term "object" refers to the *region*, not to the data it may
> contain.

It *must* be an object of some type.
The type specifies *all* of the values that that object may have.


Please Mr. Tisdale, consider this ..

unsigned int *ui;
ui = malloc(sizeof *ui);

... Assuming malloc() was successful, is ui[0] an object? Of course
it is. Was it created by the declaration of ui? No, declarations
don't define or create objects. I guess malloc() did it.

What if *ui (since it is un-initialized) contains a trap representation?
Is it still considered an int object?

Sure, why not?

I just wanted to make sure I was on the 'same page' as the other
posters in this thread.

--
Ron Collins
Air Defense/RTSC/BCS
"I have a plan so cunning, you could put a tail on it and call it a weasel"

[Joe Wright]

Emmanuel Delahaye wrote:

Joe Wright wrote on 08/08/04 :

unsigned int *ui;

This is the defintion of a pointer. It creates statically a 'pointer'
object. Its value is undeterminate (points anywhere).

ui = malloc(sizeof *ui);

This creates dynamically an object which address is stored into the
pointer 'ui'.

... Assuming malloc() was successful, is ui[0] an object? Of course it
is.

Yes.

Was it created by the declaration of ui?

What declaration ?

No, declarations don't define or create objects. I guess malloc() did it.

I think you are mixing declaration and definition. Of course an object
declaration creates nothing, but an object definition does create an
object.

The point is that a pointer is just a few bytes in memory, but it has a
size, type and address. It is an object.

Thanks ed, you're right, of course. My point is that defining ui as
pointer to unsigned int, while creating the pointer, does not create
the unsigned int. Before the successful malloc() above, the contents
of ui is indeterminate and any reference to *ui or ui[0] causes
undefined behaviour. If, and only if, the malloc() succeeds does
ui[0] become an object.

--
Joe Wright mailto:jo****** **@comcast.net
"Everything should be made as simple as possible, but not simpler."
--- Albert Einstein ---

[pete]

RCollins wrote:

Joe Wright wrote:

RCollins wrote:

Joe Wright wrote:

E. Robert Tisdale wrote:

> Keith Thompson wrote:
>
>> E. Robert Tisdale writes:
>>
>>> pete wrote:
>>>
>>>> junky_fellow wrote:
>>>>
>>>>
>>>>> Is a C object always associated with some "data"?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Normally, yes, though I suppose you could malloc some memory and
>>>> free it immediately if you wanted to, without involving any data.
>>>
>>>
>>>
>>>
>>>
>>> No.
>>>
>>> malloc() doesn't create objects.
>>> It returns a pointer of type void*.
>>> A data object must be initialized to a valid value
>>> of an object of that type before you can call it an object --
>>> it must be constructed.
>>
>>
>>
>>
>>
>>
>> C99 3.14 defines the term "object":
>>
>> object
>> region of data storage in the execution environment,
>> the contents of which can represent values
>>
>> The term "object" refers to the *region*, not to the data it may
>> contain.
>
>
>
>
>
> It *must* be an object of some type.
> The type specifies *all* of the values that that object may have.


Please Mr. Tisdale, consider this ..

unsigned int *ui;
ui = malloc(sizeof *ui);

... Assuming malloc() was successful, is ui[0] an object? Of course
it is. Was it created by the declaration of ui? No, declarations
don't define or create objects. I guess malloc() did it.

What if *ui (since it is un-initialized) contains a trap representation?
Is it still considered an int object?

Sure, why not?

I just wanted to make sure I was on the 'same page' as the other
posters in this thread.

For
int Integer;
Integer, refers to an object even though it is uninitialized
and may contain a trap representation.

Functions have addresses but they're not objects,
register specified variables don't have addresses, but they're objects.
Except for those two things,
having an address in a C program is equivalent to being an object.

--
pete

[CBFalconer]

pete wrote:

.... ******* SNIP 90 odd lines of garbage quotes ******* ...
For
int Integer;
Integer, refers to an object even though it is uninitialized
and may contain a trap representation.

Functions have addresses but they're not objects,
register specified variables don't have addresses, but they're objects.
Except for those two things,
having an address in a C program is equivalent to being an object.

Please snip stuff not germane to your answer.

--
"Churchill and Bush can both be considered wartime leaders, just
as Secretariat and Mr Ed were both horses." - James Rhodes.
"A man who is right every time is not likely to do very much."
- Francis Crick, co-discover of DNA

[Rich Grise]

pete wrote:

RCollins wrote:

Joe Wright wrote: .... I just wanted to make sure I was on the 'same page' as the other
posters in this thread.

For
int Integer;
Integer, refers to an object even though it is uninitialized
and may contain a trap representation.

Functions have addresses but they're not objects,
register specified variables don't have addresses, but they're objects.
Except for those two things,
having an address in a C program is equivalent to being an object.

So, it's kinda like a function isn't considered an object, by definition?

If I defined a structure with some data members and some pointers to
functions, could I then come up with some rationale for calling that an
"object?" Or is that too much of a stretch?

Thanks,
Rich

[Emmanuel Delahaye]

Rich Grise wrote on 11/08/04 :

So, it's kinda like a function isn't considered an object, by definition?
Yes. A function is not an object. It's a function!
If I defined a structure with some data members and some pointers to
functions, could I then come up with some rationale for calling that an
"object?" Or is that too much of a stretch?

A data member is an object
A pointer to a function is an object. The pointee is not an object.
A structure is an object

--
Emmanuel
The C-FAQ: http://www.eskimo.com/~scs/C-faq/faq.html

"C is a sharp tool"

[pete]

Rich Grise wrote:

pete wrote:

RCollins wrote:

Joe Wright wrote: ... I just wanted to make sure I was on the 'same page' as the other
posters in this thread.
For
int Integer;
Integer, refers to an object even though it is uninitialized
and may contain a trap representation.

Functions have addresses but they're not objects,
register specified variables don't have addresses, but they're objects.
Except for those two things,
having an address in a C program is equivalent to being an object.

So, it's kinda like a function isn't considered an object,
by definition?

Yes.
There are three major catagories of types.
Function types
object types
incomplete types

Function types are defined by their parameter types
and their return types.
Object types like (char), are the types which have determinable sizes.
Incomplete types like (void) or (extern array[]) don't have sizes.
If I defined a structure with some data members and some pointers to
functions,
could I then come up with some rationale for calling that an
"object?" Or is that too much of a stretch?

There's nothing special about a structure being an object.

--
pete