www.digitalmars.com         C & C++   DMDScript  

D - A pointer validation function ?

reply pontus <popi5501 student.uu.se> writes:
SGVsbG8NCg0KSSd2ZSBiZWVuIHBvbmRlcmluZyBvbiB0aGUgdmFsaWRhdGlvbiBvZiBwb2lu
dGVycywgYXMgd2UgYWxsIGhhdmUgZG9uZQ0KaXQgaXMgZWFzeSB0byBmb2xsb3cgYW4gcG9p
bnRlciBvdXRzaWRlIG9mIGFuIGFsbG9jYXRlZCBzZWdtZW50LA0KcmVzdWx0aW5nIGluIGEg
c2VnZmF1bHQuIFNvIEkgdGhvdWdodCwgc2luY2UgdGhlIE9TIGhhdmUgYWxsIHRoaXMgbmlj
ZQ0KaW5mb3JtYXRpb24gYWJvdXQgbWVtb3J5LCBpcyB0aGVyZSBhIHdheSBpdCBjYW4gc2hh
cmUgaXQgd2l0aCB0aGUNCnByb2dyYW1tZXI/IFdoYXQgSSdtIHJlYWxseSBsb29raW5nIGZv
ciBpcyBhIGZ1bmN0aW9uIHRvDQoidmFsaWRhdGUiIHBvaW50ZXJzLCBhIHN5c3RlbWNhbGwg
d2hlcmUgeW91IGFzayB0aGUgT1MgaWYgYSBwb2ludGVyIGlzDQppbiB0aGUgcHJvY2VzcyBh
ZHJlc3Mgc3BhY2UuIGxpa2UgdGhpczoNCg0KY2hhciAqbGV0dGVyczsNCmludCBvZmZzZXQg
PSBbYmlnIGFuZCBuYXN0eSBvZmZzZXQgY2FsY3VsYXRpb25zXTsNCg0KaWYodmFsaWQobGV0
dGVycyArIG9mZnNldCkgPT0gVHJ1ZSkNCnsNCiAgICAgIHByaW50ZigiJXNcbiIsIGxldHRl
cnNbb2Zmc2V0XSk7DQp9ZWxzZXsNCiAgICBwcmludGYoIlRyeWluZyB0byBhZHJlc3MgbGV0
dGVyIG91dHNpZGUgb2Ygc3RyaW5nXG4iKTsNCiAgICBleGl0KDApOw0KfQ0KDQpPZiBjb3Vy
c2UgYW55IHVzZSBvZiBzdWNoIGFuIGFkcmVzcyBpcyBhIGJ1ZyBhbmQgc2hvdWxkIGJlIGNv
cnJlY3RlZCBpbg0KYSByZWxlYXNlLCBidXQgYnVncyBzbGlwIHRocm91Z2guDQoNCkNhbiB0
aGlzIGJlIGRvbmUgd2l0aCB0aGUgYWlkIG9mIG1vc3QgT1MncyB0b2RheSwgb3IgY291bGQg
b25lIHdyYXAgdGhlDQpvcyBpbiBhIG1lbW9yeWhhbmRsZXIgd2hpY2gga25vd3MgdGhlc2Ug
dGhpbmdzLCB0aGUgRCBydW50aW1lIGZvcg0KaW5zdGFuY2UuDQpJZiBpdCBpcyBwb3NzaWJs
ZSBpdCB3b3VsZCByZXBsYWNlIHRoZSBsZXNzIGFjdXJhdGUgdGVzdCAocG9pbnRlcg0KPT0g
TlVMTCkuDQoNCkFsc28gdGhlIGZ1bmN0aW9uIGNvdWxkIHJldHVybiBhIGxvdCBvZiBuaWNl
IGluZm9ybWF0aW9uIGFib3V0IHRoZQ0Kc2VnbWVudCB0aGUgcG9pbnRlciBpcyBpbnNpZGUg
KGlmIGFueSksIGxpa2Ugc2l6ZSBhbmQgYm91bmRhcmllcy4NCg0KL1BvbnR1cw0K
Oct 07 2001
next sibling parent Axel Kittenberger <axel dtone.org> writes:
 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
Oct 07 2001
prev sibling next sibling parent a <a b.c> writes:
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
Oct 07 2001
prev sibling parent reply Russell Borogove <kaleja estarcion.com> writes:
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
Oct 08 2001
next sibling parent Russell Borogove <kaleja estarcion.com> writes:
Excuse my self-followup.

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

...but meant "Dan", not "Axel". Sorry. -RB
Oct 08 2001
prev sibling next sibling parent reply "Walter" <walter digitalmars.com> writes:
"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
Oct 08 2001
parent reply Russell Borogove <kaleja estarcion.com> writes:
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
Oct 08 2001
parent "Walter" <walter digitalmars.com> writes:
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>.
Oct 08 2001
prev sibling parent Pontus Pihlgren <popi5501 student.uu.se> writes:
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

 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
Oct 09 2001