«

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.

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

--

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.

In article <c1e911d8-13d5-4276-87e0->
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]? ...
>[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.

A (non-inline) function is, after all, compiled to a bunch of
executable instructions, on most of today's machines with most
of today's compilers. Those instructions eventually wind up
with "code-space addresses", but you get more than just *an*
address, you get a whole range of addresses. It makes more sense,
I think, to say that the function itself occupies that entire
range. Of cours, after declaring "void f(void);", the line:

sizeof f

produces a compile-time error, but this is due to the language
decreeing that no C compiler has to be able to divine the eventual
final size of a function at the point that the "sizeof" occurs.
(This is natural enough, since the function may not even have been
compiled yet. Of course, there are ways to deal with this, by
making "sizeof f" be a link-time constant instead of a compile-time
constant, but the language does not require that.)

The language specifies that, once you have declared that a some
identifier refers to a function, simply naming the function (without
actually calling it) normally produces a pointer to that function.
This pointer is a form of "address value", and the address you get
on real machines is, in general, the address of the first instruction
-- or the first byte of the first instrution -- of the function.
(Even this is not guaranteed. On the VAX, for instance, the first
*executable* byte of the function is two bytes *after* the start
of the function. Functions begin with a two-byte "register save
mask" word. The function pointer points to this word. On other
machines, a function pointer may point to a "function descriptor",
rather than to the actual code for the function. Descriptors may
be collected together at compile and/or link time, or may simply
precede each function.)

Ultimately, the C beginner -- in order to become a non-beginner --
has to grasp the idea that the C language "likes to" take something
that covers a large range of machine addresses, like an array or
a function, and "squish it down" to a pointer to the *start* of
that large range. This is the origin of the idea of the "decay"
of an array or function name, which both *usually* turn into a
pointer value, pointing to the "start" of the larger entity. But
this "decay" is suppressed in particular cases, such as using
the "sizeof" operator.
--
In-Real-Life: Chris Torek, Wind River Systems
Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
email: forget about it http://web.torek.net/torek/index.html
Reading email is like searching for food in the garbage, thanks to spammers.

Julienne Walker <> writes:
> 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_Keith) <kst->
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"

On Dec 7, 4:05 pm, Chris Torek <nos...@torek.net> wrote:
> In article <c1e911d8-13d5-4276-87e0-5696fb430...@o42g2000hsc.googlegroups.com>
> Julienne Walker <happyfro...@hotmail.com> 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]? ...
> >[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
trying to teach C. Rather, I was intending to use the concept of a
function identifier resolving to an address when used as a way to
avoid confusion long enough to get started. But in avoiding confusion
I also don't want to be thoroughly incorrect according to the
standard.

Naturally I wouldn't dream of suggesting that the whole function is a
single address, as replies so far seem to have misinterpreted despite
my careful wording of the actual post. In fact, that would defeat the
purpose.

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?

> <snip the usual good stuff from Chris>
> --
> In-Real-Life: Chris Torek, Wind River Systems
> Salt Lake City, UT, USA (40°39.22'N, 111°50.29'W) +1 801 277 2603
> email: forget about it http://web.torek.net/torek/index.html
> Reading email is like searching for food in the garbage, thanks to spammers.

>>>>> "JW" == Julienne Walker <> writes:

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

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

Julienne Walker <> writes:
[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_Keith) <kst->
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 wrote:
> On Dec 7, 4:05 pm, Chris Torek <nos...@torek.net> wrote:
> > In article <c1e911d8-13d5-4276-87e0-5696fb430...@o42g2000hsc.googlegroups.com>
> > Julienne Walker <happyfro...@hotmail.com> 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]? ...
> > >[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
> trying to teach C. Rather, I was intending to use the concept of a
> function identifier resolving to an address when used as a way to
> avoid confusion long enough to get started. But in avoiding confusion
> I also don't want to be thoroughly incorrect according to the
> standard.
>
> Naturally I wouldn't dream of suggesting that the whole function is a
> single address, as replies so far seem to have misinterpreted despite
> my careful wording of the actual post. In fact, that would defeat the
> purpose.

I'm sorry, but I don't follow that. Looking back over you previous
message, and knowing now what it was that you actually meant, I can't
find a single word that contradicts my original reading of your
message: that you intended to teach students that a function is an
address. The correct statement is that a function name decays into a
function pointer in virtually all contexts. Your way of saying it is
incorrect because:

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.

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

The only cases where it does not happen are as an operand to sizeof,
where it's a constraint violation, or as the operand of a unary '&'
operator, in which case it is the result of the expression that is a
pointer, rather than the function name itself.

On Dec 7, 4:49 pm, Keith Thompson <ks...@mib.org> wrote:
> Julienne Walker <happyfro...@hotmail.com> writes:
>
> [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_Keith) <ks...@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"

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


-Jul