33

I am well aware of the ugliness of this question, I'd still like to know if it's possible:

When a program tries to read/write to an invalid pointer (NULL, unallocated block, etc') windows crashes the application with an access violation exception.

The question is, is there a way to check wether this pointer will generate an exception before trying to use it, or else, is there a way to catch this exception?

Peter Cordes
  • 328,167
  • 45
  • 605
  • 847

7 Answers7

20

The best bet if you must use raw pointers is to make sure that it is either a valid pointer or NULL. Then you can check if it is valid by checking if it is equal to NULL.

But to answer your question, you can catch these kinds of things with structured exception handling (SEH).

That being said, SEH is a bad idea.

Brian R. Bondy
  • 339,232
  • 124
  • 596
  • 636
  • in c when l create a pointer like `int *n = (int*)malloc(_SIZE_*sizeof(int));` and the next l check if its NULL print a message saying its NULL but it doesnt print that even when l remove the malloc function and l just put the pointer like `int *n;` it still saying that its not null. Do l have to initialize to NULL before using the malloc function then? – vincent thorpe Feb 01 '20 at 12:49
  • 1
    The blog link broke; I think [this one](https://learn.microsoft.com/en-us/archive/blogs/larryosterman/so-when-is-it-ok-to-use-seh) is the right one, but the date doesn't match the one in the old URL, and I can't find a blog post from said date. I could edit the answer, but I'd like to get a second opinion. – Elusivehawk Jul 07 '21 at 10:16
17

Catching this kind of errors is addressing the symptoms, not the root cause.

The following idioms will work on any platform:

  • initialize all pointers to zero

  • if you cannot guarantee a pointer is valid, check that it is non-0 before indirecting it

  • when deleting objects, set the pointer to 0 after deletion

  • be careful of object ownership issues when passing pointers to other functions

laalto
  • 150,114
  • 66
  • 286
  • 303
14

There are functions IsBadReadPtr and IsBadWritePtr that might do what you want. There is also an article that explains why you shouldn't use them.

avakar
  • 32,009
  • 9
  • 68
  • 103
  • 3
    From MSDN: "Important: This function is obsolete and should not be used. Despite its name, it does not guarantee that the pointer is valid or that the memory pointed to is safe to use." –  Jun 14 '09 at 17:57
  • Hammer, yes, they are marked as obsolete and the article I linked to explains why. What are you trying to achieve, anyway? – avakar Jun 14 '09 at 17:59
  • The original link is dead. Here is the updated link to that blog post: [_IsBadXxxPtr should really be called CrashProgramRandomly_](https://devblogs.microsoft.com/oldnewthing/20060927-07/?p=29563) _by Raymond Chen on September 27th, 2006_. – heap underrun May 20 '22 at 22:38
9

You can certainly test if the pointer is NULL!

if ( ptr == NULL ) {
   // don't use it
}

That is the only portable test you can do. Windows does provide various APIs to test pointers, but as others have pointed out, using them can be problematic.

6

IsBadReadPointer / IsBadWritePointer

RichieHindle
  • 272,464
  • 47
  • 358
  • 399
  • I know that there are IsBadRead/WritePtr, couldn't find Valid versions. However, MSDN says that they are obsolte –  Jun 14 '09 at 17:58
  • 1
    @Hammer: Sorry, I meant "Bad", now fixed. They're considered bad form because they're not threadsafe, but they the closest thing to what the OP is asking for. – RichieHindle Jun 14 '09 at 17:59
3

I think you're looking for something like IsBadReadPtr.

Documentation:

http://msdn.microsoft.com/en-us/library/aa366713(VS.85).aspx

SuPra
  • 8,488
  • 4
  • 37
  • 30
-1

I don't know about Windows, but in *nix you could install a SIGSEGV signal handler to intercept the exception.

PaV
  • 737
  • 4
  • 7
  • On Windows you can code a Structured Exception Handler to catch the exception. – ChrisW Jun 14 '09 at 18:49
  • 1
    Signal handling is not *nix-specific: it's part of the ISO-C standard library – Christoph Jun 14 '09 at 20:12
  • 2
    This doesn't help much: after SIGSEGV handler has finished, program execution returns exactly at the same position where the root cause of the signal originated from. Unless you don't exit inside your signal handler, you will create an endless loop. Therefore in general it's a bad idea to catch SIGSEGV. – lumpidu Jun 17 '15 at 13:43