A function is an address

[Julienne Walker]

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.


-Jul

[1] To keep things in context, this is in reference to describing
functions to a beginner.

[Eric Sosman]

Re: A function is an address

Julienne Walker wrote:

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.

It would probably be better to describe a function as
a custard pie.

-Jul
>
[1] To keep things in context, this is in reference to describing
functions to a beginner.

Oh, a beginner? In that case, "custard pie" is by far
the best way to introduce the topic. Later, when the pupil
has gained some understanding and experience, you can go
back and explain that "custard pie" is really a simplification;
in full generality a function can be any kind of dessert or
comedic prop whatsoever.

(In other words, have you taken leave of your senses,
or have they taken leave of you? Or are you a disciple of
Humpty Dumpty, determined to make words mean whatever you
want them to and without regard to what others may think
they mean?)

--
Eric.Sosman@sun .com

[jameskuyper@verizon.net]

Re: A function is an address

Julienne Walker wrote:

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.

A function typically has an associated memory address indicating the
entry point for the function. A function is not an address, any more
than your house is an address.

[Keith Thompson]

Re: A function is an address

Julienne Walker <happyfrosty@ho tmail.comwrites :

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.
>
[1] To keep things in context, this is in reference to describing
functions to a beginner.

I can't think of anything *not* fundamentally flawed about describing
the use of a function as an address.

I suspect what you're thinking of is the fact that an expression of
function type (including the name of a function) is, unless it's the
operand of a unary "sizeof" or "&" operator, implicitly converted to
the function's address, and the first operand of a function call
operator is actually a pointer-to-function, not necessarily a
function. I'm sure this is covered in the FAQ.

But this does not imply that a function *is* an address (it isn't),
and it's not necessarily something I'd mention to beginners.

Until a beginner starts to use function pointers explicitly, it
probably sufices to say that a function call func(arg1, arg2) calls
the specified function and passes it the specified arguments. The
fact that there's a conversion to a function pointer happening behind
the scenes can probably wait until later.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Re: A function is an address

Julienne Walker <happyfrosty@ho tmail.comwrites :
[SNIP]

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?

When it's the operand of a unary "sizeof" operator (which is a
constraint error, rather than yielding the size of a function
pointer), and when it's the operand of a unary "&" operator (which
yields the address of the function, rather than attempting to compute
the address of the address of the function, which would be a
constraint violation).

Note that this applies to any expression of function type, not just a
function name. For example, if ``p'' is an object of
pointer-to-function type, then ``*p'' is an expression of function
type, which then decays (back) to a pointer to the function.

It's quite similar to the hanlding of array names.

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Charlton Wilbur]

Re: A function is an address

>>>>"JW" == Julienne Walker <happyfrosty@ho tmail.comwrites :

JWSo please allow me to refine my question: In what cases would
JWthe use of a function name *not* evaluate to a pointer to that
JWfunction?

Why does a beginner care?

Have you ever tried to teach programming before? This is a concept
that beginners simply do not need to worry about, and making the
beginners worry about it when you introduce functions is a damn fine
way to confuse them.

Charlton




--
Charlton Wilbur
cwilbur@chromat ico.net

[Julienne Walker]

Re: A function is an address

On Dec 7, 4:49 pm, Keith Thompson <ks...@mib.orgw rote:

Julienne Walker <happyfro...@ho tmail.comwrites :
>
[SNIP]
>

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?

>
When it's the operand of a unary "sizeof" operator (which is a
constraint error, rather than yielding the size of a function
pointer), and when it's the operand of a unary "&" operator (which
yields the address of the function, rather than attempting to compute
the address of the address of the function, which would be a
constraint violation).
>
Note that this applies to any expression of function type, not just a
function name. For example, if ``p'' is an object of
pointer-to-function type, then ``*p'' is an expression of function
type, which then decays (back) to a pointer to the function.
>
It's quite similar to the hanlding of array names.
>
--
Keith Thompson (The_Other_Keit h) <ks...@mib.or g>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

Thank you. That's what I thought, but a worry kept tickling the back
of my brain that there was something else.


-Jul

[Keith Thompson]

Re: A function is an address

jameskuyper@ver izon.net 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 .)

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Julienne Walker]

Re: A function is an address

On Dec 7, 4:40 pm, Charlton Wilbur <cwil...@chroma tico.netwrote:

>>>"JW" == Julienne Walker <happyfro...@ho tmail.comwrites :

>
JWSo please allow me to refine my question: In what cases would
JWthe use of a function name *not* evaluate to a pointer to that
JWfunction?
>
Why does a beginner care?

A beginner doesn't care about this exact detail, but I'm intending to
use it to smooth the entire process of learning C. Rest assured that
I'm not going to tell a beginner something like that without a plan.

Have you ever tried to teach programming before?

Yes.

This is a concept
that beginners simply do not need to worry about, and making the
beginners worry about it when you introduce functions is a damn fine
way to confuse them.

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

Charlton
>
--
Charlton Wilbur
cwil...@chromat ico.net

[jameskuyper@verizon.net]

Re: A function is an address

Keith Thompson wrote:

jameskuyper@ver izon.net 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

[Eric Sosman]

Re: A function is an address

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?

Keith Thompson mentioned the curious case of `& fname',
and there's an equally curious `(*fname)'. With those
exceptions, I can think of no valid uses of function names
in expressions that do not evaluate to pointers to the
named functions.

Non-expression uses do not evaluate to anything at all:

int func(void); /* declares func, evaluates nothing */

void gunk(int) {} /* defines and declares gunk,
* evaluates nothing */

However, as you're talking to a beginner I'd suggest that
you not speak about "function pointers" or "function addresses"
at all. A function name is a name for a bunch of code that
expresses a bunch of operations to be performed, and there's
no need to fret about the details of how the machine represents
those operations. You don't need to talk about "instructio ns"
or "instructio n addresses" or any such; the beginner should be
more concerned with the idea that a piece of code "here" can
somehow use a different piece of code "there," and with the
mechanics of passing arguments and returning values. That
is, concentrate on what a function does and not on how some
machine happens to do it.

... and if you want to use custard_pie() as a function
name, that's fine with me.

--
Eric.Sosman@sun .com

[Keith Thompson]

Re: A function is an address

jameskuyper@ver izon.net writes:

Keith Thompson wrote:

>jameskuyper@ver izon.net 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
>interchangeabl y.)

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

--
Keith Thompson (The_Other_Keit h) <kst-u@mib.org>
Looking for software development work in the San Diego area.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Charlton Wilbur]

Re: A function is an address

>>>>"J" == Julienne Walker <happyfrosty@ho tmail.comwrites :

>This is a concept that beginners simply do not need to worry
>about, and making the beginners worry about it when you
>introduce functions is a damn fine way to confuse them.

JI appreciate your concern, but I don't think you're in a
Jposition to make that judgment given nothing more than a quick
Jquestion 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.

But carry on; thoroughly confusing beginners is a fine way to make
sure the consulting rates for competent C programmers remain high.

Charlton



--
Charlton Wilbur
cwilbur@chromat ico.net

[James Kuyper]

Re: A function is an address

Keith Thompson wrote:

jameskuyper@ver izon.net writes:

>Keith Thompson wrote:

>>jameskuyper@ver izon.net 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
>>interchangeab ly.)

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

[user923005]

Re: A function is an address

On Dec 7, 12:28 pm, Julienne Walker <happyfro...@ho tmail.comwrote:

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.

We reference a function by its address. A function is no more its
address than an array is its address. It's simply a handy handle we
have to reference it with.
We can use a function pointer and a function interchangably on
invocation, so there is no real important difference there.
A function address is different from a data address. Despite the fact
that it sometimes works, we are not supposed to store function
addresses in void pointers.
So the address of a function is a special sort of address.