The Weird and The Wonderful

Nemanja Trifunovic wrote:

There is no such thing as a "NULL pointer exception" - there is "access violation"

Nemanja Trifunovic wrote:

if you follow your rules you may still very easily run into it

Randor wrote:

Come on man I know your not really that pedantic about verbiage. Call it whatever you want, "Access Violation" is simply an error title. Now your just trying to be argumentative. I'll call it segmentation fault[^] from now on just to get under your skin.

Randor wrote:

There are many techniques to making software more robust. Assigning pointers to NULL and checking for NULL is only one of them

Randor wrote:

Initializing a pointer to NULL to denote an invalid memory address is the same magic number technique. It assists the programmer with validating pointers and most certainly assists with making software more robust.

void my_function(MyType* object)
{
delete object;
object = NULL; // of course, this makes no sense either...
}


int main()
{
MyType* object = new MyType;
my_function(object);

// here, object is bad, but not NULL

if (object) // NULL check is worthless
  object->do_something(); // BOOOOM!!!
}

PIEBALDconsult wrote:

Protect against what you can anyway.

PIEBALDconsult wrote:

Because I can,

PIEBALDconsult wrote:

and a null pointer is generally more likely than an invalid pointer

PIEBALDconsult wrote:

Again I'll invoke the similarity to a condom

PIEBALDconsult wrote:

If I write a method that takes several pointers, I can check each one and tell the caller exactly which parameter(s) were null, rather than simply blowing up and making the post-mortem team guess what happened.

Nemanja Trifunovic wrote:

NULL only if you explicitly set it to NULL - an unitialized pointer is not going to be NULL

PIEBALDconsult wrote:

If you don't assign NULL to pointer variables when freed then you're on your own.

PIEBALDconsult wrote:

C99 and C# initialize pointers (references) to NULL

Dave Kreskowiak wrote:

what's the default for a newly created, but uninitialized pointer??

PIEBALDconsult wrote:

But I expect that if it isn't NULL already it soon will be.

Nemanja Trifunovic wrote:

why checking for 0 only?

ASSERT(0 == ((DWORD_PTR)pAddress & 3));

PDWORD pAddress = (PDWORD)&SomeFunction;
DWORD_PTR pInstructions = *pAddress;

MEMORY_BASIC_INFORMATION mbi;
if(VirtualQueryEx(GetCurrentProcess(),(LPVOID)pInstructions,&mbi,sizeof(MEMORY_BASIC_INFORMATION)))
{
	if(mbi.Protect & PAGE_EXECUTE_READ &&
		mbi.State & MEM_COMMIT &&
		mbi.AllocationProtect & PAGE_EXECUTE_WRITECOPY &&
		mbi.Type & MEM_IMAGE)
	{
		(*this.*SomeFunction)(val);
	}
}

Nemanja Trifunovic wrote:

I think I already demonstrated

PIEBALDconsult wrote:

But in that example you didn't set the pointer to NULL and you know it.

PIEBALDconsult wrote:

A called method should not free something that was passed in, or if it's expected to, you'll need double indirection.

Find a better example, that one's a coding horror on its own.

{
  int arr[5];
  int *p;
  int i;

  p=arr;
  for (i=0; i<5; i++)
    *p++ = i;
}

PIEBALDconsult wrote:

I think it's more a question of, if you write a function (perhaps a library function) that takes one or more pointers, do you check them for null or let them blow up? And why?

1. Is the operation in the null-pointer situation defined by the interface standard?
   
   
2. Would the null-pointer situation have a logical meaning (e.g. it may be useful for a function that reads data from a stream to have an option to simply throw away some data; allowing the function to take a null pointer for such usage may be more elegant than requiring the use of a separate function)?
   
   
3. Are there any circumstances that could case a null pointer to be passed in accidentally?
   
   
4. How would the probable consequence of passing in a null pointer compare with the best result one could achieve?