D
Dan Pop
In said:
Then, you're reading impaired.
Nope, it isn't. The underlined text *explicitly* admits the existence
of lvalues that DO NOT designate objects. 3 is an example of such an
lvalue.
Dan
Then, you're reading impaired.
Nope, it isn't. The underlined text *explicitly* admits the existence
of lvalues that DO NOT designate objects. 3 is an example of such an
lvalue.
Dan
K
kal
I am afraid that I don't see 3 as an lvalue at all.
My understanding is that 3 is a "value of type int" and
not a "value of object type int."
Now, *((type *)3) is an lvalue since it is of an "object type",
though it may not designate an object and thus may give rise to
undefined behaviour.
The following code, non portable, should work on some systems.
<code>
long i, j;
i = (long)(&j);
*((long *)i) = 1;
</code>
OTOH I may just be muddled about the whole thing.
I am taking the word "object" to mean what it says in 3.15.
3.15
1 object
region of data storage in the execution environment, the
contents of which can represent values
J
Jeremy Yallop
kal said:
"Object" and "object type" are distinct concepts.
Types are partitioned into object types (types that fully describe
objects), function types (types that describe functions), and
incomplete types (types that describe objects but lack information
needed to determine their sizes). [C99 6.2.5]
The type "int" is one of the object types.
Jeremy.
C
Chris Torek
Jeremy Yallop already pointed out the distiction C99 has between
"object" and "object type".
The former makes more sense, but C99 defines it as the latter.
The fundamental problem is that C99 took a more-or-less useful
concept -- the "lvalue" -- and redefined it as a pretty-much-useless
one. For this reason, I recommend avoiding the term entirely:
not only is it "jargon", it is not even useful jargon anymore.
For the record, in C89, 3 is not an lvalue, and in C99, 3 is an
lvalue. In both C89 and C99, 3 is not an object. "Object" remains
a useful concept. "Object type" is not a wonderful phrase but also
represents something that matters.
J
Joe Wright
kal said:
I agree with Kal, and Dan! Surprise! But Dan has his tongue firmly
in cheek and Kal does not. My $ 0.02 follows without tongue in cheek.
First the expression 3 is a value of int type. 3 is not an object
and has no object type. Values don't have object type. Only
expressions designating objects have object type.
int i;
Now the expression i has object type but indeterminate value. The
expression i is an lvalue.
i = 3;
Success. The int value 3 is assigned to the int object i.
Some wording in C99 muddies this up some and Dan is pointing it out.
Nobody really thinks that 3 = 4; is legal, they're just poking fun
at the Standard that seems to say so. I guess.
P
pete
Joe said:
~0u is a valid expression of object type.
~0u does not designate an object.
For:
int array[1];
(array[-1]) is an expression of object type.
array[-1] does not designate an object.
The use of (array[-1]), would invoke undefined behavior.
F
Foobarius Frobinium
Why? You just told me what they are (canonically) in excruciatingly
elaborate detail.
I *am* aware of the canonical definition of lvalues and rvalues. A
number of texts (including Deep C Secrets), use a completely different
definition. It is common amongst a lot of people (just google for
'lvalue address' some time) I'm not sure where it arose, but I found
it's what I cut my teeth on and I found it *awfully* useful as a way
of thinking about pointers.
Perhaps I should change my terminology or put in some kind of note,
but I'm not sure. Until now, I have never heard of the paradigm of
lvalue and rvalue I use criticized. It's a little different from
saying arrays are pointers, which throws you off altogether.
F
Foobarius Frobinium
Jack Klein said:
Well, I changed everything and made sure it was all in context. It
actually reads a little better now...
A
Arthur J. O'Dwyer
This is wrong (and FWIW, I don't think Dan was speaking tongue-in-
cheek at all; he was quoting the Standard). 'int' is MOST DEFINITELY
an 'object type'. It is most definitely NOT a 'function type' nor an
'incomplete type'. You can't deny that.
You guess wrongly. Here's the situation.
(A) The word "lvalue" in general CS jargon means "something with
an address, or something assignable-to." Something along
those lines. This definition is, strictly speaking, off-topic
in comp.lang.c.
(B) The C89/C90 Standard defines 'lvalue' to include 'i' but
exclude '3', to use your example. Thus the C90 'lvalue'
corresponds almost exactly to the general-CS definition
in (A), modulo any corner cases, of which I'm sure there must
be a few.
(C) The C99 standard defines 'lvalue' to include both 'i' AND '3'.
Thus, the C99 'lvalue' does not correspond to either (A) or
(B).
(D) The statement '3 = 4;' is not legal in either C90 or C99.
Neither standard says or implies that it is legal. However,
in C90 we can also say that '3' is not an lvalue (and thus a
general knowledge of CS jargon will suggest that it can't
legally appear on the left side of an assignment); in C99,
since '3' IS an lvalue, we have to actually consult the
rest of the language definition to convince ourselves that
the expression '3 = 4' is invalid (or else use our general
knowledge of CS to realize that we obviously can't assign
anything to '3'; it just doesn't work).
-Arthur,
hoping to be spared the Fortran anecdotes
D
Dan Pop
In said:
Please explain to the rest of us the difference between "type int" and
"object type int". Chapters and verses are welcome.
Dan
J
Joe Wright
Arthur said:
Nonsense. Quoting you just above..
'int' is MOST DEFINITELY an 'object type'. It is most definitely
NOT a 'function type' nor an 'incomplete type'. You can't deny that.
I do deny that. 'int' is a type. Objects have type and values have
type but nothing about type 'int' suggests 'object' rather than
'value'. Carefully now, consider..
#define THREE 3
int i;
The expressions 'THREE' and 'i' both have 'int' type. Only 'i' has
object type.
Here and elsewhere in this thread, Chris Torek, Dan Pop and yourself
describe the C99 Standard as having changed the meaning of lvalue to
the extent that the term is now valueless. That 3 is an lvalue is
ludicrous on its face.
I suggest we all take a deep breath, consider the C99 verbiage with
a grain of salt, and continue the search for unambiguous truth.
That there are multiple conflicting definitions for 'pointer',
'object', 'value' and other fundamental entities of the C language
in the C Standard is, to me, explicable but deplorable.
P
pete
Joe said:
There are only "object types" "incomplete types" and "function types".
There are no "rvalue types".
N869
6.2.5 Types
[#1] The meaning of a value stored in an object or returned
by a function is determined by the type of the expression
used to access it. (An identifier declared to be an object
is the simplest such expression; the type is specified in
the declaration of the identifier.) Types are partitioned
into object types (types that describe objects), function
types (types that describe functions), and incomplete types
(types that describe objects but lack information needed to
determine their sizes).
M
Mantorok Redgormor
Joe Wright said:
Please review the following thread:
http://groups.google.com/[email protected]&rnum=3
I
Irrwahn Grausewitz
[about the C99 lvalue definition]
[...]
| >NOT a 'function type' nor an 'incomplete type'. You can't deny that.
There is no type in C that is neither an object type, nor a function
type, nor an incomplete type. There's nothing like 'plain int' as
opposed to 'object type int'; int is an object type by definition -
always (6.2.5).
You're are mistaken. The Standardese term 'object type' classifies
types like int, double, etc. as being types that objects can have,
but it doesn't require anything having this type being an object in
the first place.
Some examples, where object types, but not necessarily objects,
are involved:
- the value returned by a function call (6.5.2.2p1).
- arguments passed to functions (6.5.2.2p4)
- compound literals (6.5.2.5p1)
- arithmetic operations (all arithmetic types are object types)
- etc. pp. ad nauseam
THREE is not an expression: the compiler will never come to see it;
so let's stick to 3 instead:
3 is not an object;
3 is of type int;
int is an object type;
hence the expression 3 is a non-object having object type int.
Simple, isn't it?
<snip>
Regards
[...]
| >'int' is MOST DEFINITELY an 'object type'. It is most definitely
| >NOT a 'function type' nor an 'incomplete type'. You can't deny that.
There is no type in C that is neither an object type, nor a function
type, nor an incomplete type. There's nothing like 'plain int' as
opposed to 'object type int'; int is an object type by definition -
always (6.2.5).
You're are mistaken. The Standardese term 'object type' classifies
types like int, double, etc. as being types that objects can have,
but it doesn't require anything having this type being an object in
the first place.
Some examples, where object types, but not necessarily objects,
are involved:
- the value returned by a function call (6.5.2.2p1).
- arguments passed to functions (6.5.2.2p4)
- compound literals (6.5.2.5p1)
- arithmetic operations (all arithmetic types are object types)
- etc. pp. ad nauseam
THREE is not an expression: the compiler will never come to see it;
so let's stick to 3 instead:
3 is not an object;
3 is of type int;
int is an object type;
hence the expression 3 is a non-object having object type int.
Simple, isn't it?
<snip>
Regards
K
kal
I admit that the difference is none. After further reading,
my understanding at present is that "int" is a type. It is
one of a set of types known as "object types."
When I wrote that I was struggling to differentiate a value
of type "int" from an object of type "int".
Now, despite my incompetency to phrase my problem correctly,
the problem remains still.
Let us consider the defintion of the term "object", viz.
"region of data storage in the execution environment,
the contents of which can represent values."
Three terms are of interest, "object", "contents", and
"value." Unfortunately I am unable to find formal
definitoins for "contents" and "value." So I have taken
their usage to be axiomatic.
Consider the expression "i = i" where i has been declared
as "int i;". The two i's do not seem to mean the same thing.
One denotes the object and the other the value of its contens.
My problem is, how to understand this distinction clearly
within the framework of the language of the standard?
Are both the i's lvalues?
Is "3" an object?
Are all expressions objects?
Is "*((int *)3)" an lvalue as per C89 standard?
D
Dan Pop
In said:
Yes, but only the first one needs to be. The second one is an expression
whose value is evaluated. Its lvalueness is irrelevant.
Nope. Attempting to take its address would fail. But, according to the
broken definition of lvalue in the C99 standard, it is an lvalue, one that
when evaluated, does not designate any object.
An object is what the standard says it is. An expression is NEVER an
object, but some expressions (involving pointer dereferencing) can be
lvalues *designating* objects.
Nope: it doesn't designate any object. There are two ways of creating
objects in C: by defining them and by dynamically allocating them.
(int *)3 creates a pointer value, but, unless this pointer value
accidentally happens to be the address of an object created by one of the
two methods mentioned above, it is an invalid pointer value and
dereferencing it invokes undefined behaviour:
fangorn:~/tmp 59> cat test.c
int main() { return *((int *)3); }
fangorn:~/tmp 60> gcc test.c
fangorn:~/tmp 61> ./a.out
Segmentation fault
Nevertheless, there are cases when creating such pointer values is
necessary and their usage, although technically still invoking undefined
behaviour, allows people to solve real life programming problems. It's
just that the integer value converted to a pointer value is not
arbitrarily but very carefully chosen: e.g. the address of a memory
mapped I/O register or of the buffer of a network adapter etc. There is
still no C object behind it, but the program behaves as if it were one,
if the value and the type are correctly chosen.
As this makes sense only in OS kernel code (or in freestanding
applications), most people don't get exposed to this kind of C
programming problems, but keep in mind that C was designed specifically
for the purpose of implementing an OS kernel.
Dan
J
Joe Wright
pete said:
Thank you pete. If we accept 'int' as object type, not function, not
incomplete, do we conclude that all int thingys are objects?
Consider the expression 'getchar()'. Its type is int. Is it an
object? No.
J
Joe Wright
Mantorok said:
I have done. Thank you.
J
Joe Wright
Irrwahn said:
Not an object, 3 is a value of type int. Simpler.
P
pete
Joe said:
Object types apply to constant expressions
and also to other expressions which don't reference objects,
as well as to expressions which do reference objects.