dereferencing NULL pointers in AIX 
Author Message
 dereferencing NULL pointers in AIX

I've recenly inherited a rather large program written in C and compiled on
IBM's C compiler on AIX 4.2. After diving into the code and running it
through gdb several times, I've come across a very strange thing. The code
dereferences NULL pointers (to check to see if they've been populated with
data.) The problem is that the program doesn't seg fault! What's going on
here??? Just as a sanity check, I compiled and ran the code on a linux box
and sure enough - seg fault.

Can anyone explain the behavior here? Maybe a little history as to why C
program in AIX behave like this? Does this conform to ANSI C?

Sean Emery



Tue, 13 Nov 2001 03:00:00 GMT  
 dereferencing NULL pointers in AIX

Quote:

> I've recenly inherited a rather large program written in C and compiled on
> IBM's C compiler on AIX 4.2. After diving into the code and running it
> through gdb several times, I've come across a very strange thing. The code
> dereferences NULL pointers (to check to see if they've been populated with
> data.) The problem is that the program doesn't seg fault! What's going on
> here??? Just as a sanity check, I compiled and ran the code on a linux box
> and sure enough - seg fault.

Different machines work different ways when it comes to dereferencing NULL.
The RS/6000 isn't the only machine which works as it does.  Attempting to
execute or write address 0 fails, however.

Quote:
> Can anyone explain the behavior here? Maybe a little history as to why C
> program in AIX behave like this? Does this conform to ANSI C?

Yes, it conforms.  Segmentation violations are an OS thing, not a language
thing.

-- Julie.



Tue, 13 Nov 2001 03:00:00 GMT  
 dereferencing NULL pointers in AIX


t>...

Quote:
> I've recenly inherited a rather large program written in C and compiled
on
> IBM's C compiler on AIX 4.2. After diving into the code and running it
> through gdb several times, I've come across a very strange thing. The
code
> dereferences NULL pointers (to check to see if they've been populated
with
> data.) The problem is that the program doesn't seg fault! What's going on
> here??? Just as a sanity check, I compiled and ran the code on a linux
box
> and sure enough - seg fault.

> Can anyone explain the behavior here? Maybe a little history as to why C
> program in AIX behave like this? Does this conform to ANSI C?

Can't help you with AIX history but can help you with ANSI C. Dereferencing
a NULL pointer is always illegal. Accessing a NULL pointer is not illegal.

If the code does this:

p = NULL;

if(p != NULL)
{
  j = p->zog;

Quote:
}

that's fine.

If the code does this:

p = NULL;

if(*p != 0)
{
  j = p->zog;

Quote:
}

that's not fine.

But since we can't see your source code, we can't tell whether it's
conforming or not. If it's giving seg violations on other platforms,
though, I'd doubt very much whether it was conforming.

Nothing is necessarily wrong with AIX just because it /doesn't/ seg fault,
though - it may be a particularly robust environment. Nothing necessarily
wrong with its compiler either - there's nothing in the ANSI standard, as
far as I know, that would forbid a compiler from putting in extra bits to
cope with undefined behaviour elegantly.

--
Richard Heathfield

The bug stops here.



Tue, 13 Nov 2001 03:00:00 GMT  
 dereferencing NULL pointers in AIX

Quote:

> I've recenly inherited a rather large program written in C and compiled on
> IBM's C compiler on AIX 4.2. After diving into the code and running it
> through gdb several times, I've come across a very strange thing. The code
> dereferences NULL pointers (to check to see if they've been populated with
> data.) The problem is that the program doesn't seg fault! What's going on
> here??? Just as a sanity check, I compiled and ran the code on a linux box
> and sure enough - seg fault.

> Can anyone explain the behavior here? Maybe a little history as to why C
> program in AIX behave like this? Does this conform to ANSI C?

> Sean Emery

Dereferencing a NULL pointer is always wrong as far as the language is
concerned. The runtime environment's handling of such an error is
undefined by the language but may be well-defined on a particular
platform. Personally, I hate systems that permit reading the character
at *(char*)NULL. Here's a story that'll show how bizarre this can get.

Some years ago, I was helping to debug an application running under SCO
UNIX. We discovered data structures containing a rogue string, namely
"(null)" and couldn't figure where it was coming from. The bug was due
to a pointer being NULL and then being passed to printf(). To my
surprise, I found that...

        printf("%s", NULL) ;

...was generating the literal string "(null)". It was (and maybe still
is!) the behaviour of printf that was misleading us.

I don't know if AIX does the same but SCO also arranges for this
assertion to be "true"...

        *(char*)NULL == 0

Which means that...

        strcpy(target, NULL)

...just gives you an "empty" string.

The horrifying nature of this behaviour is that a poorly implemented
application might run perfectly well on some systems but collapse in an
untidy heap on others.

Products such as BoundsChecker and Purify will detect this kind of
problem.

--
Andy Knight

The good thing about banging your head against a brick wall
is that the pain goes away when you stop.



Tue, 13 Nov 2001 03:00:00 GMT  
 dereferencing NULL pointers in AIX

Quote:
>Which means that...

>    strcpy(target, NULL)

>...just gives you an "empty" string.

On my SCO machine this would give a garbage string, not an empty string.

Just to emphasize that the behaviour is *undefined*, and you could get an
empty string, or a garbage string, or a coredump, or something else.

Villy



Tue, 13 Nov 2001 03:00:00 GMT  
 dereferencing NULL pointers in AIX

Quote:

> Can anyone explain the behavior here?

AIX is *WEIRD*! It is "UNIX like", but not UNIX. I've never
enountered this behavior (why would anyone DO THIS?) but
it does not surprise me.

Scott



Tue, 13 Nov 2001 03:00:00 GMT  
 dereferencing NULL pointers in AIX


Quote:
>I've recenly inherited a rather large program written in C and compiled on
>IBM's C compiler on AIX 4.2. After diving into the code and running it
>through gdb several times, I've come across a very strange thing. The code
>dereferences NULL pointers (to check to see if they've been populated with
>data.) The problem is that the program doesn't seg fault! What's going on
>here??? Just as a sanity check, I compiled and ran the code on a linux box
>and sure enough - seg fault.

Yes, I hate this as well. If I remember right they made the first page
of memory readable (but not writable) because of some C compiler (xlc)
optimization issue. I believe that xlc did (does?) generate code that
sometimes fetches a value across a NULL pointer even so it does not use
the value if the pointer turns out to be zero.

--
Jens-Uwe Mager  <pgp-mailto:62CFDB25>



Tue, 13 Nov 2001 03:00:00 GMT  
 dereferencing NULL pointers in AIX


Quote:
>I've recenly inherited a rather large program written in C and compiled on
>IBM's C compiler on AIX 4.2. After diving into the code and running it
>through gdb several times, I've come across a very strange thing. The code
>dereferences NULL pointers (to check to see if they've been populated with
>data.) The problem is that the program doesn't seg fault! What's going on
>here??? Just as a sanity check, I compiled and ran the code on a linux box
>and sure enough - seg fault.

>Can anyone explain the behavior here? Maybe a little history as to why C
>program in AIX behave like this? Does this conform to ANSI C?

The ability to dereference null exists for supporting ancient, legacy UNIX
code---the same reason for also supporting writable string literals.

You may come across old code (hopefully old!) which does stuff like this:

        *strchr(str, '\n') = 0;

Obviously, if the newline is not there, a null pointer is deferenced.  The
program may have intentionally be written that way, with the implicit knowledge
that the zero page is writable and nothing useful is stored there so that it
may be used to eliminate special case checks (analogously to the way sentinel
nil nodes in list and tree structures can be used to eliminate tests for null).
The 0 gets written to the zero page with no ill effects.

An implementation that allows null to be dereferenced conforms to ANSI C.  The
behavior of the program is then undefined, which means that no requirements are
imposed on the implementation as to what should happen. The implementation is
free to ignore the situtation with unpredictable effects, to terminate the
program with a diagnostic message or to supply some documented behavior as a
local extension to the language.

Obviously, a program that depends on the ability to dereference null is
going to have portability problems.



Tue, 13 Nov 2001 03:00:00 GMT  
 dereferencing NULL pointers in AIX

...

Quote:
>I don't know if AIX does the same but SCO also arranges for this
>assertion to be "true"...

>        *(char*)NULL == 0

For the record SCO is a company, not an OS. The have produced various
operating systems that don't all behave the same way in this respect,
indeed the behaviour can be varied even under a single OS. For example
under OS5 COFF binaries can be set with a linker flag to "map out" page
zero of the process address space. A kernel flag determines how ELF
binaries are dealt with (don't set this flag however, it trips up many
system programs).

--
-----------------------------------------


-----------------------------------------



Tue, 13 Nov 2001 03:00:00 GMT  
 dereferencing NULL pointers in AIX
You can 'disable' NULL dereferences by adding -qcheck=null to the IBM
C/C++ compilers.

In fact, the fact that the lowest page of memory is readable is used by
the optimizer, in order to allow a possible dereference of a NULL
pointer to be done before testing if the pointer is NULL.  This speeds
up some loops.
--
Mark Mendell
Visual Age C++ Development
IBM Toronto Lab



Wed, 14 Nov 2001 03:00:00 GMT  
 
 [ 10 post ] 

 Relevant Pages 

1. dereferencing NULL pointers and string functions

2. dereferencing a null pointer

3. dereferencing a null pointer

4. Dereferencing f-pointers, arrays of f-pointers, pointers to f-pointers

5. confused null pointer with null pointer constant

6. dereferencing pointer to a structure containing a pointer to int

7. NULL v null pointer constant

8. Global pointer is null sometimes even when initialized to some non-null value

9. NULL as a null function pointer

10. Null Pointer Assignment and (null)

11. Null pointer cast to far is not null

12. Dereferencing pointer to incomplete type

 

 
Powered by phpBB® Forum Software