A function is an address

  • Thread starter Julienne Walker
  • Start date
P

Peter Nilsson

Julienne Walker said:
Ignoring implementation details and strictly following
the C99 standard in terms of semantics, is there anything
fundamentally flawed with describing the use of a (non-
inline) function as an address[1]? I keep feeling like
I'm missing something obvious.

Leave 'address' out of it. Just say that all functions are
called through function pointers and that names of functions
decay to function pointers in general expressions, except
in the case of sizeof.
 
K

Keith Thompson

James Kuyper said:
Keith said:
Keith Thompson wrote:
(e-mail address removed) writes:
[...]
A function name names a function, it is not the same thing as the
function itself. A function pointer will typically contain an address,
but a function pointer is not an address. A function name will decay
into a function pointer in almost every context, but a function name
is not a function pointer.
[...]

Actually, a function pointer *is* an address; it's the address of the
function. (The standard uses the words "address" and "pointer" almost
interchangeably.)
I think that, to the extent that the standard does so, it is
defective. Treating the two terms as interchangeable would, if
normative, prohibit the implementation of pointers as structures which
contain, among other things, the address of the location in memory
that they point at. I doubt that it was the intent of the committee to
prohibit such fat-pointer implementations.

Cross-posting to comp.std.c

Not at all. In an implementation with fat pointers, a fat pointer
*is* an address. For example, the unary "&" operator yields a fat
pointer value, which is the address of the operand.

No, it isn't an address, it contains an address. It also contains
other things: bound's checking data, or type info, or a reference
count, or something else entirely, depending upon what kind of fat
pointer it is.

You're using the word "address" in a manner that's inconsistent with
the way the standard uses the word. There are other valid meanings of
the word, but they're no more relevant here than the common meaning of
"byte" as exactly 8 bits.

C99 65.3.2p3:

The unary & operator yields the address of its operand.

This address may or may not be a machine address.
 
P

pete

Julienne Walker wrote:
So please allow me to refine my question: In what cases would the use
of a function name *not* evaluate to a pointer to that function?

There are exactly two cases where
a function name will *not* evaluate to a pointer to that function:
1 As an operand of &
2 As an operand of sizeof

When the & operator is applied to an expression of function type,
the result is the address of the function.

sizeof is only defined for object types.
Since function type expressions
don't convert as operands of sizeof,
expressions with sizeof operating
on an expressions of function types, are undefined.

The only thing that you can do with an expression of function type,
in a correct C program, is to derive an address from it.
 
J

James Kuyper

Keith said:
....
You're using the word "address" in a manner that's inconsistent with
the way the standard uses the word. There are other valid meanings of
the word, but they're no more relevant here than the common meaning of
"byte" as exactly 8 bits.

C99 65.3.2p3:

The unary & operator yields the address of its operand.

This address may or may not be a machine address.

I've already covered that - see above. I've reviewed the standard's uses
of the word "address", and most of them are consistent with my
understanding of address as a concept distinct from the concept of a
pointer (while not clearly supporting that distinction, I have to admit).
 
E

Eric Sosman

pete said:
There are exactly two cases where
a function name will *not* evaluate to a pointer to that function:
1 As an operand of &
2 As an operand of sizeof

Which of these two cases covers

void func(int i) { ... }
...
(***func)(42);

? "Amongst our weaponry are such diverse elements ..."
 
J

Julienne Walker

J> I appreciate your concern, but I don't think you're in a
J> position to make that judgment given nothing more than a quick
J> question from me to the experts on clc.

On the contrary; I think, as one of those experts with some teaching
experience, I'm in an excellent position to judge that.

Yet you're only making the judgment based on your assumption of how
I'm going to present the concept.
But carry on; thoroughly confusing beginners is a fine way to make
sure the consulting rates for competent C programmers remain high.

I really do appreciate the warnings, but I'm going to great lengths to
avoid confusing beginners while still teaching correct C.
 
J

Julienne Walker

Julienne Walker said:
Ignoring implementation details and strictly following
the C99 standard in terms of semantics, is there anything
fundamentally flawed with describing the use of a (non-
inline) function as an address[1]? I keep feeling like
I'm missing something obvious.

Leave 'address' out of it. Just say that all functions are
called through function pointers and that names of functions
decay to function pointers in general expressions, except
in the case of sizeof.

That was the plan, to a certain extent. I think I have more than a
vague idea of how to present this now. Thanks Peter, and everyone else
for your input.
 
K

Keith Thompson

James Kuyper said:
I've already covered that - see above. I've reviewed the standard's
uses of the word "address", and most of them are consistent with my
understanding of address as a concept distinct from the concept of a
pointer (while not clearly supporting that distinction, I have to
admit).

I believe the standard uses the word "address" as a synonym of a
"pointer value". I don't believe it ever refers to an object of
pointer type as an "address"; only (non-null) values of pointer type
are called "addresses".

I'm not aware of any statement in the standard that's inconsistent
with the idea that an "address" is the same thing as a pointer value
(even if the pointer value is some composite that incorporates a
machine address plus other information). Can you provide an example?

(I tend to use the unqualified word "pointer" to refer to objects of
pointer type, and the unqualified word "address" to refer to values of
pointer type, but the standard doesn't follow this convention; see for
example, the description of malloc(), which returns "a pointer to the
allocated space".)
 
P

pete

Eric said:
Which of these two cases covers

void func(int i) { ... }
...
(***func)(42);

?

You've just posted an example of four expressions of function type
each being implicitly converted to a pointer.
 
W

William Ahern

Julienne Walker said:
Julienne Walker said:
Ignoring implementation details and strictly following the C99
standard in terms of semantics, is there anything fundamentally flawed
with describing the use of a (non-inline) function as an address[1]? ...
[1] To keep things in context, this is in reference to describing
functions to a beginner.

I think the biggest problem with that is that it will just confuse
the beginner.
I think my provocative thread title may have confused everyone. ;-) I
have no intention of saying "A function is an address" and leaving it
at that. That would be stupid, and completely pointless when one is

A pointer isn't just an address, either. Pointers can contain other
information beyond, or even in lieu of, the code-space address of the
underlying object. (Not that you didn't know this already.) In fact,
function pointers are ripe for this kind of use. And that is why, I think,
conflating--or using terms so susceptible--pointers with [linear] addresses
in the context of a function has elicited--directly or indirectly--such
strong responses.
 
K

Keith Thompson

William Ahern said:
A pointer isn't just an address, either. Pointers can contain other
information beyond, or even in lieu of, the code-space address of the
underlying object.
[...]

Yes, a pointer is just an address. Specifically, an address is simply
a valid non-null value of pointer type. That's the way the standard
uses the term "address"; see the description of the unary "&"
operator. (A C address may or may not be the same as a machine
address, virtual or otherwise.)
 
R

RoS

In data Sat, 08 Dec 2007 09:29:16 -0800, Keith Thompson scrisse:
I believe the standard uses the word "address" as a synonym of a
"pointer value". I don't believe it ever refers to an object of
pointer type as an "address"; only (non-null) values of pointer type
are called "addresses".

I'm not aware of any statement in the standard that's inconsistent
with the idea that an "address" is the same thing as a pointer value
(even if the pointer value is some composite that incorporates a
machine address plus other information). Can you provide an example?

char *p=0x1234;
sizeof(p)

so the pointer is not only an address; it is address and other
informations
 
P

pete

Keith Thompson wrote:
Yes, a pointer is just an address. Specifically, an address is simply
a valid non-null value of pointer type.

I have a problem with the word "valid".

Each of these kinds of pointer values
is more "valid" than the one before:
1 indeterminate
2 null pointer
3 one past
4 object address

The one past pointer is another catagory of pointer values
which I'm not sure if it should be considered an address.
 
P

pete

Julienne Walker wrote:
So please allow me to refine my question: In what cases would the use
of a function name *not* evaluate to a pointer to that function?

N869
6.3.2 Other operands
6.3.2.1 Lvalues and function designators

[#4] A function designator is an expression
that has function type.
Except when it is the operand of the sizeof operator
or the unary & operator,
a function designator with type
``function returning type''
is converted to an expression that has type
``pointer to function returning type''.
 
N

Nick Keighley

Yet you're only making the judgment based on your assumption of how
I'm going to present the concept.


I really do appreciate the warnings, but I'm going to great lengths to
avoid confusing beginners while still teaching correct C.

ignoring that I think describing a function as an address to beginners
is a mistake,
I do wonder what the background of your beginners is. You seem to be
introducing quite low level concepts (addresses) quite early.
My memory (from long ago) of being a beginner was that a "function"
was a little program. Fairly rapidly I wanted to know what was
going on underneath, but I was happy to begin with.
 
K

Keith Thompson

RoS said:
In data Sat, 08 Dec 2007 09:29:16 -0800, Keith Thompson scrisse:

char *p=0x1234;
sizeof(p)

so the pointer is not only an address; it is address and other
informations

Not really. sizeof(p) doesn't refer to the pointer *value*; it yields
the size of a pointer *object*. What I said was that an address is a
pointer value. The current value of ``p'' is a pointer value
(equivalently, I claim, the value of ``p'' is an address). The
*object* ``p'' has more information associated with it than just that
address, just as an object of type int has more information than just,
say, the value 42.

And note that
char *p=0x1234;
is a constraint violation; there's no implicit conversion from int to
char*.
 
D

Douglas A. Gwyn

Keith said:
I believe the standard uses the word "address" as a synonym of a
"pointer value". I don't believe it ever refers to an object of
pointer type as an "address"; only (non-null) values of pointer type
are called "addresses".

That's pretty much the intention. "Address" is not really a useful
term, except for steering the reader's intuition in the right general
direction. The usual IT meaning of "address" is a numerical encoding
used to access the storage location of some information. That's also
what a C pointer value is (apart from a null pointer value). About
the only actual distinction is that a null pointer value might not
correspond to any valid address representation. (But it could..)

The name of a function designates the collection of information used
to implement an invocation of the function. Standard C rules say
that the name of a function is automatically converted into a pointer
(type) to the function in most contexts, and that function calls
(invocations) are always made through pointers to the functions.
So (***foo)(bar) is the same as foo(bar), if foo was declared as a
function designator.
 
D

David R Tribble

That's pretty much the intention. "Address" is not really a useful
term, except for steering the reader's intuition in the right general
direction. The usual IT meaning of "address" is a numerical encoding
used to access the storage location of some information. That's also
what a C pointer value is (apart from a null pointer value).

I believe the only section of the std that deals with explicit
pointer-to-integer conversions is section 7.18.1.4, which
defines the intptr_t and uintptr_t types, and it uses the
term "pointer".
 
W

Wojtek Lerch

....
The usual IT meaning of "address" is a numerical encoding
used to access the storage location of some information. That's also
what a C pointer value is (apart from a null pointer value).

Actually, no; a C pointer value has a lot of more meaning associated with
it, such as whether it can be dereferenced or not, the range of integers
that can be safely added to it, and so on. It's possible for two C pointers
to look like the same address (and to compare equal) despite the fact that
one of them points to an object (and therefore can be dereferenced but not
decremented) and the other one points past the end of an array (and
therefore can be decremented but not dereferenced). Unfortunately, large
portions of the standard seems to have been written with the narrow
pointer==address model in mind, and are hopelessly unclear on how various
operations propagate the semantic guarantees that a pointer value is
supposed to carry in addition to the address.
 
D

Douglas A. Gwyn

Wojtek said:
Actually, no; a C pointer value has a lot of more meaning associated with
it, such as whether it can be dereferenced or not, the range of integers
that can be safely added to it, and so on.

(Perhaps more importantly, pointers also have types.)

Those are restrictions, not a difference in the fundamental meaning.
It's possible for two C pointers
to look like the same address (and to compare equal) despite the fact that
one of them points to an object (and therefore can be dereferenced but not
decremented) and the other one points past the end of an array (and
therefore can be decremented but not dereferenced).

Again, the model is of storage locations, and there are restrictions
(motivated by a desire for faster execution on some architectures).
... portions of the standard seems to have been written with the narrow
pointer==address model in mind, and are hopelessly unclear on how various
operations propagate the semantic guarantees that a pointer value is
supposed to carry in addition to the address.

There aren't all that many allowed operations for pointers.
Assigning to the same type presumably loses no information.
Subtraction is pretty well spelled out.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top