指针算术的合法性 [英] Legality of pointer arithmetic

问题描述

我一直在查看C99规范的委员会草案，

特别是这个URI的那个：
http://www.open-std.org/jtc1/sc22/wg.../文档/ n843.pdf 。我没有

a官方国际标准的副本，但我认为它类似于

。


指针算术规则（6.5.6.7-8）附于下面，以便

易于参考。他们似乎有惊人的限制。据我所知，b $ b见，不能保证代码：


char * p = malloc（10）; / *假设这个malloc成功* /

p [2] =''x'';


会在第三个字节写一个''x''分配的商店;事实上，

该代码的行为是完全未定义的。


（表达式p [2]被定义为相当于*（p + 2） ）;; p + 2不是与b相同的数组对象的一部分，因此行为是未定义的。）


这可能是正确的吗？我是否误读了这个规范，那个规范是否错误地表达了这种语言（或者是否存在另一种可能性）？


期待你的集体智慧，

Robin

从6.5.6节添加剂操作员：

7用于这些运算符，指向非阵列对象的指针

的行为与指向

长度的数组的第一个元素的指针相同，其中对象的类型为其元素类型。


8当一个具有整数类型的表达式从指针中添加或减去
时，结果具有指针操作数的类型。如果

指针操作数指向数组对象的一个​​元素，并且数组

足够大，则结果指向一个元素偏离

原始元素，使得

结果和原始数组元素的下标的差异等于整数表达式。在

中，如果表达式P指向数组的第i个元素

对象，则表达式（P）+ N（等效地，N +（P） ）和（P）-N（其中N

的值为n）分别指向数组中的第i + n和第......

表达式P指向数组对象的最后一个元素，则

表达式（P）+1指向数组对象的最后一个元素，

如果表达式Q指向一个数组的最后一个元素

对象，则表达式（Q）-1指向数组的最后一个元素

对象。如果指针操作数和结果都指向

的元素相同的数组对象，或者一个超过数组的最后一个元素

对象，则评估不应产生溢出;否则，

行为未定义。如果结果指向数组对象的最后一个元素

之后，则不应将其用作评估的一元*

运算符的操作数。

解决方案

ho ****** @ mailinator.com 写道：

我一直在查看C99规范的委员会草案，
特别是这个URI的那个：
http://www.open-std.org /jtc1/sc22/wg.../docs/n843.pdf 。我没有官方国际标准的副本，但我认为它是相似的。


最新的草稿是n869，可在以下网址找到：
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/

char * p = malloc（10）; / *假设这个malloc成功* /
p [2] =''x'';

将'x''写入分配的商店的第三个字节;事实上，该代码的行为是完全未定义的。

（表达式p [2]被定义为等同于*（p + 2）; p + 2不是
与p相同的数组对象的一部分，因此行为未定义。）

7.20.3p1（malloc）：

''如果分配成功，则返回指针，因此

可以将其分配给指向任何类型对象的指针，然后使用
来访问这样的对象空间中的一系列此类物品

已分配''


Robert Gamble

Robert Gamble写道：

ho******@mailinator.com 写道：

我一直在查看C99规范的委员会草案，
特别是这个URI的那个：
http://www.open-std.org/jtc1/sc22/wg.../docs/n843.pdf 。我没有官方国际标准的副本，但我认为它是相似的。

最新的草案是n869可用于：
http：// www.open-std.org/jtc1/sc22/wg14/www/docs/n869/

尝试：< http：// www。 open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>


这是包含更正的2005年草案。

不幸的是没有文字版本。


-

"如果你想通过groups.google.com发布后续内容，请不要使用

破损的回复链接在文章的底部。点击

" show options"在文章的顶部，然后点击

回复在文章标题的底部。 - Keith Thompson

ho******@mailinator.com 写道：

我一直在查看C99规范的委员会草案，
特别是这个URI的那个：
http：/ /www.open-std.org/jtc1/sc22/wg.../docs/n843.pdf 。我没有官方国际标准的副本，但我认为它是相似的。

指针算术的规则（6.5.6.7-8）附件如下，以便于参考。他们似乎有惊人的限制。据我所知，无法保证代码：

char * p = malloc（10）; / *假设这个malloc成功* /
p [2] =''x'';

将'x''写入分配的商店的第三个字节;事实上，该代码的行为是完全未定义的。

（表达式p [2]被定义为等同于*（p + 2）; p + 2不是
与p相同的数组对象的一部分，因此行为未定义。）
[...]

你忽略了7.20 .3：[...]返回的指针[...]

可以分配给指向任何类型对象的指针，然后使用

来访问这样的对象*或这些对象的数组* [...]"

（强调我的。）


-
< a href =mailto：Er ********* @ sun.com> Er ********* @ sun.com

I''ve been looking at the committee draft of the C99 specification,
specifically the one at this URI:
http://www.open-std.org/jtc1/sc22/wg.../docs/n843.pdf. I don''t have
a copy of the official international standard, but I assume that it is
similar.

The rules for pointer arithmetic (6.5.6.7-8) are appended below for
ease of reference. They seem astonishingly restrictive. As far as I can
see, there is no guarantee that the code:

char *p = malloc(10); /* assume this malloc succeeds */
p[2] = ''x'';

will write an ''x'' into the third byte of the allocated store; in fact,
the behaviour of that code is completely undefined.

(The expression p[2] is defined to be equivalent to *(p+2); p+2 is not
part of the same array object as p, hence the behaviour is undefined.)

Can that possibly be right? Am I misreading the spec, is the spec
misrepresenting the language (or is there another possiblity)?

In anticipation of your collective wisdom,
Robin

From section 6.5.6 "Additive operators":

7 For the purposes of these operators, a pointer to a nonarray object
behaves the same as a pointer to the first element of an array of
length one with the type of the object as its element type.

8 When an expression that has integer type is added to or subtracted
from a pointer, the result has the type of the pointer operand. If the
pointer operand points to an element of an array object, and the array
is large enough, the result points to an element offset from the
original element such that the difference of the subscripts of the
resulting and original array elements equals the integer expression. In
other words, if the expression P points to the i-th element of an array
object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N
has the value n) point to, respectively, the i+n-th and i-n-th
elements of the array object, provided they exist. Moreover, if the
expression P points to the last element of an array object, the
expression (P)+1 points one past the last element of the array object,
and if the expression Q points one past the last element of an array
object, the expression (Q)-1 points to the last element of the array
object. If both the pointer operand and the result point to elements of
the same array object, or one past the last element of the array
object, the evaluation shall not produce an overflow; otherwise, the
behavior is undefined. If the result points one past the last element
of the array object, it shall not be used as the operand of a unary *
operator that is evaluated.

解决方案

ho******@mailinator.com wrote:

I''ve been looking at the committee draft of the C99 specification,
specifically the one at this URI:
http://www.open-std.org/jtc1/sc22/wg.../docs/n843.pdf. I don''t have
a copy of the official international standard, but I assume that it is
similar.
The most recent draft is n869 available at:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/

The rules for pointer arithmetic (6.5.6.7-8) are appended below for
ease of reference. They seem astonishingly restrictive. As far as I can
see, there is no guarantee that the code:

char *p = malloc(10); /* assume this malloc succeeds */
p[2] = ''x'';

will write an ''x'' into the third byte of the allocated store; in fact,
the behaviour of that code is completely undefined.

(The expression p[2] is defined to be equivalent to *(p+2); p+2 is not
part of the same array object as p, hence the behaviour is undefined.)

7.20.3p1 (malloc):
''The pointer returned if the allocation succeeds is suitably aligned so
that it may be assigned to a pointer to any type of object and then
used to access such an object or an array of such objects in the space
allocated''

Robert Gamble

Robert Gamble wrote:

ho******@mailinator.com wrote:

I''ve been looking at the committee draft of the C99 specification,
specifically the one at this URI:
http://www.open-std.org/jtc1/sc22/wg.../docs/n843.pdf. I don''t have
a copy of the official international standard, but I assume that it is
similar.

The most recent draft is n869 available at:
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n869/

try: <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1124.pdf>

which is the 2005 draft incorporating the corrigendae.
Unfortunately there is no text version.

--
"If you want to post a followup via groups.google.com, don''t use
the broken "Reply" link at the bottom of the article. Click on
"show options" at the top of the article, then click on the
"Reply" at the bottom of the article headers." - Keith Thompson

ho******@mailinator.com wrote:

I''ve been looking at the committee draft of the C99 specification,
specifically the one at this URI:
http://www.open-std.org/jtc1/sc22/wg.../docs/n843.pdf. I don''t have
a copy of the official international standard, but I assume that it is
similar.

The rules for pointer arithmetic (6.5.6.7-8) are appended below for
ease of reference. They seem astonishingly restrictive. As far as I can
see, there is no guarantee that the code:

char *p = malloc(10); /* assume this malloc succeeds */
p[2] = ''x'';

will write an ''x'' into the third byte of the allocated store; in fact,
the behaviour of that code is completely undefined.

(The expression p[2] is defined to be equivalent to *(p+2); p+2 is not
part of the same array object as p, hence the behaviour is undefined.)
[...]

You''ve overlooked 7.20.3: "[...] The pointer returned [...]
may be assigned to a pointer to any type of object and then used
to access such an object *or an array of such objects* [...]"
(Emphasis mine.)

--
Er*********@sun.com

这篇关于指针算术的合法性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！