|
Home > Archive > Unix Programming > January 2004 > Determining if a pointer refers to an accessible region?
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Determining if a pointer refers to an accessible region?
|
|
| Kelvin Lim 2004-01-23, 5:36 pm |
| Hi,
This is probably a really basic question, so please forgive my ignorance.
Given a (non-null) pointer, is there any easy and reliable way to
determine whether it refers to a memory region that is accessible to the
current program? What I would like to do is to validate my pointers
before attempting to read from their referenced locations, so as to avoid
causing segmentation faults through these accesses.
Any help at all would be most appreciated. Thanks.
kelvin lim
| |
| =?iso-8859-1?q?M=E5ns_Rullg=E5rd?= 2004-01-23, 5:36 pm |
| Kelvin Lim <cklim@andrew.cmu.edu> writes:
quote:
> Hi,
>
> This is probably a really basic question, so please forgive my ignorance.
>
> Given a (non-null) pointer, is there any easy and reliable way to
> determine whether it refers to a memory region that is accessible to the
> current program? What I would like to do is to validate my pointers
> before attempting to read from their referenced locations, so as to avoid
> causing segmentation faults through these accesses.
There is no portable reliable way, and there is no need for one.
Properly written code will never have any invalid pointers anyway.
If a bug does cause one, you'll just get a segmentation fault and a
core dump, which will make it possible to track down the cause. You
should also run the program under a memory debugger, such as valgrind
(on x86 machines), purify (expensive), or electric fence (simpler).
--
Måns Rullgård
mru@kth.se
| |
| Kelvin Lim 2004-01-23, 5:36 pm |
| On Sat, 17 Jan 2004, [iso-8859-1] Måns Rullgård wrote:
quote:
> Kelvin Lim <cklim@andrew.cmu.edu> writes:
>
>
> There is no portable reliable way, and there is no need for one.
> Properly written code will never have any invalid pointers anyway.
Hi Mens,
Thanks for the very prompt response. I certainly appreciate what your
point, but in my case I'm trying to write a debug-library function that
will presumably be used with code that is still in the process of making
it to the "properly written" state.  Thus some means of checking the
validity of pointers will be useful for this purpose.
I don't need the code to be universally portable, though. Something that
works on a typical Unix system will be fine. In fact, even different
suggestions for various specific Unix flavors would probably be useful.
Thanks again.
kelvin lim
| |
| John L 2004-01-23, 5:36 pm |
|
"Kelvin Lim" <cklim@andrew.cmu.edu> wrote in message news:Pine.LNX.4.58-035.0401171524530.7672@unix47.andrew.cmu.edu...quote:
> On Sat, 17 Jan 2004, [iso-8859-1] Måns Rullgård wrote:
>
>
> Hi Mens,
>
> Thanks for the very prompt response. I certainly appreciate what your
> point, but in my case I'm trying to write a debug-library function that
> will presumably be used with code that is still in the process of making
> it to the "properly written" state. Thus some means of checking the
> validity of pointers will be useful for this purpose.
>
> I don't need the code to be universally portable, though. Something that
> works on a typical Unix system will be fine. In fact, even different
> suggestions for various specific Unix flavors would probably be useful.
>
mincore()
John.
| |
| James Antill 2004-01-23, 5:36 pm |
| On Sat, 17 Jan 2004 15:07:48 -0500, Kelvin Lim wrote:
quote:
> Hi,
>
> This is probably a really basic question, so please forgive my ignorance.
>
> Given a (non-null) pointer, is there any easy and reliable way to
> determine whether it refers to a memory region that is accessible to the
> current program? What I would like to do is to validate my pointers
> before attempting to read from their referenced locations, so as to avoid
> causing segmentation faults through these accesses.
>
> Any help at all would be most appreciated. Thanks.
Do you want this for debugging mode only, or as part of some
general application logic? I'm going to guess the former. In which case
the common solution is to use a malloc() etc. wrapper. For the common case
where you want to check that what you have is a pointer that has been
returned by malloc this can be slow but portable to all ISO C.
If you need to be able to check things like is this pointer inside any
region then you need to compare arbitrary pointers, which is still
portable to probably any Unix env. that is in common use.
Almost everyone has done at least one of these, at least once . You can
look at one I did here: http://www.and.org/texts/malloc_debug.html
--
James Antill -- james@and.org
Need an efficient and powerful string library for C?
http://www.and.org/vstr/
| |
| Brian Raiter 2004-01-23, 5:36 pm |
| > I don't need the code to be universally portable, though. Somethingquote:
> that works on a typical Unix system will be fine. In fact, even
> different suggestions for various specific Unix flavors would
> probably be useful.
This little trick works on a number of different Unixes -- it's about
as portable as you're going to get:
#define is_valid_ptr(p) ((access(p) == -1) ? (errno != EFAULT) : 1)
Basically, what's going on is that some Unix kernels have ways to
safely check pointer validity, which are not made (portably) available
to userland programs. On those kernels that do reliably report EFAULT
errors, you can use a system call, like access(), to tap into the
kernel's pointer testing. There are a number of system calls that can
be used equally well here, stat() being an obvious example. access()
is a good choice because it has less overhead and few if any side
effects.
b
| |
| Paul Pluzhnikov 2004-01-23, 5:36 pm |
| blr@drizzle.com (Brian Raiter) writes:
quote:
> This little trick works on a number of different Unixes -- it's about
> as portable as you're going to get:
>
> #define is_valid_ptr(p) ((access(p) == -1) ? (errno != EFAULT) : 1)
Except that this will not compile with any ANSI-C or C++ compiler:
junk.c:8: too few arguments to function `access'
You'll get better portability with
#define is_valid_ptr(p) ((access(p, 0) == -1) ? (errno != EFAULT) : 1)
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Brian Raiter 2004-01-23, 5:36 pm |
| >> This little trick works on a number of different Unixes -- it's aboutquote:
>
> Except that this will not compile with any ANSI-C or C++ compiler:
> junk.c:8: too few arguments to function `access'
Foo! My mistake.
quote:
> You'll get better portability with
> #define is_valid_ptr(p) ((access(p, 0) == -1) ? (errno != EFAULT) : 1)
Thanks for catching that.
b
|
|
|
|
|