HPE GreenLake Administration
- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - HP-UX
- >
- Trapping access to non r/w memory
Operating System - HP-UX
1830898
Members
3460
Online
110017
Solutions
Forums
Categories
Company
Local Language
back
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
back
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Blogs
Information
Community
Resources
Community Language
Language
Forums
Blogs
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2002 07:14 AM
04-30-2002 07:14 AM
Trapping access to non r/w memory
under UX11, I want to check whether a C pointer "points to" a "legal" memory address - i.e. one probably allocated by the application, or at least in the applications memory space. Is there a system API that will tell me this?
Sort of the equivalent to the Win32 api IsBadReadPtr().
Sort of the equivalent to the Win32 api IsBadReadPtr().
2 REPLIES 2
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2002 07:48 AM
04-30-2002 07:48 AM
Re: Trapping access to non r/w memory
In a word, no. About the only illegal address that is easily caught is a reference to a NULL pointer value. In UNIX, system calls usually set errno to EFAULT to indicate an illegal address or in severe cases the process gets a SIGBUS or SIGILL signal. There are some 3rd-party utilities that will help like Rational's Purify but in the UNIX world, bad pointer references are considered to be the sole responsibilty of the programmer. I will concede that sometimes that programmer is the one that wrote the dumb library function that you are trying to use.
In real life, one of the most common errors is not understanding that realloc can sometimes return a new base address rather than expanding the old block of memory in place. If you have pointers which point into the original block of memory those values are no longer valid - though the contents may appear to okay until the original block is reused.
In real life, one of the most common errors is not understanding that realloc can sometimes return a new base address rather than expanding the old block of memory in place. If you have pointers which point into the original block of memory those values are no longer valid - though the contents may appear to okay until the original block is reused.
If it ain't broke, I can fix that.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-30-2002 09:32 AM
04-30-2002 09:32 AM
Re: Trapping access to non r/w memory
The reason I need to do this is that I am being passed "pointers=object references" from an external scripting interface to my C++ code. It is possible for the scripting interface ( due to programmer error) to pass me a bad pointer value. I have various guards in my internal structures, but just dereferencing the pointer to check these guards can cause an exception. Looks like I may have to catch the signal.
The opinions expressed above are the personal opinions of the authors, not of Hewlett Packard Enterprise. By using this site, you accept the Terms of Use and Rules of Participation.
Company
Events and news
Customer resources
© Copyright 2025 Hewlett Packard Enterprise Development LP