Hello

I've been pondering on the validation of pointers, as we all have done
it is easy to follow an pointer outside of an allocated segment,
resulting in a segfault. So I thought, since the OS have all this nice
information about memory, is there a way it can share it with the
programmer? What I'm really looking for is a function to
"validate" pointers, a systemcall where you ask the OS if a pointer is
in the process adress space. like this:

char *letters;
int offset = [big and nasty offset calculations];

if(valid(letters + offset) == True)
{
      printf("%s\n", letters[offset]);
}else{
    printf("Trying to adress letter outside of string\n");
    exit(0);
}

Of course any use of such an adress is a bug and should be corrected in a release, but bugs slip through.

Can this be done with the aid of most OS's today, or could one wrap the
os in a memoryhandler which knows these things, the D runtime for
instance.
If it is possible it would replace the less acurate test (pointer
== NULL).

Also the function could return a lot of nice information about the segment the pointer is inside (if any), like size and boundaries.

/Pontus

> I've been pondering on the validation of pointers, as we all have done it is easy to follow an pointer outside of an allocated segment, resulting in a segfault. So I thought, since the OS have all this nice information about memory, is there a way it can share it with the programmer?

You can easily catch the SEGV signal if you want your application to behave differently than standard. (terminate). Termination on segfault is the default behavior since it make most times simply most sense.

However if you want you can catch a SIGSEGV yourself, and then either do a backtrace yourself (the glibc has an undocumented backtrace() function, at least it's not in the man pages, and there is even one that evaluates symbolic references if you've compiled with debug info), or let it do curious things like sending an email to the admin until the worst behaviour ignore it,

`man sigaction` for further stuff to that...

- Axel

pontus wrote:
> 
> Hello
> 
> I've been pondering on the validation of pointers, as we all have done
> it is easy to follow an pointer outside of an allocated segment,
> resulting in a segfault. So I thought, since the OS have all this nice
> information about memory, is there a way it can share it with the
> programmer? What I'm really looking for is a function to
> "validate" pointers, a systemcall where you ask the OS if a pointer is
> in the process adress space. like this:
> 
> char *letters;
> int offset = [big and nasty offset calculations];
> 
> if(valid(letters + offset) == True)
> {
>       printf("%s\n", letters[offset]);
> }else{
>     printf("Trying to adress letter outside of string\n");
>     exit(0);
> }
> 
> Of course any use of such an adress is a bug and should be corrected in a release, but bugs slip through.

  I guess it might be handy, but I'd be afraid of the laziness it might
encourage.  I've always been of the opinion that using a pointer in a
context that the programmer cannot be certain of it validity is an
error.  Of course this presumes that client code obeys preconditions and
that functions that are supposed to return a pointer have a mechanism to
say it failed to create the pointer (like returning null or throwing).
I guess my biggest beef is that it might be a valid pointer in the sense
that it points to your memory.  It still might be read only memory when
you plan to write.  It may just be a bad pointer who is still in you
address space.
	This routine might let you prevent seg fault, but even if it say the
pointer is safe, it still may be an error.  I don't see it providing any
useful function except maybe for a memory manager.  I'd almost rather
have something to segfault me when I use a bad pointer that is still in
my memory, but alas, I wouldn't trust the compiler to decide what is bad
in many cases.
	For me, I guess GC is the best compromise.  It would be nice to know if
I had the last reference to an object, so I could verify that I don't
have a memory leak.  How unreasonable/dangerous do you think it would be
to had GC store a reference count accurate as of the last sweep for each
object?  I guess the lack of instantaneous accuracy would make it
useless in most cases.

Dan

pontus wrote:
> I've been pondering on the validation of pointers, as we all have done
> it is easy to follow an pointer outside of an allocated segment,
> resulting in a segfault. So I thought, since the OS have all this nice
> information about memory, is there a way it can share it with the
> programmer? What I'm really looking for is a function to
> "validate" pointers, a systemcall where you ask the OS if a pointer is
> in the process adress space. like this:

I agree with Axel's argument that if you can't use a pointer with confidence, you shouldn't use it at all, but there are exceptional cases (like if you're writing a library and don't really trust the library user).

However, for such cases, the Win32 API provides the functions:
IsBadCodePtr()
IsBadStringPtr()
IsBadReadPtr()
IsBadWritePtr()

If your runtime system maps invalid pointer accesses onto C++ exceptions, you can also do something like this:

// reinterpret_cast your pointer to char*, then call this

bool IsPointerValid( char* ptr )
{
    char c;

    try
    {
        c = *ptr;
	return true;	// access succeeded, pointer is valid
    }
    catch
    {
        return false;	// access threw an exception, pointer is invalid
    }
}

Unfortunately, these only tells you if the memory is accessible, not if it was what you really wanted to access.

It's always a good idea to strive to reduce your reliance on
pointers. Personally, I've found that creating a C++ "smart array"
template class which does bounds checks in debug builds can
catch a huge number of bugs, which frequently won't be caught
immediately by the pointer checks above, because the block of
memory one element past the end of any given array is usually
accessible.

-RB

Excuse my self-followup.

Russell Borogove wrote:
> I agree with Axel's argument...

...but meant "Dan", not "Axel". Sorry.

-RB

"Russell Borogove" <kaleja@estarcion.com> wrote in message news:3BC2156A.90728BC7@estarcion.com...
> It's always a good idea to strive to reduce your reliance on
> pointers. Personally, I've found that creating a C++ "smart array"
> template class which does bounds checks in debug builds can
> catch a huge number of bugs, which frequently won't be caught
> immediately by the pointer checks above, because the block of
> memory one element past the end of any given array is usually
> accessible.


One of the ways D improves program reliability is eliminating much of the need for pointers via:

    1) function inout and out parameters
    2) improved arrays
    3) all class objects are by reference

Walter wrote:
> 
> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3BC2156A.90728BC7@estarcion.com...
> > It's always a good idea to strive to reduce your reliance on pointers. [...]
> 
> One of the ways D improves program reliability is eliminating much of the need for pointers via:
> 
>     1) function inout and out parameters
>     2) improved arrays
>     3) all class objects are by reference

Yes. You can of course do this in C++, with pass-by-reference parameters, smart array classes, etc. C++ is more "pro-choice" than D in this matter, complete with the applicability of the "respect the right [to pointer use], reduce the need" slogan. :)

(Please, please, please don't try to take this analogy too far.)

-RB

Russell Borogove wrote in message <3BC242DE.593399BD@estarcion.com>...
>Walter wrote:
>> "Russell Borogove" <kaleja@estarcion.com> wrote in message news:3BC2156A.90728BC7@estarcion.com...
>> > It's always a good idea to strive to reduce your reliance on pointers. [...]
>>
>> One of the ways D improves program reliability is eliminating much of the need for pointers via:
>>
>>     1) function inout and out parameters
>>     2) improved arrays
>>     3) all class objects are by reference
>
>Yes. You can of course do this in C++, with pass-by-reference parameters, smart array classes, etc. C++ is more "pro-choice" than D in this matter, complete with the applicability of the "respect the right [to pointer use], reduce the need" slogan. :)


You can do it all in assembler, too <g>.

Russell Borogove wrote:
> 
> pontus wrote:
> > I've been pondering on the validation of pointers, as we all have done
> > it is easy to follow an pointer outside of an allocated segment,
> > resulting in a segfault. So I thought, since the OS have all this nice
> > information about memory, is there a way it can share it with the
> > programmer? What I'm really looking for is a function to
> > "validate" pointers, a systemcall where you ask the OS if a pointer is
> > in the process adress space. like this:
> 
> I agree with Axel's argument that if you can't use a pointer with confidence, you shouldn't use it at all, but there are exceptional
Russell Borogove wrote:

> bool IsPointerValid( char* ptr )
> {
> .....
> }

I supose that this is what i was looking for really.

> memory one element past the end of any given array is usually accessible.

The bounds checking is the way to go. But I thought it might be intresting to know more (can't think of an exact aplication...) like the actuall size of the segment you allocated.

/Points