更好的免费（无效指针）行为？ [英] Better free(invalid pointer) behavior?

问题描述

对于某些N> 0，设p = malloc（N）。据我了解，免费（p + k）

0< k< N导致未定义的行为，因为只有一个指针返回（m |

re | c）alloc（）可以有效地传递给free（）。​​


这看起来很傻。不会更好的行为是免费的（）是

假设如果它收到q，其中q位于某些malloc（）中ated-and-

还没有-free（）d块从p开始，那么它应该解释为

free（p）？


更好的是，* alloc（）例程可以在他们返回的块之间留下一个备用字节，以便免费（p + N）也相当于

free（p）。


这样可以让一个人在分配的区块内移动p，而不需要

总是要跟踪区块的起始位置 -

乏味似乎只会混淆一个人的代码的业务。

解决方案

一个********* @ googlemail.com 写道：

设p = malloc （N）对于某些N> 0。据我了解，免费（p + k）

0< k< N导致未定义的行为，因为只有一个指针返回（m |

re | c）alloc（）可以有效地传递给free（）。​​


这看起来很傻。不会更好的行为是免费的（）是

假设如果它收到q，其中q位于某些malloc（）中ated-and-

还没有-free（）d块从p开始，那么它应该把它解释为

free（p）？

对我而言似乎公平逻辑;你从

接口获得一个对象，然后将其传回去销毁。它是常见的设计，可以折磨初学者的混乱

就是从malloc返回指针的情况下

对象是要发送回接口的对象

和一个可用于访问内存区域的指针。

更好，* alloc（）例程可以在它们返回的块之间留下一个备用字节，以便free（p + N）也相当于

free（p） 。


这样可以让一个人在分配的区块内移动p，而不必总是跟踪区块的起始位置 - 一个

繁琐的业务，似乎只是混淆了一个人的代码。

这是一个有趣的想法，虽然听起来好像它会慢下来
下来并使malloc实现复杂化（需要一个

搜索分配的块。你什么时候发现保持

您要求原因混淆的对象？


-

imalone

********* @ googlemail.com 写道：

对于某些N> 0，设p = malloc（N）。据我了解，免费（p + k）

0< k< N导致未定义的行为，因为只有一个指针返回（m |

re | c）alloc（）可以有效地传递给free（）。

`free（p + k）`未定义任何k 0，事实上：你的限制

`< N`是误导。

这看起来很傻。

/ me /似乎完全合理。给你带回来的东西

out。

不会更好的行为（免费）是

假设如果它收到q，其中q位于某个malloc（）ated-and-

not-yet-free（）d块从p开始，那么它应该将其解释为

免费（p）？

编号因为现在`free（p）`必须从'p`

的值开始计算你的块' '释放开始，它必须快速完成

和紧凑。这是对实现的一个重要限制。

更好的是，* alloc（）例程可以在

之间留下一个备用字节他们返回的块，以便free（p + N）也相当于

free（p）。

我不知道为什么这是更好。

这会让一个在已分配的区块内移动p，没有

总是要跟踪区块的起始位置 - 这似乎只会混淆一个's
繁琐的业务码。

我从来没有发现它很乏味，我从来没有发现它混淆。它至少是一个带有明智名称的指针
，不是吗？


也许你应该展示一个例子。


-

Chris" electric hedgehog" Dollin

生活充满了神秘感。考虑其中一个。 Sinclair，/ Babylon 5 /

一个********* @ googlemail.com 写道：

设p = malloc（N）为某些N> 0 。据我了解，免费（p + k）

0< k< N导致未定义的行为，因为只有一个指针返回（m |

re | c）alloc（）可以有效地传递给free（）。

先前由* alloc返回的指针值，是的。

这看起来很傻。不会更好的行为是免费的（）是

假设如果它收到q，其中q位于某些malloc（）中ated-and-

还没有-free（）d块从p开始，那么它应该解释为

free（p）？


更好的是，* alloc（）例程可以在他们返回的块之间留下一个备用字节，以便免费（p + N）也相当于

free（p）。


这样可以让一个人在分配的区块内移动p，而不需要

总是要跟踪区块的起始位置 -

乏味似乎只是混淆了一个人的代码的业务。

恕我直言，将你从* alloc中获得的内容传递给更加清晰，而不是某些

任意值。几乎总是你需要跟踪块的开始，因为它不是很困难。


To为了避免破坏现有的实现，该标准已经强制执行此规则。这不是一个不方便的规则，它鼓励

保存指针值的良好编程习惯，然后再修改它们。

Let p=malloc(N) for some N>0. As far as I understand it, free(p+k) for
0<k<N causes undefined behavior, since only a pointer returned by (m|
re|c)alloc() can validly be passed to free().

This seems pretty silly. Wouldn''t a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?

Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).

This would let one move p around within the allocated block, without
always having to keep track of the start location of the block - a
tedious business that seems only to obfuscate one''s code.

解决方案

an*********@googlemail.com wrote:

Let p=malloc(N) for some N>0. As far as I understand it, free(p+k) for
0<k<N causes undefined behavior, since only a pointer returned by (m|
re|c)alloc() can validly be passed to free().

This seems pretty silly. Wouldn''t a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?

To me it seems fairly logical; you get an object from the
the interface, then pass it back to be destroyed. It''s
a common design, the confusion that can afflict beginners
is that in the case of a returned pointer from malloc the
object is both the object to be sent back to the interface
and a pointer which can be used to access a memory region.

Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).

This would let one move p around within the allocated block, without
always having to keep track of the start location of the block - a
tedious business that seems only to obfuscate one''s code.

It''s an intriguing idea, though it sounds as if it would slow
down and complicate malloc implementation (necessitating a
search for the allocated block. When do you find that keeping
the object you asked for causes obfuscation?

--
imalone

an*********@googlemail.com wrote:

Let p=malloc(N) for some N>0. As far as I understand it, free(p+k) for
0<k<N causes undefined behavior, since only a pointer returned by (m|
re|c)alloc() can validly be passed to free().

`free(p+k)` is undefined for any k 0, in fact: your restriction
`<N` is misleading.

This seems pretty silly.

It seems completely reasonable to /me/. Give back what you took
out.

Wouldn''t a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?

No. Because now `free(p)` has to work out from the value of `p`
where the block you''re freeing starts, and it has to do so quickly
and compactly. That''s a significant constraint on the implementation.

Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).

I don''t see why this is "better".

This would let one move p around within the allocated block, without
always having to keep track of the start location of the block - a
tedious business that seems only to obfuscate one''s code.

I''ve never found it tedious, and I''ve never found it obfuscating. It''s
at most one pointer with a sensible name, isn''t it?

Perhaps you should exhibit an example.

--
Chris "electric hedgehog" Dollin
"Life is full of mysteries. Consider this one of them." Sinclair, /Babylon 5/

an*********@googlemail.com wrote:

Let p=malloc(N) for some N>0. As far as I understand it, free(p+k) for
0<k<N causes undefined behavior, since only a pointer returned by (m|
re|c)alloc() can validly be passed to free().

A pointer value previously returned by *alloc, yes.

This seems pretty silly. Wouldn''t a better behavior of free() be to
assume that if it receives q, where q lies in some malloc()ated-and-
not-yet-free()d block starting at p, then it should interpret this as
free(p)?

Even better, the *alloc() routines could leave a spare byte between
the blocks they return so that free(p+N) would also be equivalent to
free(p).

This would let one move p around within the allocated block, without
always having to keep track of the start location of the block - a
tedious business that seems only to obfuscate one''s code.

IMHO, it''s cleaner to pass to free what you got from *alloc, not some
arbitrary value. Almost always you need to keep track of the start of
the block anyway, so it''s not as if it''s difficult.

To refrain from breaking existing implementations, the standard has
mandated this rule. It''s not an inconvinient rule, and it encourages
good programming practise of preserving pointer values, before
modifying them.

这篇关于更好的免费（无效指针）行为？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！