J
jacob navia
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
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