Pointer Guide

[Foobarius Frobinium]

Please review this guide for clarity, accuracy, etc. so I can
hopefully compile a very good tutorial on how to use pointers in C,
including advanced topics, that is easy to follow and exposes the
details.

http://thelinuxlink.net/~fingolfin/pointer-guide/

My e-mail address is fake. To really contact me, send mail to:
fi***********************@thelinuxlink.net, subtracting the blatant
anti-spam component.

--
I'm so happy
'Cause today I found my friends
They're in my head

-- Kurt Cobain

[Arthur J. O'Dwyer]

On Fri, 18 Jun 2004, Foobarius Frobinium wrote:

Please review this guide for clarity, accuracy, etc. so I can
hopefully compile a very good tutorial on how to use pointers in C,
including advanced topics, that is easy to follow and exposes the
details.

http://thelinuxlink.net/~fingolfin/pointer-guide/

Your use of "lvalue" and "rvalue" is slightly non-standard, but
IMO consistent enough. The usual terminology would have it
that an /expression/ /is/ an lvalue or an rvalue, depending on
whether the expression denotes an object with an /address/.
You use "lvalue" to mean /address/, and "rvalue" to mean
/value/. Consistent enough, but irking to pedants.

The HTMLification of the first sample program, the one that
begins '/* vim:ts=4 */', is absolutely unreadable on a white
background (the default in most GUI web browsers). Do not
use light green or cyan text on a white background. Prefer
no coloration, especially since you can't seem to decide on
a consistent scheme: why is 'fprintf' black but 'stdout'
magenta, for example?

HTML could be used to great advantage in the body text of
the tutorial, however. Consider bolding new terms on their
first appearance, to make it easier to skim the large
paragraphs; and I recommend using <tt></tt> or <i></i>
around code snippets in the text such as 'foo' and 'frob'.

The line '/* vim:ts=4 */' is completely unnecessary to
your tutorial, BTW, and will only confuse non-Unix types.
Suggest removing the hard tabs from your HTML source code
as well, since I doubt many browsers can effectively deal
with them. Suggest the use of <pre> to format source code.

Suggest 'return 0;' from 'main'. This is not required
by C99, but is a good practice in both C90 and C99. And
you are supposedly writing to instill good practices in
newbies...

"Therefore, the return type of *bar is int..." Delete
the word "return" from this sentence; operators /yield/
values. Functions /return/. Unary * is not a function,
and thus /returns/ nothing.

"The relevance of them will be revealed yet..." Insert
"not" before "be," of course.

s/interchangably/interchangeably/

"And since char's are one byte in length (at least on
all systems I know)..." 'sizeof(char)' is 1 (byte) by
definition. Whether any particular "system" has a
machine-level concept of "byte" is not relevant to C
programming. But then neither is using actual numbers
to refer to "addresses in RAM," so you'll just have to
pick a wording that will satisfy the pedants. Suggest
simply removing the parenthetical comment.

"...in short it is a data type that is made to
reference other data through its lvalue." Confusing.
Firstly, 'short' is a data type, so you've just majorly
confused the skimmers, who aren't paying much attention
to your grammatical flourishes. Secondly, either your
grammar or your content is wrong in the second half of
that sentence; a pointer is an object which references
other data through its "rvalue" (its /value/), or
equivalently a pointer /contains/ another datum's "lvalue"
(its /address/).

"The data an array accesses cannot be changed.
Therefore they are not pointers." Grammar strikes again!
First, the data accessed by an array *can* be changed;
consider 'arr[0] = 42; arr[0] = 43;'. Secondly, the
data accessed by an array *can* be pointers; consider
'int *arp[10];'. You mean, "An array cannot be changed
to 'point' to other data; therefore arrays are not pointers."

s/syntax sugar/syntactic sugar/

Your HTMLification is screwed up majorly in "Basic
Pointer Arithmetic," where it actually "eats" the 'for'
keyword in your loop. Yet another reason to drop the
colorization.

"When you add a number to a number type, such as an int
or double, you get straight addition. But when you do it on
pointers, the number is automatically multiplied by the size
(in bytes) of the type to which the pointer points." This
is how it's usually explained, true. But your lead-in is
somewhat silly, since you never say what you mean by "straight
addition." Obviously the machine code for adding 1 to a
pointer is different from that for adding 1 to an 'int';
but the machine code for adding 1 to a 'double' is often
*far* more complicated. Yet you call the latter two "straight"
addition! IMO it would make more sense simply to tell the
reader that addition on pointers is /defined/ the way it
is, and let them determine for themselves whether it's
weird or not.

s/deference/dereference/

"...the arithmetic operators take precedence over pointer
[dereference] anyway..." This is just flat-out /wrong/.
Remove it, and the surrounding misdirection.

Finally, although the tutorial is obviously not yet
completed, I must urge you to add material on the []
indirection operator. The reader is currently left thinking
that '*(kochba+i)' is the only way to dereference a pointer.
[On a lighter note, I must say I've never seen 'kochba' used
as the third element of 'foo, bar,...'! Very... quirky.]
HTH,
-Arthur

[Foobarius Frobinium]

"Arthur J. O'Dwyer" <aj*@nospam.andrew.cmu.edu> wrote in message news:<Pi**********************************@unix47. andrew.cmu.edu>...

On Fri, 18 Jun 2004, Foobarius Frobinium wrote:

Please review this guide for clarity, accuracy, etc. so I can
hopefully compile a very good tutorial on how to use pointers in C,
including advanced topics, that is easy to follow and exposes the
details.

http://thelinuxlink.net/~fingolfin/pointer-guide/

<snip rest of useful, verbose critique>
"...the arithmetic operators take precedence over pointer
[dereference] anyway..." This is just flat-out /wrong/.
Remove it, and the surrounding misdirection.
They don't?? I woulda sworn they did...damn, I'll have to check. Maybe
something is wrong with gcc, but maybe I was just being stupid

Finally, although the tutorial is obviously not yet
completed, I must urge you to add material on the []
indirection operator. The reader is currently left thinking
that '*(kochba+i)' is the only way to dereference a pointer.
[On a lighter note, I must say I've never seen 'kochba' used
as the third element of 'foo, bar,...'! Very... quirky.]
Yes, the very next thing I was planning was how the [] form works, and
tie that back into the equivalency of arrays and pointers. As for
'kochba', any Jewish hackers you might know might be able to tell you
of Simeon Bar Kochba, who invented subsurface operations as an element
of guerilla warfare (i.e., Whack-A-Guerilla), 1800 years before Dien
Bien Phu. It's true!

Quirkiness in amidst hopefully useful data is all part of my
adolescent inanities, and probably makes the reading a little easier.

HTH,
-Arthur

[Jack Klein]

On 18 Jun 2004 12:07:20 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote in comp.lang.c:

Please review this guide for clarity, accuracy, etc. so I can
hopefully compile a very good tutorial on how to use pointers in C,
including advanced topics, that is easy to follow and exposes the
details.

http://thelinuxlink.net/~fingolfin/pointer-guide/

My e-mail address is fake. To really contact me, send mail to:
fi***********************@thelinuxlink.net, subtracting the blatant
anti-spam component.

I disagree with Arthur. You have this in the first paragraph:

"The lvalue is the variable's address in memory, and the rvalue is the
actual content of the variable."

You completely misunderstand the concepts of lvalues and rvalues in C.

In the snippet:

int x;
x = 3;

....the integer constant literal '3' is an rvalue that has nothing at
all to do with any variable.

The C standard defines the term 'lvalue' in part of a single sentence:

"An lvalue is an expression with an object type or an incomplete type
other than void" [6.3.2.1 P. 1]

Notice that the neither of the words 'address' or 'variable' appear in
this definition.

Also note that the C standard has dropped the word 'rvalue' from the
official terms of the language. It is mentioned only in a footnote:

"What is sometimes called ‘‘rvalue’’ is in this International Standard
described as the ‘‘value of an expression’’" [Footnote 53]

Just a little bit later, in your second sentence, you say:

"A pointer is a variable whose rvalue is the lvalue of another
variable."

This is just plain wrong. The value of a pointer object is an
'address'. A pointer object itself is an lvalue. The address that it
contains is not any sort of lvalue. Performing a dereference on a
pointer (other than pointer to void) creates an expression with an
object type, so *p is an lvalue expression.

Saying that the value of a pointer is an lvalue is like saying that
the value of an int is an lvalue.

Consider:

int x = 3;

....'x' is an lvalue, and has the value 3.

Now let's add:

int *ip = &x;

....'*ip' is an lvalue, which is an expression of object type (type
int) with the value of 'x', namely 3.

....'ip' is an lvalue, an expression of object type (type pointer to
int) with the value address of 'x'.

But the contents of 'ip', namely the address of x, is not an lvalue,
anymore than the contents of 'x', namely the integer value 3, is.

Have you actually obtained and read a copy of the ISO C Standard? The
PDF version is available for $18.00 US from ANSI. Until you do, I
seriously suggest you stop trying to write about things like lvalues
and rvalues, because you do not know their actual definitions and the
result is just plain incorrect.

--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++
http://www.contrib.andrew.cmu.edu/~a...FAQ-acllc.html

[Mark Richards]

Jack,

I was very interested in reading this Pointer Guide, since I need a few.
Perhaps I should stick to K&R for now, but I'm tempted to give this a
read. Would it lead me too far astray?

I noticed on your web page http://jk-technology.com/c/standards.html#c99
that you mention a new book was in process by Dr. Bjarne Stroustrup. Do
you happen to know if it has been published yet, and if so by whom?

Mark Richards

[Old Wolf]

Jack Klein <ja*******@spamcop.net> wrote:

In the snippet:

int x;
x = 3;

...the integer constant literal '3' is an rvalue that has nothing at
all to do with any variable.

The C standard defines the term 'lvalue' in part of a single sentence:

"An lvalue is an expression with an object type or an incomplete type
other than void" [6.3.2.1 P. 1]

'3' is an expression, it has type "int", and an int is an object,
therefore it is an expression with an object type. So your quote
seems to say that '3' is an lvalue. Where have I gone wrong..

[tweak]

Mark Richards wrote:

Jack,

I was very interested in reading this Pointer Guide, since I need a few.
Perhaps I should stick to K&R for now, but I'm tempted to give this a
read. Would it lead me too far astray?

I noticed on your web page http://jk-technology.com/c/standards.html#c99
that you mention a new book was in process by Dr. Bjarne Stroustrup. Do
you happen to know if it has been published yet, and if so by whom?

Mark Richards

The two places I learned pointers were:

1) K&R2

and

2) A Tutorial on Pointers and Arrays in C by Ted Jensen (which is like
reading K&R2 with expanded examples). The last url I have for this
document is: http://pweb.netcom.com/~tjensen/ptr/cpoint.htm

And thanks to all the folks here who helped me with restrict.

Cheers,

Brian

[Mark McIntyre]

On 19 Jun 2004 20:50:49 -0700, in comp.lang.c , ol*****@inspire.net.nz (Old
Wolf) wrote:

Jack Klein <ja*******@spamcop.net> wrote:

In the snippet:

int x;
x = 3;

...the integer constant literal '3' is an rvalue that has nothing at
all to do with any variable.

The C standard defines the term 'lvalue' in part of a single sentence:

"An lvalue is an expression with an object type or an incomplete type
other than void" [6.3.2.1 P. 1]
'3' is an expression, it has type "int", and an int is an object,
therefore it is an expression with an object type. So your quote
seems to say that '3' is an lvalue.

if '3' were an lvalue, you could put it on the left of an expression
3 = x+2;
so you know your interpretation is wrong. <aside>this is a slight
exaggeration</aside>
Where have I gone wrong..

You have applied "all ducks have feet, therefore all feet belong to ducks"
logic.

Because an object can have type int, it does not follow that all things of
type int are objects. You can have constants of type int. A constant need
not be a region of data storage, it could be built into the machine code of
the program (and often is).
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---
----== Posted via Newsfeed.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeed.com The #1 Newsgroup Service in the World! >100,000 Newsgroups
---= 19 East/West-Coast Specialized Servers - Total Privacy via Encryption =---

[xarax]

"Mark McIntyre" <ma**********@spamcop.net> wrote in message
news:aq********************************@4ax.com...

On 19 Jun 2004 20:50:49 -0700, in comp.lang.c , ol*****@inspire.net.nz (Old
Wolf) wrote:

Jack Klein <ja*******@spamcop.net> wrote:

In the snippet:

int x;
x = 3;

...the integer constant literal '3' is an rvalue that has nothing at
all to do with any variable.

The C standard defines the term 'lvalue' in part of a single sentence:

"An lvalue is an expression with an object type or an incomplete type
other than void" [6.3.2.1 P. 1]

'3' is an expression, it has type "int", and an int is an object,
therefore it is an expression with an object type. So your quote
seems to say that '3' is an lvalue.

if '3' were an lvalue, you could put it on the left of an expression
3 = x+2;
so you know your interpretation is wrong. <aside>this is a slight
exaggeration</aside>

Where have I gone wrong..

You have applied "all ducks have feet, therefore all feet belong to ducks"
logic.

Because an object can have type int, it does not follow that all things of
type int are objects. You can have constants of type int. A constant need
not be a region of data storage, it could be built into the machine code of
the program (and often is).
--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.com/ms3/bchambless0/welcome_to_clc.html>

I just use a very naive definition that seems to
work for me in most cases:

1. "lvalue"; the "l" (lower case ell) means "left". It's
something that can appear on the left side of an assignment.

2. "rvalue"; the "r" means "right". It's something that
can *only* appear on the right side of an assignment (an
expression that doesn't satisfy the requirements for lvalue).

The compiler will tell me when I get it wrong. That's
good enough for me.
--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS for FREE!

[Ralmin]

"Old Wolf" <ol*****@inspire.net.nz> wrote:

'3' is an expression, it has type "int", and an int is
an object, therefore it is an expression with an object
type. So your quote seems to say that '3' is an lvalue.
Where have I gone wrong..

You went wrong where you said an int is an object. Expressions of type int
do not necessarily refer to objects.

An integer constant between -32767 and 32767 is guaranteed to be of type
int. An integer constant from -2147483647 to -32768, or from 32768 to
2147483647 is guaranteed to be of type int if it fits in an int, otherwise
of type long.

An exception: Take as an example the expression -32768, which is actually
the integer constant 32768 which is then negated. Consider a 2's complement
system where int is 16 bits. Because the value of positive 32768 does not
fit into an int, it is given type long. Then, when negated, it still has
type long despite that the value now does fit into an int.

On Borland's Turbo C (a 16-bit MS-DOS compiler):
sizeof(-32768) == 4
sizeof(-32767-1) == 2

--
Simon.

[Old Wolf]

"xarax" <xa***@email.com> wrote:

I just use a very naive definition that seems to
work for me in most cases:

1. "lvalue"; the "l" (lower case ell) means "left". It's
something that can appear on the left side of an assignment.

2. "rvalue"; the "r" means "right". It's something that
can *only* appear on the right side of an assignment (an
expression that doesn't satisfy the requirements for lvalue).

The compiler will tell me when I get it wrong. That's
good enough for me.

That isn't much of a 'definition'. In fact it's wrong: the name
of an array is an lvalue but it can't appear on the left side of
an assignment. Your definition is circular, ie. it doesn't help
one whit in determining whether an expression is an lvalue or not.
The standard says that an assignment consists of
(modifiable-lvalue) = (expression)
.. This depends on modifiable-lvalue already being defined.

Your 'definition' is better called 'empirical method for determining',
and has another problem in that many compilers allow assignments to
non-lvalues in some cases.

[Chris Dollin]

Old Wolf wrote:

"xarax" <xa***@email.com> wrote:

I just use a very naive definition that seems to
work for me in most cases:

1. "lvalue"; the "l" (lower case ell) means "left". It's
something that can appear on the left side of an assignment.

2. "rvalue"; the "r" means "right". It's something that
can *only* appear on the right side of an assignment (an
expression that doesn't satisfy the requirements for lvalue).

The compiler will tell me when I get it wrong. That's
good enough for me.

That isn't much of a 'definition'.

It's pretty nearly *the* definition (apart from the "only"); the
lvalue is what you get when you evaluate as per the lhs of an
expression, the rvalue is what you get when you evaluate as per the
rhs. That's what Strachey meant when he introduced the terms. All
the nitpickery is just formalising it, usually for specific languages.

Of course for languages like Pop11 the terminology breaks down
somewhat ...

[Pop assignments run left-to-right, eg `42 -> x`, and the notion of
`lvalue` is not so much `address` as `procedure`, since the target
can be a procedure call eg `17 -> hd(someList)`.]

--
Chris "electric hedgehog" Dollin
C FAQs at: http://www.faqs.org/faqs/by-newsgrou...mp.lang.c.html
C welcome: http://www.angelfire.com/ms3/bchambl...me_to_clc.html

[Jeremy Yallop]

Old Wolf wrote:

Jack Klein <ja*******@spamcop.net> wrote:

The C standard defines the term 'lvalue' in part of a single sentence:

"An lvalue is an expression with an object type or an incomplete type
other than void" [6.3.2.1 P. 1]

'3' is an expression, it has type "int", and an int is an object,
therefore it is an expression with an object type. So your quote
seems to say that '3' is an lvalue.

I think that's basically correct according to the wording of the
standard (although you should perhaps change "and an int is an object"
to "and int is an object type").

The notion of "lvalue", while intuitively pretty clear, seems
surprisingly difficult to pin down satisfactorily. In K&R 1 "lvalue"
was defined by the grammar, so "lvalueness" could be determined during
the earliest stages of compilation.

(something like)

lvalue ::= identifier
* identifier
expression[expression]
( lvalue )

The first C standard ("C89") introduced a new definition of "lvalue"
that postponed the decision as to whether a particular expression is
an lvalue until runtime:

An lvalue is an expression (with an object type or an incomplete
type other than void) that designates an object.

Consider the program

int main(int argc, char **argv)
{
argv[2];
}

Does the expression argv[2] "designate an object"? The answer depends
on the arguments passed to the program, so in some runs of the program
the expression is an lvalue, and in some it is not (and invokes
undefined behaviour by attempting to access elements outside of the
array).

The last C standard ("C99") changed the definition yet again to the
wording Jack quoted above:

An lvalue is an expression with an object type or an incomplete type
other than void

For better or worse, the effect has been to move the test for
"lvalueness" to somewhere between where the previous definitions
placed it: to the time when types are associated with expressions and
checked for consistency. In C99 whether a particular expression is an
lvalue -- i.e. whether it is an "expression with an object type"
&c. -- cannot be determined by the BNF grammar, because the grammar
contains no information about types. Further, unlike in C89, there is
no need to wait until runtime, because, C being "statically typed",
the type of every expression in C is determined during translation.
As a result, the expression "argv[2]" in the program above, which is
/sometimes/ an lvalue under the C89 definition, is /always/ an lvalue
according to the C99 rules.

A side effect, then, of the new definition is that certain expressions
that do not always refer to objects -- and some which never do -- are
now considered lvalues. Unfortunately, the new wording appears to be
a little too broad, and now encompasses expressions which not only
/do/ not refer to objects (which was an unavoidable consequence of
moving the "lvalueness test" from runtime to translation-time), but
which /cannot/ (e.g. the integer literal '3' in your example).

Jeremy.

[Dan Pop]

In <84**************************@posting.google.com > ol*****@inspire.net.nz (Old Wolf) writes:

Jack Klein <ja*******@spamcop.net> wrote:

In the snippet:

int x;
x = 3;

...the integer constant literal '3' is an rvalue that has nothing at
all to do with any variable.

The C standard defines the term 'lvalue' in part of a single sentence:

"An lvalue is an expression with an object type or an incomplete type
other than void" [6.3.2.1 P. 1]

'3' is an expression, it has type "int", and an int is an object,
therefore it is an expression with an object type. So your quote
seems to say that '3' is an lvalue. Where have I gone wrong..

Nowhere. 3 *is* an lvalue in C99, period. The C89 definition was

An lvalue is an expression (with an object type or an incomplete
type other than void) that designates an object.

Which was simple, clear and made sense.

The full C99 version is:

1 An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an
object when it is evaluated, the behavior is undefined.

Which is actually the traditional definition of rvalue! It's still simple
and clear, it just doesn't make any sense ;-)

The practical implications are insignificant, however, as the standard
is carefully written to overrule the usage of 3 in any place where a C89
lvalue is actually required. And if the committee forgot to fix
the wording to match the new definition in one place or another,
undefined behaviour is covering the effects of the mistake ;-)

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Old Wolf]

Jeremy Yallop <je****@jdyallop.freeserve.co.uk> wrote:

Old Wolf wrote:

Jack Klein <ja*******@spamcop.net> wrote:

The C standard defines the term 'lvalue' in part of a single sentence:

"An lvalue is an expression with an object type or an incomplete type
other than void" [6.3.2.1 P. 1]

'3' is an expression, it has type "int", and an int is an object,
therefore it is an expression with an object type. So your quote
seems to say that '3' is an lvalue.

I think that's basically correct according to the wording of the
standard (although you should perhaps change "and an int is an object"
to "and int is an object type").

A side effect, then, of the new definition is that certain expressions
that do not always refer to objects -- and some which never do -- are
now considered lvalues. Unfortunately, the new wording appears to be
a little too broad, and now encompasses expressions which not only
/do/ not refer to objects (which was an unavoidable consequence of
moving the "lvalueness test" from runtime to translation-time), but
which /cannot/ (e.g. the integer literal '3' in your example).

Just after that quote (in N869 at least) is:

A modifiable lvalue is an lvalue that does not
have array type, does not have an incomplete type, does not
have a const-qualified type, and if it is a structure or
union, does not have any member (including, recursively, any
member or element of all contained aggregates or unions)
with a const-qualified type.

'3' has type "int" (not "int const"). So '3' is actually a modifiable
lvalue. The only constraint on the left-operand of an assignment
(or the operand of ++ or --) is that it is a modifiable lvalue.

So I guess this means that a C99 conforming compiler doesn't have to
issue any diagnostic for:
3++;
or
3 = 4;

[J. J. Farrell]

Mark McIntyre <ma**********@spamcop.net> wrote in message news:<aq********************************@4ax.com>. ..

On 19 Jun 2004 20:50:49 -0700, in comp.lang.c , ol*****@inspire.net.nz (Old
Wolf) wrote:

Jack Klein <ja*******@spamcop.net> wrote:

In the snippet:

int x;
x = 3;

...the integer constant literal '3' is an rvalue that has nothing at
all to do with any variable.

The C standard defines the term 'lvalue' in part of a single sentence:

"An lvalue is an expression with an object type or an incomplete type
other than void" [6.3.2.1 P. 1]

'3' is an expression, it has type "int", and an int is an object,
therefore it is an expression with an object type. So your quote
seems to say that '3' is an lvalue.

if '3' were an lvalue, you could put it on the left of an expression
3 = x+2;
so you know your interpretation is wrong. <aside>this is a slight
exaggeration</aside>

Where have I gone wrong..

You have applied "all ducks have feet, therefore all feet belong to ducks"
logic.

Because an object can have type int, it does not follow that all things of
type int are objects. You can have constants of type int. A constant need
not be a region of data storage, it could be built into the machine code of
the program (and often is).

I think Old Wolf is right here. Mark's talking Common Sense whereas
Old Wolf is talking The Standard - they often do not go together.

C89 is clear that an lvalue designates an object. This has been
changed in C99, and I doubt very much that it is supposed to mean
what it appears to say.

6.3.2.1 Lvalues, arrays, and function designators

An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an object
when it is evaluated, the behavior is undefined.

It seems clear that an expression such as 3+5 is an lvalue, since
it is an expression with an object type (as opposed to a function
type or an incomplete type, those being the three types of type
in C99). It also seems clear that

int i;

i = 3+5;

results in undefined behaviour, since it involves the evaluation
of an lvalue that does not designate an object.

I'm sure this isn't what the Standardizers meant, but it appears
to be what they've said. Can anyone show otherwise?

[Irrwahn Grausewitz]

jj*@bcs.org.uk (J. J. Farrell) wrote:

[about lvalues and rvalues]

C89 is clear that an lvalue designates an object. This has been
changed in C99, and I doubt very much that it is supposed to mean
what it appears to say.

6.3.2.1 Lvalues, arrays, and function designators

An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an object ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ when it is evaluated, the behavior is undefined. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
It seems clear that an expression such as 3+5 is an lvalue, since
it is an expression with an object type (as opposed to a function
type or an incomplete type, those being the three types of type
in C99).
While 3+5 is indeed an lvalue, it cannot legitimately be used as
such: it doesn't designate an object (in simple terms: you cannot
take its address). Remember: an expression that has object type
does not necessarily designate an object as well.
It also seems clear that

int i;

i = 3+5;

results in undefined behaviour, since it involves the evaluation
of an lvalue that does not designate an object.
Wrong. Of course the lvalue i designates an object, specifically
the one at the memory location &i.
I'm sure this isn't what the Standardizers meant, but it appears
to be what they've said. Can anyone show otherwise?

You missed C99 6.3.2.1p2:

2 Except when it is the operand of the sizeof operator, the unary &
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
operator, the ++ operator, the -- operator, or the left operand of
the . operator or an assignment operator, an lvalue that does not
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
have array type is converted to the value stored in the designated
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
object (and is no longer an lvalue).
^^^^^^

Hence, in i = 3+5; the left hand operand of the assignment operator
is *not* evaluated for the value, but for the designator.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Irrwahn Grausewitz]

Da*****@cern.ch (Dan Pop) wrote:

ol*****@inspire.net.nz (Old Wolf) writes:

Jack Klein <ja*******@spamcop.net> wrote:

In the snippet:

int x;
x = 3;

...the integer constant literal '3' is an rvalue that has nothing at
all to do with any variable.

The C standard defines the term 'lvalue' in part of a single sentence:

"An lvalue is an expression with an object type or an incomplete type
other than void" [6.3.2.1 P. 1]
'3' is an expression, it has type "int", and an int is an object,
No; int is a type.
therefore it is an expression with an object type.
That's correct. The expression 3 has the object type int, albeit it
does not designate an object. All objects are of object type, but not
all expressions with an object type designate objects as well.
So your quote
seems to say that '3' is an lvalue. Where have I gone wrong..

Nowhere. 3 *is* an lvalue in C99, period.

Agreed, but one that invokes undefined behaviour when used as such,
as per C99 6.3.2.1p1: "[...] if an lvalue does not designate an
object when it is evaluated, the behavior is undefined."
The C89 definition was

An lvalue is an expression (with an object type or an incomplete
type other than void) that designates an object.

Which was simple, clear and made sense.

The full C99 version is:

1 An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an
object when it is evaluated, the behavior is undefined.

Which is actually the traditional definition of rvalue!
I beg to disagree, since evaluation rvalues that do not designate
objects doesn't invoke undefined behaviour.
It's still simple
and clear, it just doesn't make any sense ;-)
Because it is incomplete: you omitted the evaluation rules in
6.3.2.1p2, which is the second part of the lvalue definition:

2 Except when it is the operand of the sizeof operator, the unary
& operator, the ++ operator, the -- operator, or the left
operand of the . operator or an assignment operator, an lvalue
that does not have array type is converted to the value stored
in the designated object (and is no longer an lvalue). If the
lvalue has qualified type, the value has the unqualified version
of the type of the lvalue; otherwise, the value has the type of
the lvalue. If the lvalue has an incomplete type and does not
have array type, the behavior is undefined.
The practical implications are insignificant, however, as the standard
is carefully written to overrule the usage of 3 in any place where a C89
lvalue is actually required.

Ideed, see quote above.

<snip>

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[Dan Pop]

In <51********************************@4ax.com> Irrwahn Grausewitz <ir*******@freenet.de> writes:

Da*****@cern.ch (Dan Pop) wrote:

The full C99 version is:

1 An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an
object when it is evaluated, the behavior is undefined.

Which is actually the traditional definition of rvalue!

I beg to disagree, since evaluation rvalues that do not designate
objects doesn't invoke undefined behaviour.

The *definition* stops at the semicolon.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[kal]

Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>...

Nowhere. 3 *is* an lvalue in C99, period.
It does not seem to me to be what the standard implies.
The C89 definition was

An lvalue is an expression (with an object type or an incomplete
type other than void) that designates an object.

Which was simple, clear and made sense.
Quite. lvalue is defined to be (a) An expression, and (b) the
value of which DESIGNATES an object. They key word here is
DESIGNATES.
The full C99 version is:

1 An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an
object when it is evaluated, the behavior is undefined.

This is precisely the same as the C89 definition, viz., an lvalue
is (a) an expression and, (b) the value of which must DESIGNATE
an object.

I am not in possession of a copy of the C99 standard. But in one
of the drafts of it the following are stated.

6.3.2.1 Lvalues and function designators

1 An lvalue is an expression with an object type or an incomplete
type other than void;(44) if an lvalue does not designate an
object when it is evaluated, the behavior is undefined. When an
object is said to have a particular type, the type is specified
by the lvalue used to designate the object. A modifiable lvalue
is an lvalue that does not have array type, does not have an
incomplete type, does not have a const-qualified type, and if it
is a structure or union, does not have any member (including,
recursively, any member or element of all contained aggregates
or unions) with a const-qualified type.

The footnote (44) provides some additional information.

(44) The name ‘‘lvalue'' comes originally from the assignment
expression E1 = E2, in which the left operand E1 is
required to be a (modifiable) lvalue. It is perhaps better
considered as representing an object ‘‘locator value''.
What is sometimes called ‘‘rvalue'' is in this International
Standard described as the ‘‘value of an expression''.

An obvious example of an lvalue is an identifier of an
object. As a further example, if E is a unary expression
that is a pointer to an object, *E is an lvalue that
designates the object to which E points.

[Dan Pop]

In <a5**************************@posting.google.com > k_*****@yahoo.com (kal) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>...

Nowhere. 3 *is* an lvalue in C99, period.

It does not seem to me to be what the standard implies.

Then, you're reading impaired.

The C89 definition was

An lvalue is an expression (with an object type or an incomplete
type other than void) that designates an object.

Which was simple, clear and made sense.

Quite. lvalue is defined to be (a) An expression, and (b) the
value of which DESIGNATES an object. They key word here is
DESIGNATES.

The full C99 version is:

1 An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ object when it is evaluated, the behavior is undefined.

^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is precisely the same as the C89 definition, viz., an lvalue
is (a) an expression and, (b) the value of which must DESIGNATE
an object.

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[kal]

Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>...

In <a5**************************@posting.google.com > k_*****@yahoo.com (kal) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>...

The full C99 version is:

1 An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ object when it is evaluated, the behavior is undefined.

^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is precisely the same as the C89 definition, viz., an lvalue
is (a) an expression and, (b) the value of which must DESIGNATE
an object.

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.

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

[Jeremy Yallop]

kal wrote:

>Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>...
>> The full C99 version is:
>>
>> 1 An lvalue is an expression with an object type or an incomplete
>> type other than void; if an lvalue does not designate an ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> object when it is evaluated, the behavior is undefined.

[...] 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." [...] OTOH I may just be muddled about the whole thing.
I am taking the word "object" to mean what it says in 3.15.

"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.

[Chris Torek]

In article <a5*************************@posting.google.com>
kal <k_*****@yahoo.com> writes:

I am afraid that I don't see 3 as an lvalue at all.
Jeremy Yallop already pointed out the distiction C99 has between
"object" and "object type".
My understanding is that 3 is a "value of type int" and
not a "value of object type int."

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.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) [phone]
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

[Joe Wright]

kal wrote:

Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>...

In <a5**************************@posting.google.com > k_*****@yahoo.com (kal) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>...
The full C99 version is:

1 An lvalue is an expression with an object type or an incomplete
type other than void; if an lvalue does not designate an

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

object when it is evaluated, the behavior is undefined.

^^^^^^^^^^^^^^^^^^^^^^^^^^^
This is precisely the same as the C89 definition, viz., an lvalue
is (a) an expression and, (b) the value of which must DESIGNATE
an object.

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.

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

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.

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

[pete]

Joe Wright wrote:

Values don't have object type. Only
expressions designating objects have object type.

~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.

[Foobarius Frobinium]

Jack Klein <ja*******@spamcop.net> wrote in message news:<sp********************************@4ax.com>. ..

On 18 Jun 2004 12:07:20 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote in comp.lang.c:

Please review this guide for clarity, accuracy, etc. so I can
hopefully compile a very good tutorial on how to use pointers in C,
including advanced topics, that is easy to follow and exposes the
details.

http://thelinuxlink.net/~fingolfin/pointer-guide/

My e-mail address is fake. To really contact me, send mail to:
fi***********************@thelinuxlink.net, subtracting the blatant
anti-spam component.

<snip>

Have you actually obtained and read a copy of the ISO C Standard? The
PDF version is available for $18.00 US from ANSI. Until you do, I
seriously suggest you stop trying to write about things like lvalues
and rvalues, because you do not know their actual definitions and the
result is just plain incorrect.

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.

--
"I'll start this off without any words
I got so high, I scratched till I bled
Love myself better than you
I know it's wrong, but what should I do?"

[Foobarius Frobinium]

Jack Klein <ja*******@spamcop.net> wrote in message news:<sp********************************@4ax.com>. ..

On 18 Jun 2004 12:07:20 -0700, fo******@youremailbox.com (Foobarius
Frobinium) wrote in comp.lang.c:
<snip>
Have you actually obtained and read a copy of the ISO C Standard? The
PDF version is available for $18.00 US from ANSI. Until you do, I
seriously suggest you stop trying to write about things like lvalues
and rvalues, because you do not know their actual definitions and the
result is just plain incorrect.

Well, I changed everything and made sure it was all in context. It
actually reads a little better now...

[Arthur J. O'Dwyer]

On Tue, 22 Jun 2004, Joe Wright wrote:

kal wrote:

Da*****@cern.ch (Dan Pop) wrote:

k_*****@yahoo.com (kal) writes:
Da*****@cern.ch (Dan Pop) wrote [in C99]>1 An lvalue is an expression with an object type or an incomplete
> type other than void; if an lvalue does not designate an
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> object when it is evaluated, the behavior is undefined.
^^^^^^^^^^^^^^^^^^^^^^^^^^^

The underlined text *explicitly* admits the existence
of lvalues that DO NOT designate objects. 3 is an example of such an
lvalue.
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."

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.
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.
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.

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

[Dan Pop]

In <a5*************************@posting.google.com> k_*****@yahoo.com (kal) writes:

Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>...

In <a5**************************@posting.google.com > k_*****@yahoo.com (kal) writes:

>Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>... >> The full C99 version is:
>>
>> 1 An lvalue is an expression with an object type or an incomplete
>> type other than void; if an lvalue does not designate an

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> object when it is evaluated, the behavior is undefined.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>This is precisely the same as the C89 definition, viz., an lvalue
>is (a) an expression and, (b) the value of which must DESIGNATE
>an object.

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.

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."

Please explain to the rest of us the difference between "type int" and
"object type int". Chapters and verses are welcome.

Dan
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Joe Wright]

Arthur J. O'Dwyer wrote:

On Tue, 22 Jun 2004, Joe Wright wrote:

kal wrote:

Da*****@cern.ch (Dan Pop) wrote:

k_*****@yahoo.com (kal) writes:

>Da*****@cern.ch (Dan Pop) wrote
[in C99]
1 An lvalue is an expression with an object type or an incomplete
>> type other than void; if an lvalue does not designate an

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

>> object when it is evaluated, the behavior is undefined.
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^

The underlined text *explicitly* admits the existence
of lvalues that DO NOT designate objects. 3 is an example of such an
lvalue.

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."

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.

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.

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.

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).

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.

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

[pete]

Joe Wright wrote:

Arthur J. O'Dwyer wrote: 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..

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).
--
pete

[Mantorok Redgormor]

Joe Wright <jo********@comcast.net> wrote in message news:<cP********************@comcast.com>...

Arthur J. O'Dwyer wrote:

On Tue, 22 Jun 2004, Joe Wright wrote:

kal wrote:

Da*****@cern.ch (Dan Pop) wrote:

>k_*****@yahoo.com (kal) writes:
>
>>Da*****@cern.ch (Dan Pop) wrote

[in C99]

>>>1 An lvalue is an expression with an object type or an incomplete
>>> type other than void; if an lvalue does not designate an
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>>> object when it is evaluated, the behavior is undefined.
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> The underlined text *explicitly* admits the existence
>of lvalues that DO NOT designate objects. 3 is an example of such an
>lvalue.

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."

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.

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.

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.

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).

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.

Please review the following thread:
http://groups.google.com/groups?q=co...n.co.uk&rnum=3

--
nethlek

[Irrwahn Grausewitz]

Joe Wright <jo********@comcast.net> wrote:

[about the C99 lvalue definition]

[...]

Nonsense. Quoting you [Arthur J. O'Dwyer] 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.
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).
Objects have type and values have
type but nothing about type 'int' suggests 'object' rather than
'value'.
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
Carefully now, consider..

#define THREE 3
int i;

The expressions 'THREE' and 'i' both have 'int' type. Only 'i' has
object type.

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
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html

[kal]

Da*****@cern.ch (Dan Pop) wrote in message news:<cb**********@sunnews.cern.ch>...

Please explain to the rest of us the difference between "type int" and
"object type int". Chapters and verses are welcome.

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?

[Dan Pop]

In <a5**************************@posting.google.com > k_*****@yahoo.com (kal) writes:

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?
Yes, but only the first one needs to be. The second one is an expression
whose value is evaluated. Its lvalueness is irrelevant.
Is "3" an object?
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.
Are all expressions objects?
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.
Is "*((int *)3)" an lvalue as per C89 standard?

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
--
Dan Pop
DESY Zeuthen, RZ group
Email: Da*****@ifh.de

[Joe Wright]

pete wrote:

Joe Wright wrote:

Arthur J. O'Dwyer wrote:

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..

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).

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.

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

[Joe Wright]

Mantorok Redgormor wrote:

Joe Wright <jo********@comcast.net> wrote in message news:<cP********************@comcast.com>...

Arthur J. O'Dwyer wrote:

On Tue, 22 Jun 2004, Joe Wright wrote:
kal wrote:
>Da*****@cern.ch (Dan Pop) wrote:
>
>
>>k_*****@yahoo.com (kal) writes:
>>
>>
>>>Da*****@cern.ch (Dan Pop) wrote

[in C99]
>>>>1 An lvalue is an expression with an object type or an incomplete
>>>> type other than void; if an lvalue does not designate an
>>
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>
>>>> object when it is evaluated, the behavior is undefined.
>>>
>>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>>The underlined text *explicitly* admits the existence
>>of lvalues that DO NOT designate objects. 3 is an example of such an
>>lvalue.
>
>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."

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.
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.

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.
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).

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.

Please review the following thread:
http://groups.google.com/groups?q=co...n.co.uk&rnum=3

I have done. Thank you.

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

[Joe Wright]

Irrwahn Grausewitz wrote:

Joe Wright <jo********@comcast.net> wrote:

[about the C99 lvalue definition]

[...]

Nonsense. Quoting you [Arthur J. O'Dwyer] 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.

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).

Objects have type and values have
type but nothing about type 'int' suggests 'object' rather than
'value'.

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

Carefully now, consider..

#define THREE 3
int i;

The expressions 'THREE' and 'i' both have 'int' type. Only 'i' has
object type.

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?

Not an object, 3 is a value of type int. Simpler.

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

[pete]

Joe Wright wrote:

pete wrote:

Joe Wright wrote:

Arthur J. O'Dwyer wrote:

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..

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).

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.

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.

--
pete

[Irrwahn Grausewitz]

Joe Wright <jo********@comcast.net> wrote:

Irrwahn Grausewitz wrote:

<snip>

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?

Not an object, 3 is a value of type int. Simpler.

But less useful for making my point, that's why I wrote it that way.

Regards
--
Irrwahn Grausewitz (ir*******@freenet.de)
welcome to clc: http://www.ungerhu.com/jxh/clc.welcome.txt
clc faq-list : http://www.faqs.org/faqs/C-faq/faq/
clc OT guide : http://benpfaff.org/writings/clc/off-topic.html