Arithmetic on function address

[Stephen Biggs]

Given this code:
void f(void){}
int main(void){retu rn (int)f+5;}

Is there anything wrong with this in terms of the standards? Is this legal
C code? One compiler I'm working with compiles this quietly, even with the
most stringent and pedantic ANSI and warning levels, but generates code
that only loads the address of "f" and fails to make the addition before
returning a value from "main".

GCC "does the right thing".

Is there something I'm missing?

[Eric Sosman]

Re: Arithmetic on function address

Stephen Biggs wrote:[color=blue]
>
> Given this code:
> void f(void){}
> int main(void){retu rn (int)f+5;}
>
> Is there anything wrong with this in terms of the standards?[/color]

Yes and no. The Standard permits you to cast a pointer
value (even a function pointer value) to an integer, but it
does not guarantee that the result is useful or even usable.
[color=blue]
> Is this legal C code?[/color]

Legal but useless.
[color=blue]
> One compiler I'm working with compiles this quietly, even with the
> most stringent and pedantic ANSI and warning levels, but generates code
> that only loads the address of "f" and fails to make the addition before
> returning a value from "main".
>
> GCC "does the right thing".
>
> Is there something I'm missing?[/color]

Your marbles, perhaps. ;-) What are you trying to
accomplish with this ill-defined operation?

--
Eric.Sosman@sun .com

[Stephen Biggs]

Re: Arithmetic on function address

Eric Sosman <Eric.Sosman@su n.com> wrote in
news:4089560E.9 86D134A@sun.com :
[color=blue]
> Stephen Biggs wrote:[color=green]
>>
>> Given this code:
>> void f(void){}
>> int main(void){retu rn (int)f+5;}
>>
>> Is there anything wrong with this in terms of the standards?[/color]
>
> Yes and no. The Standard permits you to cast a pointer
> value (even a function pointer value) to an integer, but it
> does not guarantee that the result is useful or even usable.[/color]


But, it then should allow you to add a value to that integer, as the
code says, no? Is this what you mean by no guarantees of it being
usable?
[color=blue]
>[color=green]
>> Is this legal C code?[/color]
>
> Legal but useless.[/color]


Ok, fine... I agree completely that it is useless, but shouldn't correct
code be generated for it?
[color=blue]
>[color=green]
>> One compiler I'm working with compiles this quietly, even with the
>> most stringent and pedantic ANSI and warning levels, but generates
>> code that only loads the address of "f" and fails to make the
>> addition before returning a value from "main".
>>
>> GCC "does the right thing".
>>
>> Is there something I'm missing?[/color]
>
> Your marbles, perhaps. ;-) What are you trying to
> accomplish with this ill-defined operation?
>[/color]

Thank you for that :)... I am not trying to accomplish anything besides
running the GCC testsuite on some other compiler that I am trying to
analyze. This is part of the testsuite and passes with GCC, no
problem... I was just wondering if this is a bug in the compiler that I
am trying to run on this code? I want to be sure that this should
generate code correctly before I cry "bug". That is, that it should
generate code to add the constant after the pointer is converted to an
integer.

Thanks for any help.

[Eric Sosman]

Re: Arithmetic on function address

Stephen Biggs wrote:[color=blue]
>
> Eric Sosman <Eric.Sosman@su n.com> wrote in
> news:4089560E.9 86D134A@sun.com :
>[color=green]
> > Stephen Biggs wrote:[color=darkred]
> >>
> >> Given this code:
> >> void f(void){}
> >> int main(void){retu rn (int)f+5;}
> >>
> >> Is there anything wrong with this in terms of the standards?[/color]
> >
> > Yes and no. The Standard permits you to cast a pointer
> > value (even a function pointer value) to an integer, but it
> > does not guarantee that the result is useful or even usable.[/color]
>
> But, it then should allow you to add a value to that integer, as the
> code says, no? Is this what you mean by no guarantees of it being
> usable?[/color]

If you're testing compilers (as you say later on), you really
ought to get yourself a copy of the Standard -- which says (in
section 6.2.3, paragraph 6):

Any pointer type may be converted to an integer type.
Except as previously specified [not relevant here],
the result is implementation-defined. If the result
cannot be represented in the integer type, the behavior
is undefined. The result need not be in the range of
values of any integer type.

So: The result of the conversion is implementation-defined, and
need not be a valid value for an `int', and any attempt to create
an invalid value causes undefined behavior. That's "unusable" in
my book. (Gurus: Contrast this paragraph with the apparently
stronger conditions of 6.3.1.3/3: pointer-to-int can generate
U.B. instead of raising an implementation-defined signal.)
[color=blue][color=green][color=darkred]
> >> Is this legal C code?[/color]
> >
> > Legal but useless.[/color]
>
> Ok, fine... I agree completely that it is useless, but shouldn't correct
> code be generated for it?[/color]

It's hard to understand what "correct" means when describing
what might be undefined behavior. I think you need to do two
things before concluding that the generated code is "incorrect: "
You need to consult the compiler's own documentation to find how
it defines the conversion result, and you then need to determine
whether the result is in range for an `int'. Then:

- If the conversion result is defined but out of range,
you have no grounds for complaint. Any and all behaviors
(hence any and all generated code) are "correct."

- If the conversion result is defined and in range, you
may have reason to complain.

- If the conversion result is not defined, you have reason
to complain about the documentation, but not (yet) about
the code generation.

One observation about testing compilers: They usually must
obey several standards, not just one, and some of these may be
just "usual practice" rather than formal standards. That is,
the C Standard represents a sort of "non-negotiable minimum"
for a C implementation, but a C implementation that did *only*
what the Standard required would not enjoy much success. The
prospective users will also want POSIX support and/or Windows
support, they'll want "friendly" behavior when they do things
like clear a pointer to all-bits-zero, they'll want CHAR_BIT
to equal (not exceed) 8, they'll want various guarantees about
signal() behavior, and so on. They will *not* want the strictly-
conforming but user-hostile C compiler of the DeathStation 9000!

Next time you climb into your car, pause and take a look
around. How many of the things you see could be removed without
actually removing the car's ability to get you from Here to
There? Rip out the radio, the air conditioner, the leather
seats, the back seat, the side and rear windows, the power
steering -- you'll still have a strictly-conforming car, but
you might not want to drive it much.

--
Eric.Sosman@sun .com

[Alex Fraser]

Re: Arithmetic on function address

"Stephen Biggs" <Spammers@AreLo wLifes.com-INVALID-MUNGED> wrote in message
news:c6bjka$sct $1@news2.netvis ion.net.il...[color=blue]
> Given this code:
> void f(void){}
> int main(void){retu rn (int)f+5;}
>
> Is there anything wrong with this in terms of the standards? Is this
> legal C code? One compiler I'm working with compiles this quietly, even
> with the most stringent and pedantic ANSI and warning levels, but
> generates code that only loads the address of "f" and fails to make the
> addition before returning a value from "main".[/color]

Perhaps it optimised the addition away by moving f() ;).

[Arthur J. O'Dwyer]

Re: Arithmetic on function address


On Fri, 23 Apr 2004, Stephen Biggs wrote:[color=blue]
>
> Eric Sosman <Eric.Sosman@su n.com> wrote...[color=green]
> > Stephen Biggs wrote:[color=darkred]
> >>
> >> Given this code:
> >> void f(void){}
> >> int main(void){retu rn (int)f+5;}
> >>
> >> Is there anything wrong with this in terms of the standards?[/color]
> >
> > Yes and no. The Standard permits you to cast a pointer
> > value (even a function pointer value) to an integer, but it
> > does not guarantee that the result is useful or even usable.[/color]
>
> But, it then should allow you to add a value to that integer, as the
> code says, no? Is this what you mean by no guarantees of it being
> usable?[/color]

[This explanation based on N869 6.3.2.3#6.]

Not necessarily. The implementation might for instance map the
address of 'f' onto 'INT_MAX', thus producing signed-int overflow
when you try to add 5 to it. *Then*, and only then, is your program
allowed to defrost your refrigerator.
Alternatively, the implementation could map 'f' directly onto a
trap representation in 'int'; then, *any* attempt to use the value
of '(int)f' at all would trigger undefined behavior. (Note that
'(int)f' itself is still a valid construct on such systems; you
can take the 'sizeof ((int)f)' with impunity, but that's all you can
do.)
Finally, according to the word of the C99 draft standard, the
implementation is allowed to map the address of 'f' directly onto
a number so large that 'int' can't hold it. Instant undefined
behavior! (Except IMO in the case of 'sizeof', as above.)

[color=blue][color=green][color=darkred]
> >> Is this legal C code?[/color]
> >
> > Legal but useless.[/color]
>
>
> Ok, fine... I agree completely that it is useless, but shouldn't correct
> code be generated for it?[/color]

If it's completely useless --- and in fact could legitimately do
*anything at all* to your machine --- then what, pray tell, would be
the "correct code" you'd expect to see generated? "Garbage in,
garbage out" is the rule that applies here. Well, more precisely,
"Something that might or might not produce garbage in, something that
might or might not be garbage out."
[color=blue][color=green][color=darkred]
> >> One compiler I'm working with compiles this quietly, even with the
> >> most stringent and pedantic ANSI and warning levels, but generates
> >> code that only loads the address of "f" and fails to make the
> >> addition before returning a value from "main".[/color][/color][/color]

You mean that on this compiler, the expressions

(int)f AND (int)f+5

compile to the same machine code? This is odd, but perfectly legitimate,
behavior for a conforming optimizing C compiler as long as it documents
its behavior in a conforming fashion. There's nothing wrong with your
compiler (although I would say it's a weird one); there is something
wrong with your test suite.

[BTW, if any experts could explain what 6.3.2.3 #6 means by
"except as previously specified," I'd love to hear it. I don't
recall any "previously specified" cases of the pointer-to-integer
cast's being defined.]

-Arthur

[Malcolm]

Re: Arithmetic on function address


"Stephen Biggs"[color=blue]
> Given this code:
> void f(void){}
> int main(void){retu rn (int)f+5;}
>
> One compiler ... generates code that only loads the address of "f"
> and fails to make the addition before returning a value from "main".
>[/color]
Something funny is going on. As others have pointed out legally the compiler
can do anything with such a construct, but if it allows a cast from main to
f then it should put the address of main() in the integer register and then
add five to it. However how are you checking this? Is it by writing a second
program in which main() is possibly in a different position?
Why not see if you can get an assembly lisiting of the program to see what
code is being compiled?

[Stephen Biggs]

Re: Arithmetic on function address

Eric Sosman <Eric.Sosman@su n.com> wrote in
news:4089813E.7 7879D4C@sun.com :
[color=blue]
> Stephen Biggs wrote:[color=green]
>>
>> Eric Sosman <Eric.Sosman@su n.com> wrote in
>> news:4089560E.9 86D134A@sun.com :
>>[color=darkred]
>> > Stephen Biggs wrote:
>> >>
>> >> Given this code:
>> >> void f(void){}
>> >> int main(void){retu rn (int)f+5;}
>> >>
>> >> Is there anything wrong with this in terms of the standards?
>> >
>> > Yes and no. The Standard permits you to cast a pointer
>> > value (even a function pointer value) to an integer, but it
>> > does not guarantee that the result is useful or even usable.[/color]
>>
>> But, it then should allow you to add a value to that integer, as the
>> code says, no? Is this what you mean by no guarantees of it being
>> usable?[/color]
>
> If you're testing compilers (as you say later on), you really
> ought to get yourself a copy of the Standard[/color]


Yes... I should, but I am doing this as an employee of a company and
they are too cheap to buy it... :(

[color=blue]
> -- which says (in
> section 6.2.3, paragraph 6):
>
> Any pointer type may be converted to an integer type.
> Except as previously specified [not relevant here],
> the result is implementation-defined. If the result
> cannot be represented in the integer type, the behavior
> is undefined. The result need not be in the range of
> values of any integer type.
>
> So: The result of the conversion is implementation-defined, and
> need not be a valid value for an `int', and any attempt to create
> an invalid value causes undefined behavior. That's "unusable" in
> my book. (Gurus: Contrast this paragraph with the apparently
> stronger conditions of 6.3.1.3/3: pointer-to-int can generate
> U.B. instead of raising an implementation-defined signal.)[/color]


Ok... I understand this... that's just it... the code that this compiler
generates does the conversion and actually returns the address of the
function as an integer. It just silently discards the addition. If
this is implementation behavior, shouldn't it (as you say below about
compilers needing to give more than just what the standard says) either
complain about an invalid value or do the addition also, since it
accepts the conversion in the first place? The function address is
converted to an integer since this is what is returned, so the integer
value should be available for more computation if needed.

Any other behavior, such as what is happening here, is a bug in the
compiler IMHO.
[color=blue]
>[color=green][color=darkred]
>> >> Is this legal C code?
>> >
>> > Legal but useless.[/color]
>>
>> Ok, fine... I agree completely that it is useless, but shouldn't
>> correct code be generated for it?[/color]
>
> It's hard to understand what "correct" means when describing
> what might be undefined behavior.[/color]


According to the definition above about "undefined behavior", as I read
it, since function addresses as well as all other pointers in this
compiler are the same size as an int (32 bits), then doing this
conversion is definitely defined. Thus, dropping the addition after
making the conversion is a bug.
[color=blue]
> I think you need to do two
> things before concluding that the generated code is "incorrect: "
> You need to consult the compiler's own documentation to find how
> it defines the conversion result, and you then need to determine
> whether the result is in range for an `int'. Then:
>
> - If the conversion result is defined but out of range,
> you have no grounds for complaint. Any and all behaviors
> (hence any and all generated code) are "correct."
>
> - If the conversion result is defined and in range, you
> may have reason to complain.[/color]


That is exactly what is happening here... a function pointer or any
other pointer is the same size as an unsigned int (32 bits). Smaller
actually, here, so it fits in a signed int.
[color=blue]
>
> - If the conversion result is not defined, you have reason
> to complain about the documentation, but not (yet) about
> the code generation.[/color]


See above. If I am reading right what you quoted from the standard, then
the behavior is defined. If the conversion result was not defined, then
shouldn't, at least, a warning (or even a pedantic remark) be generated?
This compiler is extremely anal about other aspects of ANSI/ISO C.
[color=blue]
>
> One observation about testing compilers: They usually must
> obey several standards, not just one, and some of these may be
> just "usual practice" rather than formal standards. That is,
> the C Standard represents a sort of "non-negotiable minimum"
> for a C implementation, but a C implementation that did *only*
> what the Standard required would not enjoy much success. The
> prospective users will also want POSIX support and/or Windows
> support, they'll want "friendly" behavior when they do things
> like clear a pointer to all-bits-zero, they'll want CHAR_BIT
> to equal (not exceed) 8, they'll want various guarantees about
> signal() behavior, and so on. They will *not* want the strictly-
> conforming but user-hostile C compiler of the DeathStation 9000!
>
> Next time you climb into your car, pause and take a look
> around. How many of the things you see could be removed without
> actually removing the car's ability to get you from Here to
> There? Rip out the radio, the air conditioner, the leather
> seats, the back seat, the side and rear windows, the power
> steering -- you'll still have a strictly-conforming car, but
> you might not want to drive it much.[/color]


Yes... but what "standard" is this car "conforming " to?
[color=blue]
>[/color]
Thanks for the help, Eric.

[Keith Thompson]

Re: Arithmetic on function address

Stephen Biggs <Spammers@AreLo wLifes.com-INVALID-MUNGED> writes:[color=blue]
> Given this code:
> void f(void){}
> int main(void){retu rn (int)f+5;}
>
> Is there anything wrong with this in terms of the standards? Is this legal
> C code? One compiler I'm working with compiles this quietly, even with the
> most stringent and pedantic ANSI and warning levels, but generates code
> that only loads the address of "f" and fails to make the addition before
> returning a value from "main".
>
> GCC "does the right thing".
>
> Is there something I'm missing?[/color]

That's a very odd way to examine the value of an integer expression.
On many systems, the value returned from main doesn't directly map to
the status returned by the program (returning just the low-order 8
bits is common).

You shouldn't expect the result of casting a function address to int
to be at all meaningful, but it does seem odd that you're not seeing
the addition of 5 in the generated code. Is it possible that the
addition is being done during compilation or linking?

Try something like this:

#include <stdio.h>
void f(void){}
int main(void){prin tf("(int)f+5 = %d\n", (int)f+5);retur n 0;}

with and without the "+5" (but be aware that adding code to main()
could change the address of f()).

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[CBFalconer]

Re: Arithmetic on function address

Eric Sosman wrote:[color=blue]
>[/color]
.... snip ...[color=blue]
>
> Next time you climb into your car, pause and take a look
> around. How many of the things you see could be removed without
> actually removing the car's ability to get you from Here to
> There? Rip out the radio, the air conditioner, the leather
> seats, the back seat, the side and rear windows, the power
> steering -- you'll still have a strictly-conforming car, but
> you might not want to drive it much.[/color]

Apart from the leather seats, that sounds like a 1954 MG TD. I
would be happy to drive one. :-)

--
Chuck F (cbfalconer@yah oo.com) (cbfalconer@wor ldnet.att.net)
Available for consulting/temporary embedded and systems.
<http://cbfalconer.home .att.net> USE worldnet address!

[Mark McIntyre]

Re: Arithmetic on function address

On Fri, 23 Apr 2004 23:01:14 +0000 (UTC), in comp.lang.c , Stephen Biggs
<Spammers@AreLo wLifes.com-INVALID-MUNGED> wrote:
[color=blue]
>Eric Sosman <Eric.Sosman@su n.com> wrote in
>news:4089813E. 77879D4C@sun.co m:
>[color=green]
>>
>> If you're testing compilers (as you say later on), you really
>> ought to get yourself a copy of the Standard[/color]
>
>
>Yes... I should, but I am doing this as an employee of a company and
>they are too cheap to buy it... :([/color]

If your employer can't affort an $18 download from the ANSI website, you
need a different job. At the very least buy it yourself.

--
Mark McIntyre
CLC FAQ <http://www.eskimo.com/~scs/C-faq/top.html>
CLC readme: <http://www.angelfire.c om/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 =---

[Jack Klein]

Re: Arithmetic on function address

On Fri, 23 Apr 2004 23:01:14 +0000 (UTC), Stephen Biggs
<Spammers@AreLo wLifes.com-INVALID-MUNGED> wrote in comp.lang.c:

[snip]
[color=blue]
> See above. If I am reading right what you quoted from the standard, then
> the behavior is defined. If the conversion result was not defined, then
> shouldn't, at least, a warning (or even a pedantic remark) be generated?
> This compiler is extremely anal about other aspects of ANSI/ISO C.[/color]

You or your employer really need to spend the $18.00 to download a PDF
copy of the standard. You fail to understand the full meaning of
undefined behavior, which is a very important concept in C.

Undefined behavior relieves the implementation (i.e., compiler) of any
and all obligations as far as the C standard is concerned. Most
specifically, no diagnostic of any kind is ever required in the event
of undefined behavior.

--
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.l earn.c-c++

http://www.contrib.andrew.cmu.edu/~ajo/docs/FAQ-acllc.html

[Malcolm]

Re: Arithmetic on function address


"Jack Klein" <jackklein@spam cop.net> wrote in message[color=blue]
>
> Most specifically, no diagnostic of any kind is ever required in the
> event of undefined behavior.
>[/color]
Though a program that evokes UB is not a correct C program. So a compiler
should issue a diagnostic if possible, and the reason this is not mandated
is that it is often technically too hard for the compiler to do.

[Keith Thompson]

Re: Arithmetic on function address

Mark McIntyre <markmcintyre@s pamcop.net> writes:[color=blue]
> On Fri, 23 Apr 2004 23:01:14 +0000 (UTC), in comp.lang.c , Stephen Biggs
> <Spammers@AreLo wLifes.com-INVALID-MUNGED> wrote:[color=green]
> >Eric Sosman <Eric.Sosman@su n.com> wrote in
> >news:4089813E. 77879D4C@sun.co m:[color=darkred]
> >> If you're testing compilers (as you say later on), you really
> >> ought to get yourself a copy of the Standard[/color]
> >
> >Yes... I should, but I am doing this as an employee of a company and
> >they are too cheap to buy it... :([/color]
>
> If your employer can't affort an $18 download from the ANSI website, you
> need a different job. At the very least buy it yourself.[/color]

But read the licensing terms first. Paying $18 for a copy of the
standard and making it generally available to employees would violate
the license. The safest thing to do would probably be to spend $18
per programmer and give each programmer his/her own copy.

IANAL, please do not trust any statements I make about copyright law
and licensing.

--
Keith Thompson (The_Other_Keit h) kst-u@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <*> <http://users.sdsc.edu/~kst>
Schroedinger does Shakespeare: "To be *and* not to be"

[Dan Pop]

Re: Arithmetic on function address

In <4089813E.77879 D4C@sun.com> Eric Sosman <Eric.Sosman@su n.com> writes:
[color=blue]
>Stephen Biggs wrote:[color=green]
>>
>> Eric Sosman <Eric.Sosman@su n.com> wrote in
>> news:4089560E.9 86D134A@sun.com :
>>[color=darkred]
>> > Stephen Biggs wrote:
>> >>
>> >> Given this code:
>> >> void f(void){}
>> >> int main(void){retu rn (int)f+5;}
>> >>
>> >> Is there anything wrong with this in terms of the standards?
>> >
>> > Yes and no. The Standard permits you to cast a pointer
>> > value (even a function pointer value) to an integer, but it
>> > does not guarantee that the result is useful or even usable.[/color]
>>
>> But, it then should allow you to add a value to that integer, as the
>> code says, no? Is this what you mean by no guarantees of it being
>> usable?[/color]
>
> If you're testing compilers (as you say later on), you really
>ought to get yourself a copy of the Standard -- which says (in
>section 6.2.3, paragraph 6):
>
> Any pointer type may be converted to an integer type.
> Except as previously specified [not relevant here],
> the result is implementation-defined. If the result
> cannot be represented in the integer type, the behavior
> is undefined. The result need not be in the range of
> values of any integer type.
>
>So: The result of the conversion is implementation-defined, and
>need not be a valid value for an `int', and any attempt to create
>an invalid value causes undefined behavior. That's "unusable" in
>my book.[/color]

Not in mine. The feature works in an *implementation-defined* way.
If I want to test it on a given compiler, I *must* first read its
documentation. If the documentation says: "the feature is useless on
this compiler", then, there is no point in testing it. If it assigns
meaningful and useful semantics to it, then I can test whether it
really works as advertised.

The feature is far from useless, as pointed out in a different thread,
because it is the *only* way of printing the value of a pointer to
function without automatically invoking undefined behaviour, unless the
implementation explicitly makes it useless for this purpose.

Granted, it can't be used in strictly conforming programs. So what,
neither can fopen and friends, yet we keep recommending them all the time.

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