information
shabu
Richard Heathfield
<c4435629-109c-486b...@k17g2000yqb.googlegroups.com>,
shabu wrote:
> use of pointers
right
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within
lolguy
> use of pointers
pointers are used to pass addresses sometimes u want get more than one
information from a function then u can use ptrs there also linked list
and advanced data structures which need ptrs for them u should buy a
book and read about c its better that way u will learn more
Nick Keighley
> use of pointers
what about them?
Richard Heathfield
<d95ba094-1a14-45de...@a21g2000yqc.googlegroups.com>,
lolguy wrote:
> On Oct 1, 10:12 am, shabu <shabanazm...@gmail.com> wrote:
>> use of pointers
>
> pointers are used to pass addresses
Wrong. Pointers /are/ addresses. If you want to "pass" anything, use a
function call.
<snip>
Debanjan
> use of pointers
When you need to pass a pointer to an object or nothing. There are no
null references.
When you want to traverse a data structure.
When you need pointer arithmetic (should be rare except in low-level
code).
There are many other uses of pointers but the above cannot be
implemented with reference,(I know it's comp.lang.c)
Eric Sosman
> In
> <d95ba094-1a14-45de...@a21g2000yqc.googlegroups.com>,
> lolguy wrote:
>
>> On Oct 1, 10:12 am, shabu <shabanazm...@gmail.com> wrote:
>>> use of pointers
>> pointers are used to pass addresses
>
Wrong. Pointers are addresses /with types/.
--
Eric Sosman
eso...@ieee-dot-org.invalid
Richard Heathfield
> Richard Heathfield wrote:
>> In
>>
<d95ba094-1a14-45de...@a21g2000yqc.googlegroups.com>,
>> lolguy wrote:
>>
>>> On Oct 1, 10:12 am, shabu <shabanazm...@gmail.com> wrote:
>>>> use of pointers
>>> pointers are used to pass addresses
>>
>> Wrong. Pointers /are/ addresses. [...]
>
> Wrong. Pointers are addresses /with types/.
Wrong. Pointers are a kind of dog, bred to locate birds without
actually mauling them.
(Translation: I fold.)
Charles Richmond
> In
> <c4435629-109c-486b...@k17g2000yqb.googlegroups.com>,
> shabu wrote:
>
>> use of pointers
>
> right
>
<- -> pointers are your BFF EA EA ...
--
+----------------------------------------+
| Charles and Francis Richmond |
| |
| plano dot net at aquaporin4 dot com |
+----------------------------------------+
Charles Richmond
> Richard Heathfield wrote:
>> In
>> <d95ba094-1a14-45de...@a21g2000yqc.googlegroups.com>,
>> lolguy wrote:
>>
>>> On Oct 1, 10:12 am, shabu <shabanazm...@gmail.com> wrote:
>>>> use of pointers
>>> pointers are used to pass addresses
>>
>> Wrong. Pointers /are/ addresses. [...]
>
> Wrong. Pointers are addresses /with types/.
>
and in C, pointers have an associated implied length of the type
of data pointed to.
Eric Sosman
> [... good points about improving the Standard's wording ...]
> Eric Sosman <eso...@ieee-dot-org.invalid> writes:
>>> Wrong. Pointers /are/ addresses. [...]
>> Wrong. Pointers are addresses /with types/.
>
Yes, but an address without a type is not a pointer.
> For example, a suitcase is a container /with a handle/,
> but still a suitcase is a container, that is, the set
> of suitcases is a subset of the set of containers.
Yes, but a 55-gallon oil drum is not a suitcase, even
though it is clearly a container.
> The process of ignoring special properties of a given
> specimen (like the handle) is called �abstraction�.
Yes, but an abstract container is not a suitcase.
> Sometimes, abstraction is hard to handle for people;
> for example, a human being is a mammal, that is, an animal,
> but some people do not consider themself to be animals.
Grrr!
Eric Sosman
> Eric Sosman wrote:
>> Richard Heathfield wrote:
>>> In
>>> <d95ba094-1a14-45de...@a21g2000yqc.googlegroups.com>,
>>> lolguy wrote:
>>>
>>>> On Oct 1, 10:12 am, shabu <shabanazm...@gmail.com> wrote:
>>>>> use of pointers
>>>> pointers are used to pass addresses
>>>
>>> Wrong. Pointers /are/ addresses. [...]
>>
>> Wrong. Pointers are addresses /with types/.
>>
>
> and in C, pointers have an associated implied length of the type of data
> pointed to.
Right. That information comes from the type. So, too, does
the interpretation of the data found at (and near) the address:
union { int i; float f; } x;
int *ip = &x.i;
float *fp = &x.f;
Now ip and fp hold the same address (they "compare equal"), and on
machines where sizeof(int)==sizeof(float) they "refer" to the same
batch of bytes, yet the effects of *ip=42 and *fp=42 are different.
Keith Thompson
> Richard Heathfield wrote:
>> In
>> <d95ba094-1a14-45de...@a21g2000yqc.googlegroups.com>,
>> lolguy wrote:
>>
>>> On Oct 1, 10:12 am, shabu <shabanazm...@gmail.com> wrote:
>>>> use of pointers
>>> pointers are used to pass addresses
>>
>> Wrong. Pointers /are/ addresses. [...]
>
> Wrong. Pointers are addresses /with types/.
Addresses have types; that's how C defines the word "address".
"Address of foo" and "pointer to foo" are synonymous.
N1256 6.5.2.3p3:
The unary & operator yields the address of its operand. If the
operand has type ‘‘type’’, the result has type ‘‘pointer to
type’’.
(C99 had "returns" rather than "yields".)
For example, &arr is not the same as &arr[0]; one is the address of an
array object, the other is the address of an element of that array
object.
--
Keith Thompson (The_Other_Keith) ks...@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
Keith Thompson
> Eric Sosman wrote:
>> Richard Heathfield wrote:
>>> In
>>> <d95ba094-1a14-45de...@a21g2000yqc.googlegroups.com>,
>>> lolguy wrote:
>>>
>>>> On Oct 1, 10:12 am, shabu <shabanazm...@gmail.com> wrote:
>>>>> use of pointers
>>>> pointers are used to pass addresses
>>>
>>> Wrong. Pointers /are/ addresses. [...]
>>
>> Wrong. Pointers are addresses /with types/.
>
> and in C, pointers have an associated implied length of the type of
> data pointed to.
A pointer value must be of some specific pointer type. That pointer
type is associated with the *type* (not just the length) of the object
pointed to.
Andrey Tarasevich
> Stefan Ram wrote:
>> [... good points about improving the Standard's wording ...]
>> Eric Sosman <eso...@ieee-dot-org.invalid> writes:
>>>> Wrong. Pointers /are/ addresses. [...]
>>> Wrong. Pointers are addresses /with types/.
>> An �address with a type� still is an address.
>
> Yes, but an address without a type is not a pointer.
>
As Keith correctly noted in one of his messages, in the official C
terminology, terms "address" and "pointer" are synonymous and mean
exactly the same thing.
Joe Wright
Such ambiguous usage is unfortunate. They are NOT the same. If you will consider
pointer an object and address a value which can be stored in a pointer, life
will take on new meaning for you and greater serenity.
The confusion comes, I believe, because both the object and the value share a
characteristic type. Consider the following.
int *p, i = 5;
p = &i;
p is a pointer to int, i is an int and &i is the address of i. The address of i
has pointer type but it is a value, not a pointer.
--
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
Keith Thompson
> Andrey Tarasevich wrote:
>> Eric Sosman wrote:
>>> Stefan Ram wrote:
>>>> [... good points about improving the Standard's wording ...]
>>>> Eric Sosman <eso...@ieee-dot-org.invalid> writes:
>>>>>> Wrong. Pointers /are/ addresses. [...]
>>>>> Wrong. Pointers are addresses /with types/.
>>>> An »address with a type« still is an address.
>>>
>>> Yes, but an address without a type is not a pointer.
>>
>> As Keith correctly noted in one of his messages, in the official C
>> terminology, terms "address" and "pointer" are synonymous and mean
>> exactly the same thing.
>
> Such ambiguous usage is unfortunate. They are NOT the same. If you
> will consider pointer an object and address a value which can be
> stored in a pointer, life will take on new meaning for you and greater
> serenity.
Perhaps so, but you'll be using the words in a manner that's
inconsistent with the standard's usage, which is likely to lead
to confusion.
As far as I know, there's no ambiguity in the standard's usage
of the words; it just uses them in a way that's inconsistent with
they way you'd like them to be defined. (And I probably agree that
your way is better, but I find consistency with the standard to be
more important.)
Note that a "null pointer" is clearly a pointer *value*, not
necessarily a pointer object. Note also that the standard says
that malloc() "returns either a null pointer or a pointer to the
allocated space"; again, this is a value, not an object.
(Yes, I'm just restating what the standard says.)
> The confusion comes, I believe, because both the object and the value
> share a characteristic type. Consider the following.
>
> int *p, i = 5;
> p = &i;
>
> p is a pointer to int, i is an int and &i is the address of i. The
> address of i has pointer type but it is a value, not a pointer.
But if you say that it is a pointer (value), that's equally consisetnt.
Andrey Tarasevich
> Andrey Tarasevich wrote:
>> Eric Sosman wrote:
>>>> Eric Sosman <eso...@ieee-dot-org.invalid> writes:
>>>>>> Wrong. Pointers /are/ addresses. [...]
>>>>> Wrong. Pointers are addresses /with types/.
>>>> An »address with a type« still is an address.
>>> Yes, but an address without a type is not a pointer.
>>>
>> As Keith correctly noted in one of his messages, in the official C
>> terminology, terms "address" and "pointer" are synonymous and mean
>> exactly the same thing.
>
> Such ambiguous usage is unfortunate. They are NOT the same. If you will consider
> pointer an object and address a value which can be stored in a pointer, life
> will take on new meaning for you and greater serenity.
If _I_ will consider... Well, yes, but, once again, for better or worse,
the distinction you are referring to does not take place in the formal C
terminology. At least not in the above form.
On the one hand, it is perfectly valid to refer to a value (i.e.
"non-Lvalue") of pointer type as a "pointer", even though it is not an
object.
On the other hand, (I have to admit) I can't see how the term "address"
can be used to refer to pointer objects themselves (as opposed to
pointer values stored in those objects).
So, I agree, the distinction between "pointers" and "addresses" does
exist, although it is not as straightforward as you are trying to
represent it.
--
Best regards,
Andrey Tarasevich
Tim Rentsch
Actually I think they are used with slightly different
meanings. An "address" is an abstract quantity that
identifies a memory location, and a pointer is a
representation of such a location identifier that can be
maniuplated programmatically. Very much like the
distinction between "integer" and "int".
Richard
Meanwhile in the real world some people do nothing but sow confusion
and delay real work. In C a pointer is an address in each and every
project and company I worked for. No one was *ever once* confused.
It is the address of a piece of memory. EOS. It Points that
memory. EOS. It is dereferenced meaning its also fine to refer to a
pointer as an address or a reference (in C).
This ridiculous semantic games in c.l.c are a hindrance to many.
--
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
Tim Rentsch
I'm not advocating or defending the usage in the Standard,
only trying to explain what it is.
Joe Wright
> Joe Wright <joeww...@comcast.net> writes:
>> Andrey Tarasevich wrote:
>>> Eric Sosman wrote:
>>>> Stefan Ram wrote:
>>>>> [... good points about improving the Standard's wording ...]
>>>>> Eric Sosman <eso...@ieee-dot-org.invalid> writes:
>>>>>>> Wrong. Pointers /are/ addresses. [...]
>>>>>> Wrong. Pointers are addresses /with types/.
think we're better off agreeing that functions might return pointers. That's a
widely shared opinion and you are welcome to it. Not me.
The Standard is Standard of course. Not flawless, certainly.
I don't demand that you or anyone agree with me. (It would be nice..)
Keith Thompson
[...]
> You and I Keith, have had this very discussion before. You agree with
> me but think we're better off agreeing that functions might return
> pointers. That's a widely shared opinion and you are welcome to
> it. Not me.
>
> The Standard is Standard of course. Not flawless, certainly.
>
> I don't demand that you or anyone agree with me. (It would be nice..)
I'm still not 100% clear on what opinion you hold. Perhaps if I
were, we could avoid having this discussion yet again.
The standard says that, for example, malloc() returns a pointer.
It's not reasonably possible to disagree with that; that's just
what the standard says. That has implications about what the word
"pointer", as used by the standard, means. It's hardly the only case
where the standard uses a word with a meaning that's inconsistent
with the way it's commonly used elsewhere (byte, object, etc.).
I presume you agree with this.
Clearly words can have different meanings in different contexts.
"Pointer" can refer to a dog or to a stick, for example.
I *think* you're saying that you dislike the way the standard uses
the word "pointer". Is that a fair summary? If so, I couldn't
possibly disagree with you; only you can know what you dislike.
Can you state, ideally in one short and unambiguous sentence,
just what your opinion is that you think I disagree with?
Joe Wright
> Joe Wright wrote:
>> Andrey Tarasevich wrote:
>>> Eric Sosman wrote:
>>>>> Eric Sosman <eso...@ieee-dot-org.invalid> writes:
>>>>>>> Wrong. Pointers /are/ addresses. [...]
>>>>>> Wrong. Pointers are addresses /with types/.
>>>> Yes, but an address without a type is not a pointer.
>>>>
>>> As Keith correctly noted in one of his messages, in the official C
>>> terminology, terms "address" and "pointer" are synonymous and mean
>>> exactly the same thing.
>>
>> Such ambiguous usage is unfortunate. They are NOT the same. If you
>> will consider pointer an object and address a value which can be
>> stored in a pointer, life will take on new meaning for you and greater
>> serenity.
>
> If _I_ will consider... Well, yes, but, once again, for better or worse,
> the distinction you are referring to does not take place in the formal C
> terminology. At least not in the above form.
>
> On the one hand, it is perfectly valid to refer to a value (i.e.
> "non-Lvalue") of pointer type as a "pointer", even though it is not an
> object.
>
> On the other hand, (I have to admit) I can't see how the term "address"
> can be used to refer to pointer objects themselves (as opposed to
> pointer values stored in those objects).
>
> So, I agree, the distinction between "pointers" and "addresses" does
> exist, although it is not as straightforward as you are trying to
> represent it.
>
Functions return values, not objects. That the Standard conflates 'Pointer to'
and 'Address of' is IMO a mistake.
Joe Wright
>
> Such as [all quotations from ISO/IEC 9899:1999 (E)]:
>
> »If the selection cannot be honored, the setlocale
> function returns a null pointer«
>
> It does not actually return an object, just an address, so
> why is this address is beingt called »pointer« here?
>
> »causes the setlocale function to return a pointer to
> the string«
>
> Here, it also just returns an address value, still it is
> called »pointer«.
>
> »The localeconv function returns a pointer to the
> filled-in object.«
>
> The address returned is the address of an object, but it is
> not an object itself, but a value. Still it is being called
> »a pointer«.
>
> I believe that I could find more examples of this usage,
> but possibly three will suffice.
>
With all due deference to the Standard, calling a value with the name of an
object is wrong. A pointer is an object. You can say that strcat() returns a
pointer, but it does not. Saying it doesn't make it so.
Richard Heathfield
<snip>
> With all due deference to the Standard, calling a value with the
> name of an object is wrong. A pointer is an object.
The Standard clearly uses the word "pointer" to refer not only to
objects but also to values, types, and functions. Are you suggesting
that a function pointer is an object? For example, strcpy is a
function pointer. Do you really think that strcpy is an object?
> You can say that strcat() returns a pointer,
Yes, you can.
> but it does not.
Er, yes it does.
> Saying it doesn't make it so.
Saying it doesn't doesn't make it not so. Read the Standard.
Joe Wright
> Joe Wright <joeww...@comcast.net> writes:
> [...]
>> You and I Keith, have had this very discussion before. You agree with
>> me but think we're better off agreeing that functions might return
>> pointers. That's a widely shared opinion and you are welcome to
>> it. Not me.
>>
>> The Standard is Standard of course. Not flawless, certainly.
>>
>> I don't demand that you or anyone agree with me. (It would be nice..)
>
> I'm still not 100% clear on what opinion you hold. Perhaps if I
> were, we could avoid having this discussion yet again.
>
> The standard says that, for example, malloc() returns a pointer.
> It's not reasonably possible to disagree with that; that's just
> what the standard says. That has implications about what the word
> "pointer", as used by the standard, means. It's hardly the only case
> where the standard uses a word with a meaning that's inconsistent
> with the way it's commonly used elsewhere (byte, object, etc.).
> I presume you agree with this.
>
> Clearly words can have different meanings in different contexts.
> "Pointer" can refer to a dog or to a stick, for example.
>
> I *think* you're saying that you dislike the way the standard uses
> the word "pointer". Is that a fair summary? If so, I couldn't
> possibly disagree with you; only you can know what you dislike.
>
> Can you state, ideally in one short and unambiguous sentence,
> just what your opinion is that you think I disagree with?
>
IMO you would have me accept that strcpy() returns a pointer because the
Standard says it does. Nonsense says I. Functions return values, not objects.
BWK, scribe for DMR decries in the first sentence of Chapter 5 of K&R1, "A
pointer is a variable that contains the address of another variable." That's
good enough for me but not, apparently, for you. A stick is not a pointer.
I am not trying to start a fight with anyone, only to explain how I see things
even if my explanation is at odds with some reading of the Standard. I don't
hold the Standard as Scripture.
DMR turned 68 last month. Time flies..
The hard parts of C are pointers vs addresses, declarations vs definitions,
scope and linkage. The Standard is less than clear on these subjects. In the
near future, in a new thread, I will elaborate my takes on these subjects.
Richard Heathfield
<snip>
> IMO you would have me accept that strcpy() returns a pointer because
> the Standard says it does.
The Standard defines the language.
> Nonsense says I. Functions return values, not objects.
The Standard says that strcpy returns the value of s1. Since s1 is a
pointer object, its value is a pointer value. Pointers *are* values.
For example, a null pointer is a pointer value, not a pointer object.
It's a pointer value because it has pointer type, just as 6 is not an
object but is an int value because it has int type.
> BWK, scribe for DMR decries in the first sentence of
> Chapter 5 of K&R1, "A pointer is a variable that contains the
> address of another variable." That's good enough for me but not,
> apparently, for you.
Well, bwk is over-simplifying. To a first approximation, what he says
is correct - but it is not the whole story. For example, if you take
what he says as gospel, then function pointer objects are not pointer
objects (because they contain the address of a function, not a
"variable") - and that would clearly be ludicrous.
<snip>
Joe Wright
> In <2ZudnYePd9nIKlrX...@giganews.com>, Joe Wright wrote:
>
> <snip>
>
>> With all due deference to the Standard, calling a value with the
>> name of an object is wrong. A pointer is an object.
>
> The Standard clearly uses the word "pointer" to refer not only to
> objects but also to values, types, and functions. Are you suggesting
> that a function pointer is an object? For example, strcpy is a
> function pointer. Do you really think that strcpy is an object?
>
>> You can say that strcat() returns a pointer,
>
> Yes, you can.
>
>> but it does not.
>
> Er, yes it does.
>
>> Saying it doesn't make it so.
>
> Saying it doesn't doesn't make it not so. Read the Standard.
>
written 31 years ago by BWK for DMR is Scripture.
Brian was 67 this year.
Richard Heathfield
<snip>
> Boo. "A pointer is a variable that contains the address of another
> variable." written 31 years ago by BWK for DMR is Scripture.
So function pointers aren't pointers. Cute.
James Kuyper
> Keith Thompson wrote:
...
>> I'm still not 100% clear on what opinion you hold. Perhaps if I
>> were, we could avoid having this discussion yet again.
>>
>> The standard says that, for example, malloc() returns a pointer.
>> It's not reasonably possible to disagree with that; that's just
>> what the standard says. That has implications about what the word
>> "pointer", as used by the standard, means. It's hardly the only case
>> where the standard uses a word with a meaning that's inconsistent
>> with the way it's commonly used elsewhere (byte, object, etc.).
>> I presume you agree with this.
>>
> Our malloc() and friends return values of type (void*), not pointers.
More precisely, they return pointer values of type void*.
>> Clearly words can have different meanings in different contexts.
>> "Pointer" can refer to a dog or to a stick, for example.
>>
>> I *think* you're saying that you dislike the way the standard uses
>> the word "pointer". Is that a fair summary? If so, I couldn't
>> possibly disagree with you; only you can know what you dislike.
>>
>> Can you state, ideally in one short and unambiguous sentence,
>> just what your opinion is that you think I disagree with?
>>
> IMO you would have me accept that strcpy() returns a pointer because the
> Standard says it does. Nonsense says I. Functions return values, not
> objects. ...
The standard rather consistently uses 'pointer' as a short form for
either 'pointer object' or 'pointer value', depending upon context,
relying upon the reader to use the context to determine which of the two
it's referring to. It would be nice it the standard bothered explaining
this usage, but it does not. It's quite likely that, somewhere in the
standard, this usage leaves the standard ambiguous. It might be better
if it they had chosen not to shorten either term, but if such a change
were made, the standard would be a noticeably longer.
Keith is not trying to get you to accept that strcpy() returns a pointer
object, but only that the standard says that strcpy() returns "a
pointer", by which the standard means "a pointer value".
> ... BWK, scribe for DMR decries in the first sentence of Chapter 5
> of K&R1, "A pointer is a variable that contains the address of another
> variable." That's good enough for me but not, apparently, for you. ...
K&R was the closest thing that early C had to a standard, but it's not
written with sufficient precision to qualify as an official standard.
Despite it's faults (and it's handling of the word 'pointer' is
certainly one of them) the standard pinned down with much greater
precision a number of thing that K&R left excessively vague.
Ben Bacarisse
> Keith Thompson wrote:
<snip>
>> Can you state, ideally in one short and unambiguous sentence,
>> just what your opinion is that you think I disagree with?
>>
> IMO you would have me accept that strcpy() returns a pointer because
> the Standard says it does. Nonsense says I. Functions return values,
> not objects. BWK, scribe for DMR decries in the first sentence of
> Chapter 5 of K&R1, "A pointer is a variable that contains the address
> of another variable." That's good enough for me but not, apparently,
> for you.
It's not good enough for K&R either since the chapter goes on to
contain further uses that complicate this simple picture. For example
we read that
"The calling program passes pointers to the values to be changed:
swap(&a, &b);
Since the operator '&' gives the address of a variable, '&a' is a
pointer to 'a'."
Here we have not only a pointer to a value rather than to a variable
(that's probably just something that slipped though the editing), but
also an expression (not an object) that "is a pointer". Even your
idea that functions don't return pointers (because pointers must be
objects) is not supported by K&R. Later on we read that:
"If 'binary' find the word, it return a pointer to it; if it fails,
it return NULL."
I am sure that you can make the distinction rigorous; and there may be
some merit in trying to get other to agree with you on the distinction
you are trying to preserve; but you can't turn to K&R for unwavering
support for it.
Personally, I am very happy with slightly sloppy language even, in a
technical book. The meanings of technical terms emerge from good
technical writing even if the language is not always consistent. I
have been (correctly) corrected for writing that argv is a pointer to
an array of pointers, but there in chapter 5 I find:
"Since argv is a pointer to an array of pointers..."
It is the nature of Usenet that details get more attention than big
ideas.
<snip>
--
Ben.
Joe Wright
> In <X-idncZd5sjaWFrX...@giganews.com>, Joe Wright wrote:
>
> <snip>
>
>> IMO you would have me accept that strcpy() returns a pointer because
>> the Standard says it does.
>
> The Standard defines the language.
>
>> Nonsense says I. Functions return values, not objects.
>
> The Standard says that strcpy returns the value of s1. Since s1 is a
> pointer object, its value is a pointer value. Pointers *are* values.
> For example, a null pointer is a pointer value, not a pointer object.
> It's a pointer value because it has pointer type, just as 6 is not an
> object but is an int value because it has int type.
>
"Since the value of s1 is a pointer type and since s1 is a pointer object then
the value of s1 is a pointer."? Did you really write that?
>> BWK, scribe for DMR decries in the first sentence of
>> Chapter 5 of K&R1, "A pointer is a variable that contains the
>> address of another variable." That's good enough for me but not,
>> apparently, for you.
>
> Well, bwk is over-simplifying. To a first approximation, what he says
> is correct - but it is not the whole story. For example, if you take
> what he says as gospel, then function pointer objects are not pointer
> objects (because they contain the address of a function, not a
> "variable") - and that would clearly be ludicrous.
>
You have pretty good creds Richard but Brian outranks you big time. Function
pointer objects contain the address of a function. The function itself is
arguably an object, if not a variable.
My point is simply that a value, the address of an object, having pointer type
is NOT a pointer. If the Standard says otherwise, it is wrong.
Keith Thompson
> pointer type is NOT a pointer. If the Standard says otherwise, it is
> wrong.
The phrase "an integer" may refer either to an object of integer
type or to a value of integer type.
Why is it so hard to accept that the phrase "a pointer" may refer
either to an object of pointer type or to a value of pointer type?
If you prefer to apply the unqualified word "pointer" only to pointer
objects, and not to pointer valies (i.e., addresess), that's fine.
But I fail to see the point of denying that the word "pointer"
*can* refer to a pointer value, not just because the Standard uses
it that way, but because plenty of other people do so as well.
What fundamental principle is violated by using the word "pointer"
to refer to a value, to the extent that you say the standard is
just wrong to do so?
Seebs
> You have pretty good creds Richard but Brian outranks you big time.
Rank and a dollar get you a bag of chips.
Questions of fact are not determined by rank.
> My point is simply that a value, the address of an object, having
> pointer type is NOT a pointer. If the Standard says otherwise, it is wrong.
I don't think so. BWK's a great guy, but his didactic material explaining
how to think about variables declared as pointers is not necessarily more
authoritative than the language spec.
A ton of words got redefined a little bit in the process of formalizing
their definitions. The new definitions aren't wrong, even when they are
perhaps different.
-s
--
Copyright 2009, all wrongs reversed. Peter Seebach / usenet...@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
Richard Heathfield
> Richard Heathfield wrote:
>> In <X-idncZd5sjaWFrX...@giganews.com>, Joe Wright
>> wrote:
>>
>> <snip>
>>
>>> IMO you would have me accept that strcpy() returns a pointer
>>> because the Standard says it does.
>>
>> The Standard defines the language.
>>
>>> Nonsense says I. Functions return values, not objects.
>>
>> The Standard says that strcpy returns the value of s1. Since s1 is
>> a pointer object, its value is a pointer value. Pointers *are*
>> values. For example, a null pointer is a pointer value, not a
>> pointer object. It's a pointer value because it has pointer type,
>> just as 6 is not an object but is an int value because it has int
>> type.
>>
> It is amazing to me that a student of English and logic as you would
> write such. "Since the value of s1 is a pointer type and since s1 is
> a pointer object then the value of s1 is a pointer."? Did you really
> write that?
No, and I most certainly didn't say (as you claim I said) that a value
is a type! What I actually wrote was: "The Standard says that strcpy
returns the value of s1. Since s1 is a pointer object, its value is a
pointer value. Pointers *are* values. For example, a null pointer is
a pointer value, not a pointer object. It's a pointer value because
it has pointer type, just as 6 is not an object but is an int value
because it has int type."
>>> BWK, scribe for DMR decries in the first sentence of
>>> Chapter 5 of K&R1, "A pointer is a variable that contains the
>>> address of another variable." That's good enough for me but not,
>>> apparently, for you.
>>
>> Well, bwk is over-simplifying. To a first approximation, what he
>> says is correct - but it is not the whole story. For example, if
>> you take what he says as gospel, then function pointer objects are
>> not pointer objects (because they contain the address of a
>> function, not a "variable") - and that would clearly be ludicrous.
>>
> You have pretty good creds Richard but Brian outranks you big time.
Sure. So what? A Carbon atom gets you a benzene ring that, if asked,
bwk would agree that the term "pointer" can be applied to values,
types, and functions as well as to objects.
> Function pointer objects contain the address of a function. The
> function itself is arguably an object, if not a variable.
C&V, please.
> My point is simply that a value, the address of an object, having
> pointer type is NOT a pointer. If the Standard says otherwise, it is
> wrong.
Since the Standard does say otherwise, and since the Standard is right
by definition, I conclude that your point is mistaken. You said that
bwk outranks me. Well, so he does - but, by the same token, sure as
eggs is eggs the ISO guys outrank you. So if you find your logic
compelling, consistency demands that you apply it to your own claim.
Here's some C&V for you, taking null pointers as my example:
"An integral constant expression with the value 0, or such an
expression cast to type void * , is called a null pointer constant.
If a null pointer constant is assigned to or compared for equality to
a pointer, the constant is converted to a pointer of that type. Such
a pointer, called a null pointer, is guaranteed to compare unequal to
a pointer to any object or function."
Thus, in the code
int is_null(void *p)
{
return p == 0;
}
the 0 (an integral constant expression with the value 0, and thus a
null pointer constant) is being compared to a pointer, and is
therefore converted to /a pointer/ - but conversions do not create
objects. 0 is converted not to an object but to a value of a
different type, a pointer type. And it is explicitly called a pointer
by the text of the Standard.
Joe Wright
> Joe Wright <joeww...@comcast.net> writes:
> [...]
>> My point is simply that a value, the address of an object, having
>> pointer type is NOT a pointer. If the Standard says otherwise, it is
>> wrong.
>
> The phrase "an integer" may refer either to an object of integer
> type or to a value of integer type.
>
The phrase "an integer" is not at issue here.
> Why is it so hard to accept that the phrase "a pointer" may refer
> either to an object of pointer type or to a value of pointer type?
>
Because I find it useful to differentiate 'pointer' and 'address'.
> If you prefer to apply the unqualified word "pointer" only to pointer
> objects, and not to pointer valies (i.e., addresess), that's fine.
> But I fail to see the point of denying that the word "pointer"
> *can* refer to a pointer value, not just because the Standard uses
> it that way, but because plenty of other people do so as well.
>
Common usage is an argument for English pronunciation of particular words but
not so much for Computer Science. Conflating 'pointer to' and 'address of' is
just that and should be avoided.
> What fundamental principle is violated by using the word "pointer"
> to refer to a value, to the extent that you say the standard is
> just wrong to do so?
>
Because 'pointer' is already defined ..
char *p;
.. defines p a pointer to char. Not a value. p may contain an address if you
assign one to it. But p is a pointer, not an address.
Usage again. Expressing p (as rvalue) yields a value commonly called 'pointer'
when it should be called 'address'. The two are different in my view.
Joe Wright
> Sure. So what? A Carbon atom gets you a benzene ring that, if asked,
> bwk would agree that the term "pointer" can be applied to values,
> types, and functions as well as to objects.
>
>> Function pointer objects contain the address of a function. The
>> function itself is arguably an object, if not a variable.
>
> C&V, please.
>
Can't really. Except that the value of the function pointer is the address of a
region of storage. That might be an object?
>> My point is simply that a value, the address of an object, having
>> pointer type is NOT a pointer. If the Standard says otherwise, it is
>> wrong.
>
> Since the Standard does say otherwise, and since the Standard is right
> by definition, I conclude that your point is mistaken. You said that
> bwk outranks me. Well, so he does - but, by the same token, sure as
> eggs is eggs the ISO guys outrank you. So if you find your logic
> compelling, consistency demands that you apply it to your own claim.
>
Since the Standard is right by definition, there is no point in my disagreeing
with anything you think it says. But please consider..
char *buff = malloc(80);
The pointer buff is an lvalue (object) accepting the assignment of the address
of some memory returned by malloc. Expressing buff in rvalue context yields the
address value. Do you insist that this value is a pointer? (Yes, it does have
pointer type.)
PS You have lots of creds here. I have C Unleashed on the floor next to my desk.
I plan to pick it up one day and put it on my desk.
Keith Thompson
> disagreeing with anything you think it says. But please consider..
>
> char *buff = malloc(80);
>
> The pointer buff is an lvalue (object) accepting the assignment of the
> address of some memory returned by malloc.
"lvalue" and "object" are not synonymous. An lvalue is, roughly, an
expression that designates an object. (Getting the definition of
"lvalue" right is one thing the Standard, in both major versions, has
gotten wrong.)
> Expressing buff in rvalue
> context yields the address value. Do you insist that this value is a
> pointer? (Yes, it does have pointer type.)
Yes.
If you insist that a pointer value cannot be called a "pointer",
then it's not. But it can, so it is.
You have every right to dislike this usage, but you cannot reasonably
deny that the word "pointer" *is* used that way, and I see nothing
inconsistent about it.
Is there some basic principle, other than your claim that a value
of pointer type should not be called a "pointer", that's being
violated here?
Looking at the English usage, a pointer is something that points.
A pointer value can point at something. Given:
int x;
the value of the expression ``&x'' points to the object x.
[...]
Keith Thompson
>> What fundamental principle is violated by using the word "pointer"
>> to refer to a value, to the extent that you say the standard is
>> just wrong to do so?
>>
> Because 'pointer' is already defined ..
Yes, it's defined by the ISO standard for the language we discuss
here, and it's defined in a way that's inconsistent with your usage.
> char *p;
>
> .. defines p a pointer to char. Not a value. p may contain an address
> if you assign one to it. But p is a pointer, not an address.
Right, p is an object of pointer type, "a pointer" for short.
> Usage again. Expressing p (as rvalue) yields a value commonly called
> 'pointer' when it should be called 'address'. The two are different in
> my view.
I understand that that's your view. You've demonstrated no basis
for it other than your own personal preference.
It's easy enough to disambiguate the various concepts, if necessary,
by using "pointer" as an adjective: pointer object, pointer value,
pointer expression, pointer type.
Joe Wright
Richard Tobin
Joe Wright <joeww...@comcast.net> wrote:
>> The phrase "an integer" may refer either to an object of integer
>> type or to a value of integer type.
>The phrase "an integer" is not at issue here.
It's an analoguy.
>> Why is it so hard to accept that the phrase "a pointer" may refer
>> either to an object of pointer type or to a value of pointer type?
>Because I find it useful to differentiate 'pointer' and 'address'.
Why not use "pointer variable" and "pointer", just as you presumably
use "integer variable" and "integer"? In my experience, "pointer" and
"address" are used indiscriminately by most C programmers, so your
distinction will be lost on them.
>Common usage is an argument for English pronunciation of particular words but
>not so much for Computer Science. Conflating 'pointer to' and 'address of' is
>just that and should be avoided.
Unless other share your usage, it's a source of confusion, not precision.
-- Richard
--
Please remember to mention me / in tapes you leave behind.
James Kuyper
> Richard Heathfield wrote:
>> Since the Standard does say otherwise, and since the Standard is right
>> by definition, I conclude that your point is mistaken. You said that
>> bwk outranks me. Well, so he does - but, by the same token, sure as
>> eggs is eggs the ISO guys outrank you. So if you find your logic
>> compelling, consistency demands that you apply it to your own claim.
>>
> Since the Standard is right by definition,
The standard defines what C is; it can be inconsistent, in can differ
from what the authors intended, it can be badly designed. The one thing
it can't do is incorrectly define C, because there is no more
authoritative definition of what C is, to which it can be compared and
found wanting.
> ... there is no point in my
> disagreeing with anything you think it says.
If you believe that he thinks incorrectly about what it says, there's a
point in presenting the evidence that justifies your belief.
> ... But please consider..
>
> char *buff = malloc(80);
>
> The pointer buff is an lvalue (object) accepting the assignment of the
> address of some memory returned by malloc. Expressing buff in rvalue
> context yields the address value. Do you insist that this value is a
> pointer? (Yes, it does have pointer type.)
Yes, it is a pointer value. No, it is not a pointer object. Yes the
standard says it is a pointer, with the expectation that the reader will
be able to disambiguate that as meaning "pointer value".
Tim Rentsch
> Joe Wright wrote:
>> Richard Heathfield wrote:
> ...
>>> Since the Standard does say otherwise, and since the Standard is
>>> right by definition, I conclude that your point is mistaken. You
>>> said that bwk outranks me. Well, so he does - but, by the same
>>> token, sure as eggs is eggs the ISO guys outrank you. So if you
>>> find your logic compelling, consistency demands that you apply it
>>> to your own claim.
>>>
>> Since the Standard is right by definition,
>
> The standard defines what C is; it can be inconsistent, in can differ
> from what the authors intended, it can be badly designed. The one
> thing it can't do is incorrectly define C, because there is no more
> authoritative definition of what C is, to which it can be compared and
> found wanting.
Essentially no one other than you really believes this. For
example, function calls in C are mutually exclusive, so an
expression like
f() + g()
will either completely evaluate f() and then g(), or first g()
and then f(), but evaluation of the two function bodies must not
be interleaved (in terms of the abstract machine). Readers of
comp.lang.c, and also other people who are familiar with ISO C,
essentially all consider this part of C. Yet the Standard does
not say this. The authority for it is a response to a defect
report, but that response is not reflected in any text in
the Standard itself.
If you want to think that C is defined only by text in the
Standard and nothing else, you're perfectly free to do so.
But please remember that this view is only your opinion, not
absolute truth, and represent it as such. There are plenty
of people who don't share that opinion.