关于函数地址的算术 [英] Arithmetic on function address
问题描述
鉴于此代码：
void f（void）{}
int main（void）{return（int）f + 5;}
标准方面有什么问题吗？这是合法的
C代码吗？我正在使用的一个编译器悄悄编译，即使使用最严格和最迂腐的ANSI和警告级别，但生成代码
只加载地址 ; F"
从'main'返回一个值之前没有添加。
GCC做正确的事情。
有什么我想念的吗？
Stephen Biggs写道：<鉴于此代码：
void f（void）{}
int main（void）{return（int）f + 5;}
是否有任何问题这在标准方面？
是和否。标准允许您将指针
值（甚至函数指针值）转换为整数，但它不能保证结果有用甚至可用。
这是合法的C代码吗？
合法但无用。
我正在使用的一个编译器安静地编译它，即使是最严格和最迂腐的ANSI和警告级别，但生成只加载f的地址的代码
从主返回一个值之前没有进行添加。
GCC做正确的事情。
我有什么东西吗？我失踪了吗？
你的大理石，也许吧。 ;-)你想用这个定义不明确的操作来实现
是什么？
-
Er ********* @ sun.com
Eric Sosman <尔********* @ sun.com>写在
新闻：40 *************** @ sun.com：
Stephen Biggs写道：< blockquote class =post_quotes>
鉴于此代码：
void f（void）{}
int main（void）{return（int）f + 5;}
标准方面有什么问题吗？
是和否。标准允许您将指针
值（甚至函数指针值）转换为整数，但它不保证结果有用甚至可用。
但是，它应该允许你为该整数添加一个值，因为
代码说，不是吗？这是你的意思吗？不保证它可用吗？
$ blockquote class =post_quotes>这是合法的C代码吗？
合法但没用。
好的，很好......我完全同意它没用，但是不应该正确
为它生成代码？
我正在使用的一个编译器安静地编译它，即使使用最严格和最迂腐的ANSI和警告级别，但生成的代码只加载f的地址。并且在从main返回值之前没有添加
。
GCC做正确的事情。
我有什么东西吗？我失踪了？
你的大理石，也许吧。 ;-)你想用这个定义不明确的操作来完成什么？
谢谢你：）...我不是想除了
之外，还有其他一些编译器运行GCC测试套件，我正在尝试进行
分析。这是测试套件的一部分，并通过GCC，没有
问题...我只是想知道这是否是编译器中的一个错误我想要运行的b $ b这段代码？我想确定这应该在我哭bug之前正确生成代码。也就是说，它应该
生成代码，在指针转换为
整数后添加常量。
谢谢任何帮助。
Stephen Biggs写道：
Eric Sosman< Er ********* @ sun.com>在
新闻中写道：40 *************** @ sun.com：
Stephen Biggs写道：
鉴于此代码：
void f（void）{}
int main（void）{return（int）f + 5;}
是在标准方面有什么不妥吗？
是和否。标准允许您将指针
值（甚至函数指针值）转换为整数，但它不保证结果有用甚至可用。
但是，它应该允许你为该整数添加一个值，因为
代码说，不是吗？这是你的意思，不保证它可用吗？
如果你正在测试编译器（正如你后面所说），你真的
应该得到一份标准副本 - 其中说明（在
第6.2.3节第6段中）：
任何指针类型都可以转换为整数类型。
除了之前指定的[此处不相关]，
结果是实现定义的。如果结果
无法以整数类型表示，则行为
未定义。结果不必在任何整数类型的
值的范围内。
所以：转换的结果是实现定义的，并且
不一定是'int''的有效值，任何创建
无效值的尝试都会导致未定义的行为。这是无法使用的在
我的书。 （Gurus：将这一段与6.3.1.3/3显然更强的条件进行对比：指向int的指针可以生成
UB而不是提出实现定义的信号。）
这是合法的C代码吗？
法律但是没用。
好的，很好......我完全同意它没用，但是不应该为它生成代码吗？
很难理解什么是正确的表示在描述
时可能是未定义的行为。我认为在得出生成的代码不正确之前你需要做两件事b / b
你需要查阅编译器自己的文档来查找
如何定义转换结果，然后你需要确定
结果是否在int的范围内。然后：
- 如果转换结果已定义但超出范围，
您没有理由投诉。任何和所有行为
（因此任何和所有生成的代码）都是正确的。
- 如果转换结果已定义且在范围内，你好
可能有理由抱怨。
- 如果转换结果没有定义，你有理由
来抱怨文档，但不是（还）关于
代码生成。
关于测试编译器的一个观察：他们通常必须
遵守几个标准，而不仅仅是一个标准，其中一些标准可能仅仅是通常的做法。而不是正式的标准。也就是说，C标准对于C实现来说代表了一种不可协商的最小值
，但是C实现只做* * * br / >
标准要求不会取得多大成功。
预期用户还需要POSIX支持和/或Windows
支持，他们会想要友好的他们做事时的行为
清除指向所有位零的指针，他们会希望CHAR_BIT
等于（不超过）8，他们会想要各种保证
signal（）行为，等等。他们*不会*想要严格的
符合但用户恶意的DeathStation 9000 C编译器！
下次你爬上车，暂停并看一下
左右。你看到的有多少东西可以在没有
的情况下移除，实际上除去了汽车从这里到达的能力
那里？撕掉收音机，空调，皮革座椅，后座，侧窗和后窗，电源
转向 - 你还会有一辆符合标准的汽车，但是你可能不想开车太多。
-
Er ********* @ sun.com
Given this code:
void f(void){}
int main(void){return (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?
Stephen Biggs wrote:
Given this code:
void f(void){}
int main(void){return (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.
Is this legal C code?
Legal but useless.
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?
Your marbles, perhaps. ;-) What are you trying to
accomplish with this ill-defined operation?
--
Er*********@sun.com
Eric Sosman <Er*********@sun.com> wrote in
news:40***************@sun.com:
Stephen Biggs wrote:
Given this code:
void f(void){}
int main(void){return (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.
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?
Is this legal C code?
Legal but useless.
Ok, fine... I agree completely that it is useless, but shouldn''t correct
code be generated for it?
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?
Your marbles, perhaps. ;-) What are you trying to
accomplish with this ill-defined operation?
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.
Stephen Biggs wrote:
Eric Sosman <Er*********@sun.com> wrote in
news:40***************@sun.com:Stephen Biggs wrote:
Given this code:
void f(void){}
int main(void){return (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.
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?
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.)
Is this legal C code?
Legal but useless.
Ok, fine... I agree completely that it is useless, but shouldn''t correct
code be generated for it?
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.
--
Er*********@sun.com
这篇关于关于函数地址的算术的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
