指针有效性 [英] Pointer validity
问题描述
有效指针有两种状态。要么为空（NULL），要么填写
地址，该地址必须是有效地址。
有效地址为：
1）当前的全球背景。
程序数据的第一个字节
直到最后一个字节。在这里我们找到静态表，全局上下文
指针等。
这是程序的全局变量。
2 ）当前范围和所有嵌套范围。当前范围由局部变量和参数的地址给出
。 A
保守
这个区域的估计是main（）中argc的地址或
$ b的
地址$ b在main中的第一个局部变量。通常情况下，一个程序永远不应该在其范围之外访问内存，但是它可以接收指向
更高的区域的指示
范围，所以如果彻底完成比较并不容易。
3）堆。到这个区域属于所有使用malloc（）
分配的地址，而不是传递给free（）。
快速程序tyo确定指针的有效性是：
1）检查地址是否在数据区中。如果
标准
为这些地址指定了一个名称，那将是很好的，但这在
环境中是很棘手的，那些地址不是''连续的。在这里我们
假设
编译器提供__first_data__和__last_data__。
2）检查地址是否在有效范围内堆栈我们需要两个
内存
再次比较。当前堆栈和顶部的存储值
。
我们假设编译器提供__top_of_stack__
3）堆。我们假设有一个程序来验证内存块。
所有这些在大多数情况下会花费几个内存读取，或者调用
到a
程序，如果是malloced块。
如果使用所有
指针自动执行这些测试怎么样？br />
传递给所有函数？
这会导致指针错误立即出现。这可能是以后断开连接的
。但是在开发的第一阶段，速度是不是很好，因为正确实现算法很重要。
指针错误是可能会在开发的第一阶段出现，
我们现在有办法让机器检查这些指针。
磨机的运行处理器现在运行在几个GHZ。一些内存
比较会减慢程序的速度，以至于在PC架构中完全透明。
当然，在嵌入式系统中情况有所不同，但对于PC中的开发人员而言，这将是一个很好的改进。
只是一些想法
jacob
Valid pointers have two states. Either empty (NULL), or filled with an
address that must be at a valid address.
Valid addresses are:
1) The current global context. The first byte of the data of the
program
till the last byte. Here we find static tables, global context
pointers, etc.
This are the global variables of the program.
2) The current scope and all nested scopes. The current scope is given
by the address of the local variables and the arguments. A
conservative
estimate of this area is the address of argc in main() or the
address of the
first local variable in main. Normally, a procedure should never
access
memory outside its scope, but it can receive pointers to areas in
higher
scopes, so the comparison is not easier if done throughly.
3) The heap. To this area belong all addresses allocated with malloc()
and not passed to free().
A fast procedure tyo determine the validity of a pointer could be:
1) Check if the address is in the data area. It would be nice if the
standard
specified a name for those addresses, but this is tricky in
environments where those addresses aren''t contiguous. Here we
suppose
that the compiler supplies __first_data__ and __last_data__.
2) To check if the address is within the valid stack we need two
memory
comparisons again. The current stack and the stored value of the top
of it.
We suppose the compiler provides __top_of_stack__
3) The heap. We suppose there is a procedure to verify a memory block.
All this would cost a couple of memory reads in most cases, or a call
to a
procedure, in case of malloced block.
What about making those tests automatically to do that with all
pointers
passed to all functions?
That would lead to pointer bugs surfacing immediately. This could be
disconnected later. But in the first phases of development, speed is
not so
important as correctly implementing the algorithm.
Pointer bugs are likely to surface in the first phases of development,
and we have the means now to put the machine to check those pointers.
A run of the mill processor now runs at several GHZ. Some memory
comparisons would slow down the program so little as to be completely
transparent in PC architectures.
Of course, in embedded systems the situation is different, but for C
developers in a PC this would be a good improvement.
Just some thoughts
jacob
推荐答案
" jacob navia" < JA *** @ jacob.remcomp.fr>在消息中写道
news：bq ********** @ news-reader5.wanadoo.fr ...
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:bq**********@news-reader5.wanadoo.fr...
有效指针有两种状态。要么为空（NULL），要么填充一个必须在有效地址的
地址。
有效地址是：
1）当前的全局上下文。
程序数据的第一个字节直到最后一个字节。这里我们找到静态表，全局上下文指针等。
这是程序的全局变量。
2）当前作用域和所有嵌套作用域。当前范围由局部变量和参数的地址给出。这个区域的保守
估计是main（）中argc的地址或main中第一个局部变量的
地址。通常情况下，程序不应该在其范围之外访问内存，但它可以接收指向更高范围内区域的指针，因此如果完全进行比较则不容易。 br />
3）堆。这个区域属于所有使用malloc（）
分配的地址，而不是传递给free（）。
以上所有都是特定于实施的，因此OFF
TOPIC。不需要堆或堆栈框架，因为我们知道并喜欢它们。实现被允许做他们想要的任何事情，好像行为似乎符合标准。
有效内存位置的指针可以来自外部
source（例如，由当前运行C程序的
以外的代理生成），并且可由当前运行的
C程序使用。
快速程序tyo确定指针的有效性可能是：
1）检查地址是否在数据区中。如果
标准指定了这些地址的名称会很好，但在这些地址不连续的
环境中这很棘手。在这里我们假设编译器提供__first_data__和__last_data__。
2）要检查地址是否在有效堆栈内，我们需要两个内存再次比较。当前堆栈及其顶部的存储值。
我们假设编译器提供__top_of_stack__
堆栈帧（如果实现）可以包含更多数据只需查看源代码中的
自动变量声明，就可以看到
。一个损坏的
指针恰好落在堆栈框架边界内
根据你的描述似乎是有效的。
3）堆。我们假设有一个验证内存块的过程。
标准不需要单个堆，当然
它的实现是不透明的，可能会有变化。
在大多数情况下，所有这些都会花费几次内存读取，或者在一个malloced块的情况下调用
程序。
如何自动执行这些测试将所有
指针传递给所有函数？
这会导致指针错误立即出现。这可能会在以后断开连接。但是在开发的第一阶段，速度并不像正确实现算法那么重要。
指针错误很可能在开发的第一阶段出现，我们现在有办法让机器检查那些指针。
一台磨机处理器现在运行在几个GHZ。一些内存的比较会使程序变慢，从而在PC架构中完全透明。
当然，在嵌入式系统中情况有所不同，但对于C <这是一个很好的改进。只需要一些想法
jacob
Valid pointers have two states. Either empty (NULL), or filled with an
address that must be at a valid address.
Valid addresses are:
1) The current global context. The first byte of the data of the
program
till the last byte. Here we find static tables, global context
pointers, etc.
This are the global variables of the program.
2) The current scope and all nested scopes. The current scope is given
by the address of the local variables and the arguments. A
conservative
estimate of this area is the address of argc in main() or the
address of the
first local variable in main. Normally, a procedure should never
access
memory outside its scope, but it can receive pointers to areas in
higher
scopes, so the comparison is not easier if done throughly.
3) The heap. To this area belong all addresses allocated with malloc()
and not passed to free().
All of the above is implementation specific and therefore OFF
TOPIC. There is no requirement for a heap or stackframe as we
know and love them. Implementations are allowed to do whatever
they want as if the behavior appears to conform to the standard.
Pointers to valid memory locations can come from an external
source (e.g., generated by an agent other than the currently
running C program), and be usable by the currently running
C program.
A fast procedure tyo determine the validity of a pointer could be:
1) Check if the address is in the data area. It would be nice if the
standard
specified a name for those addresses, but this is tricky in
environments where those addresses aren''t contiguous. Here we
suppose
that the compiler supplies __first_data__ and __last_data__.
2) To check if the address is within the valid stack we need two
memory
comparisons again. The current stack and the stored value of the top
of it.
We suppose the compiler provides __top_of_stack__
A stack frame, if implemented, can contain more data locations
than what would appear to be needed by just looking at the
automatic variable declarations in the source code. A corrupted
pointer that just happens to fall within the stackframe boundaries
would appear to be valid according to your description.
3) The heap. We suppose there is a procedure to verify a memory block.
A single heap is not required by the standard, and certainly
its implementation would be opaque and subject to change.
All this would cost a couple of memory reads in most cases, or a call
to a
procedure, in case of malloced block.
What about making those tests automatically to do that with all
pointers
passed to all functions?
That would lead to pointer bugs surfacing immediately. This could be
disconnected later. But in the first phases of development, speed is
not so
important as correctly implementing the algorithm.
Pointer bugs are likely to surface in the first phases of development,
and we have the means now to put the machine to check those pointers.
A run of the mill processor now runs at several GHZ. Some memory
comparisons would slow down the program so little as to be completely
transparent in PC architectures.
Of course, in embedded systems the situation is different, but for C
developers in a PC this would be a good improvement.
Just some thoughts
jacob
你的前提是有缺陷的，因此你的结论毫无意义。
有很多内存管理工具可以替代malloc（）和
朋友，用于查找堆损坏，悬空引用等。
这完全取决于实现细节，并且需要编译器才能使用
熟悉
堆的实现。
Your premise is flawed, therefore your conclusions are meaningless.
There are plenty of memory management tools out there that are
replacements for the common implementations of malloc() and
friends, for locating heap corruption, dangling references, etc.
It is all dependent upon implementation details and is something
that would require a compiler to have intimate knowledge of the
heap implementation.
" xarax" < xa的*** @ email.com>在留言中写道
news：78 ******************* @ newsread2.news.pas.eart hlink.net ...
"xarax" <xa***@email.com> wrote in message
news:78*******************@newsread2.news.pas.eart hlink.net...
以上所有都是特定于实现的，因此OFF
TOPIC。不需要堆或堆栈框架，因为我们知道并喜欢它们。实现被允许做他们想要的任何事情，好像行为看起来符合标准。
对不起但我从标准中收集了由
局部变量仅在执行函数期间有效。
由于函数返回并被调用，这意味着堆栈结构
one方式或其他。这个东西从main（）开始，
可以调用其他函数。
只要程序运行，全局的范围就是无限的。 br />
这意味着C肯定会从本地存储中概念性地假设这个存储是不同的
。
malloc / free是标准。
指向有效内存位置的指针可以来自外部源（例如，由当前正在运行的C程序以外的代理生成），并可由当前正在运行的程序。
是的，我们可以假设操作系统
返回应用程序的有效指针，但这种情况非常罕见，
在显而易见的malloc / free之外。
这是非常罕见的，可以安全地忘记。
你的前提是有缺陷的，因此你的结论毫无意义。
这里没有任何瑕疵。
有很多记忆那些管理工具可以替代malloc（）和
朋友的常见实现，用于查找堆损坏，悬空引用等。
And它们可能与我描述的内容非常相似。
这完全依赖于实现细节，而且需要编译器对
堆有深入的了解。实施。
All of the above is implementation specific and therefore OFF
TOPIC. There is no requirement for a heap or stackframe as we
know and love them. Implementations are allowed to do whatever
they want as if the behavior appears to conform to the standard.
Sorry but I gather from the standard that the storage allocated by
local variables is valid only during the execution of a function.
Since functions return and are called, this implies a stack structure
one way or the other. The thing gets started with main() that
can call other functions.
The scope of a global is indefinite, as long as the program runs.
This means that C surely assumes that this storage is distinct
conceptually from the local storage.
malloc/free are part of the standard.
Pointers to valid memory locations can come from an external
source (e.g., generated by an agent other than the currently
running C program), and be usable by the currently running
C program.
Yes, we could hypothetically assume that the operating system
returns valid pointers to applications but this is very uncommon,
outside the obvious call to malloc/free.
This is very rare and can be safely forgotten.
Your premise is flawed, therefore your conclusions are meaningless.
There is nothing flawed here.
There are plenty of memory management tools out there that are
replacements for the common implementations of malloc() and
friends, for locating heap corruption, dangling references, etc.
And they do probably a very similar thing to what I described.
It is all dependent upon implementation details and is something
that would require a compiler to have intimate knowledge of the
heap implementation.
是的。什么呢？
我的问题是：添加语言本身会有趣吗？
C受到广泛批评，有理由，对于充足的
机会，b $ b指针错误。想到这一点并不是主题。在开发过程中，任何程序中最常见的错误是
一个
。
C的两个概念语言是我们分歧的基础。对你来说，
任何
对该语言的一些基本原则的反思是非主题。我想b / b
关于我们如何改善事情的讨论太少了。
Yes. And so what?
My question is: would it be interesting to add to the language itself?
C has been widely critized, and with reason, for the ample
opportunities of
pointer errors. Giving thought to this is not off topic here. It is
one
of the most common errors in any program when it is being developed.
Two conceptions of the C language underlie our differences. For you,
any
reflection about some basic tenets of the language is "off topic". I
think
too little discussion is going on about how we could improve things.
" jacob navia" < JA *** @ jacob.remcomp.fr>在消息中写道
news：bq ********** @ news-reader4.wanadoo.fr ...
"jacob navia" <ja***@jacob.remcomp.fr> wrote in message
news:bq**********@news-reader4.wanadoo.fr...
xarax ; < xa的*** @ email.com>在消息中写道
新闻：78 ******************* @ newsread2.news.pas.eart hlink.net ...
"xarax" <xa***@email.com> wrote in message
news:78*******************@newsread2.news.pas.eart hlink.net...
以上所有都是特定于实现的，因此OFF
TOPIC。不需要堆或堆栈框架，因为我们知道并喜欢它们。实现被允许做他们想要的任何事情，好像行为似乎符合标准。
抱歉，我从标准中收集到由局部变量分配的存储是仅在执行函数期间有效。
由于函数返回并被调用，这意味着堆栈结构
All of the above is implementation specific and therefore OFF
TOPIC. There is no requirement for a heap or stackframe as we
know and love them. Implementations are allowed to do whatever
they want as if the behavior appears to conform to the standard.
Sorry but I gather from the standard that the storage allocated by
local variables is valid only during the execution of a function.
Since functions return and are called, this implies a stack structure
.... can使用，但不是必须的。
单向或反向。
或者可以使用其他一些非堆栈方法。
这个东西从main（）开始，
可以调用其他函数。
不需要函数调用函数的功能
用栈实现。
只要程序运行，全局范围就是无限期的。
这是肯定的。程序执行的持续时间。
这意味着C肯定会假设这个存储在概念上与本地存储区别不同。
" Local" vs非本地这不是一生的问题，而是范围问题。
但是，本地与全球范围被视为截然不同。
那是''毕竟，范围意味着什么。 :-)
但是并没有要求编译器在内部存储例如所有全局变量和所有本地变量的'b $ b'''。这通常是完成的，
但这是一个实现细节。
malloc / free是标准的一部分。
是的。你的观点是什么？
.... can be used, but not that one is required.
one way or the other.
Or some other non-stack method may be used.
The thing gets started with main() that
can call other functions.
The ability for functions to call functions is not required
to be implemented with a stack.
The scope of a global is indefinite, as long as the program runs.
It is definite. The duration of the program''s execution.
This means that C surely assumes that this storage is distinct
conceptually from the local storage.
"Local" vs "nonlocal" is not a lifetime issue, but one of scope.
But yes, ''local'' vs. ''global'' scopes are considered distinct.
That''s what ''scope'' means, after all. :-)
But there''s no requirement that a compiler internally store e.g
''all globals here and all locals there''. This is often done,
but this is an implementation detail.
malloc/free are part of the standard.
Yes they are. What''s your point?
指向有效内存位置的指针可以来自外部源（例如，由当前正在运行的代理生成） C程序），并且可以被当前运行的C程序使用。
是的，我们可以假设操作系统
返回应用程序的有效指针，但这种情况非常罕见，
Pointers to valid memory locations can come from an external
source (e.g., generated by an agent other than the currently
running C program), and be usable by the currently running
C program.
Yes, we could hypothetically assume that the operating system
returns valid pointers to applications but this is very uncommon,
我觉得很常见。例如。 Microsoft Windows非常广泛。具有接口的嵌入式设备也是如此。
在明显的malloc / free调用之外。
这是非常罕见的，可以是安全地忘记了。
IMO并不罕见。
另外，根据我的经验，罕见的问题是最困难的。 >
来纠正（甚至定位）。
I find it very common. E.g. Microsoft Windows is very
widespread. So are embedded devices with interfaces that
use pointers.
outside the obvious call to malloc/free.
This is very rare and can be safely forgotten.
IMO not rare at all.
Also, in my experience, the ''rare'' problems are the most difficult
to rectify (or even locate).
你的前提是有缺陷的，因此你的结论毫无意义。
这里没有任何瑕疵。
Your premise is flawed, therefore your conclusions are meaningless.
There is nothing flawed here.
有很多内存管理工具可以替代malloc（）和
朋友的常见实现，用于查找堆损坏，悬空引用等等。
There are plenty of memory management tools out there that are
replacements for the common implementations of malloc() and
friends, for locating heap corruption, dangling references, etc.
它们可能与我所描述的非常类似。
And they do probably a very similar thing to what I described.
必须以特定于平台的方式。
In necessarily platform specific ways.
这完全依赖于实现细节，而且需要编译器对
堆实现有深入的了解。
是的。那么呢？
It is all dependent upon implementation details and is something
that would require a compiler to have intimate knowledge of the
heap implementation.
Yes. And so what?
所以在这里，我们讨论标准C，而不是实现细节。
我的问题是：添加它会很有趣吗语言本身？
也许对某些人来说可能是这样，但对其他人来说却不行。
C因为充足的机会而受到广泛的批评，并且有理由
指针错误。
C语言没有必要证明它存在于任何
评论家。我认为它取决于它自己的成功。 AFAIK，
除了COBOL，它是最古老的高级语言，但仍然广泛使用（我欢迎来自历史学家的任何更正）。
想到这个并不是主题。
实际上是。在这里我们讨论C语言。
它是开发过程中任何程序中最常见错误之一。
是的。这就是为什么许多/大多数''评论家''你引用了b $ b b经常试图将他们的工具归咎于他们的错误。
C语言的两个概念构成了我们差异的基础。对你来说，
对语言的一些基本原则的任何反思都是非主题。
关于C的基本原则的解释，作为帮助某人的一部分
与C确实是热门话题。关于
''如何以及为什么'，''可以/应该有所不同'等等的推测/建议不是。
我
我认为关于我们如何改进事情的讨论太少了。
So here, we discuss standard C, not implementation details.
My question is: would it be interesting to add to the language itself?
Perhaps it might be to some, but not to others.
C has been widely critized, and with reason, for the ample
opportunities of
pointer errors.
The C language has no need to justify its existence to any
critics. I think it stands upon its own success. AFAIK,
besides COBOL, it''s the oldest high-level language still in
widespread use (I welcome any corrections from the historians).
Giving thought to this is not off topic here.
Actually it is. Here we discuss the C language as it is.
It is
one
of the most common errors in any program when it is being developed.
Yes it is. Which is why many/most of the ''critics'' you cite
often try to blame their tools for their mistakes.
Two conceptions of the C language underlie our differences. For you,
any
reflection about some basic tenets of the language is "off topic".
Explanations of ''basic tenets'' of C as part of helping someone
with C are indeed topical. Speculations/suggestions about the
''how and why'', ''can/should something be different'', etc. are not.
I
think
too little discussion is going on about how we could improve things.
很多这样的讨论正在发生，你只是显然没有&br / >
意识到这一点。许多此类讨论的结果是C99。
十多年的讨论。太少了？ :-)
我建议你访问comp.std.c如果你想分享想法
关于语言的变化。
-Mike
Much such discussion is occurring, you just apparently aren''t
aware of it. The result of many such discussions was C99.
Ten-plus years of discussion. Too little? :-)
I suggest you visit comp.std.c if you want to share ideas
about changes to the language.
-Mike
这篇关于指针有效性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
