请教一个基础问题——数组名减1是否可以

OwnWaterloo

用VC6写出的程序， 我们就不指望它的可移植性了吧

而且， 你们的出发点都是以自我需求为中心的 ： 我不需要， 在我看来大部分人不需要； 我只用VC（GCC） —— 所以，标准算老几，我跟你说， 没事！

但是， lz既然有这个需求， 那可能lz就真的关心这点可移植性， 真的需要移植到乱七八糟的机器上去呢？
难道告诉他， lz， 放弃那些机器吧？
这不是解决问题的方式， 是在逃避问题。


另外， 代码生成也是人写的。 同样可以注意越界问题就是了。

原帖由 reiase 于 2009-12-17 22:27 发表
顶多有几个刚知道负下标的小毛孩为此写两段“证明自己聪明的程序”

让我想起了 ：

原帖由 file3 于 2009-12-16 13:32 发表
看看这个
int a[10];
1[a];
可以编译通过哦

zx_wing

6.3.2.3 Pointers
1 A pointer to void may be converted to or from a pointer to any incomplete or object
type.  A pointer to any incomplete or object type may be converted to a pointer to void
and back again; the result shall compare equal to the original pointer.
2 For any qualifier q, a pointer to a non-q-qualified type may be converted to a pointer to
the q-qualified version of the type; the values stored in the original and converted pointers
shall compare equal.
3 An integer constant expression with the value 0, or such an expression cast to type void
46)
*, is called a null pointer constant. If a null pointer constant is assigned to or
compared for equality to a pointer, the constant is converted to a pointer of that type.
Such a pointer, called a null pointer, is guaranteed to compare unequal to a pointer to any
object or function.

Conversion of a null pointer to another pointer type yields a null pointer of that type.
Anytwo null pointers shall compare equal.
An integer may be converted to any pointer type. The result is implementation-defined,
47)
might not be properly aligned, and might not point to an entity of the referenced type.
Any pointer type may be converted to an integer type; 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 anyinteger type.
A pointer to an object or incomplete type may be converted to a pointer to a different
48)
object or incomplete type. If the resulting pointer is not correctly aligned for the
pointed-to type, the behavior is undefined. Otherwise, when converted back again, the
result shall compare equal to the original pointer. When a pointer to an object is
converted to a pointer to a character type, the result points to the lowest addressed byte of
the object. Successive increments of the result, up to the size of the object, yield pointers
to the remaining bytes of the object.
A pointer to a function of one type may be converted to a pointer to a function of another
type and back again; the result shall compare equal to the original pointer. If a converted
pointer is used to call a function whose type is not compatible with the pointed-to type,
the behavior is undefined.

from ansi c standard

[ 本帖最后由 zx_wing 于 2009-12-17 23:02 编辑 ]

OwnWaterloo

说实话， 标准里面这段是我最熟悉的一段。

但这能证明什么？？？
implementation-defined， might not...  ， undefined.
没有任何一句说指针和整数的转换是有良好定义的， 最好的情况也是实现定义的。
你得去翻编译器手册。

这也是我比较愁的问题。 本以为c99的stdint.h中的(u)intptr_t有帮助。 但(u)intptr_t是optional的。

OwnWaterloo

给你帖个能证明我的观点的文章吧， 你帖的那段标准， 完全是帮我说话的……


http://www.c-faq.com/ptrs/int2ptr.html

Q: How are integers converted to and from pointers? Can I temporarily stuff an integer into a pointer, or vice versa?

A: Once upon a time, it was guaranteed that a pointer could be converted to an integer (though one never knew whether an int or a long might be required), and that an integer could be converted to a pointer, and that a pointer remained unchanged when converted to a (large enough) integer and back again, and that the conversions (and any mapping) were intended to be ``unsurprising to those who know the addressing structure of the machine.'' In other words, there is some precedent and support for integer/pointer conversions, but they have always been machine dependent, and hence nonportable. Explicit casts have always been required (though early compilers rarely complained if you left them out).

The ANSI/ISO C Standard, in order to ensure that C is widely implementable, has weakened those earlier guarantees. Pointer-to-integer and integer-to-pointer conversions are implementation-defined (see question 11.33), and there is no longer any guarantee that pointers can be converted to integers and back, without change.

Forcing pointers into integers, or integers into pointers, has never been good practice. When you need a generic slot that can hold either kind of data, a union is a much better idea.

这很直接的说明了存在int和指针不能随意转换的机器。 否则C标准不会在这里无故将保证减弱。

[ 本帖最后由 OwnWaterloo 于 2009-12-17 23:21 编辑 ]

zx_wing

原帖由 OwnWaterloo 于 2009-12-17 23:08 发表
说实话， 标准里面这段是我最熟悉的一段。

但这能证明什么？？？
implementation-defined， might not...  ， undefined.
没有任何一句说指针和整数的转换是有良好定义的， 最好的情况也是实现定义的 ...

唉，标准没说清楚，是因为硬件平台多样的，整形的长短也是不同的，无法用一句准确的话概括出适用于所有情况。
但标准不说清楚，就留下了空间，就可以杜撰出奇奇怪怪的东西，比如你说的指针回绕。
所以我说要结合实践才能谈理论，因为光谈理论的话，就永远有理论上存在而实际不存在的情况出现。

OwnWaterloo

原帖由 zx_wing 于 2009-12-17 23:21 发表
唉，标准没说清楚，是因为硬件平台多样的，整形的长短也是不同的，无法用一句准确的话概括出适用于所有情况。
但标准不说清楚，就留下了空间，就可以杜撰出奇奇怪怪的东西，比如你说的指针回绕。

你这部分观点我认为正确。 但这个观点， 可以证明lz的问题吗？
这部分观点能证明什么？
恰好证明lz的问题 —— 数组名 -1 —— 是没有保证的。 而不是有保证的。

原帖由 zx_wing 于 2009-12-17 23:21 发表
所以我说要结合实践才能谈理论，因为光谈理论的话，就永远有理论上存在而实际不存在的情况出现。

见ls， C标准为什么要降低保证？ 如果这种情况实际上不存在， 它为什么要降低保证？


理论研究也是很重要的。 你能保证那些奇奇怪怪的东西一直会停留在理论而不可能实际存在？

而且你的态度是在逃避lz的问题。
就好像别人问cout 如何控制最小域宽， 你给他说用printf一样。
lz需要考虑这点移植性， 你凭什么将他的需求砍掉？


你喜欢实践， 但别人研究理论就错了吗？？？ 就是不应该的， 就是不重要的？ 就是一定不可能实际出现的？

chenzhanyiczy

zx_wing 耐性真好，算了吧，费口水的

盗用某人的一句话：
人不能被说服，除非他(她/它)自己愿意相信。

OwnWaterloo

所以我根本不愿意在你身上多浪费口水

论坛热点

你总是这样回帖，即使你观点正确，也只能说明你很肤浅，知道么。

OwnWaterloo

哦， 原来你欣赏的是抱着错误观点装深沉， 难怪难怪