[email protected] wrote:
>
> Well, yes, they can. If they are used. I know, when using HLASM,
> such is the responsibility of the programmer. I wonder if the C
> compiler emits such instructions before dereferencing a pointer.
> That was what prompted my thought - C pointer dereferencing of
> a NULL pointer. I wonder which would have more overhead: consistent
> use of the compare and trap (or compare plus branch, 2 instructions,
> or compare-and-branch instruction on the z196) or a hardware during
> execution test for a non-GPR0 base register containing a NULL
> pointer. Not that I'm likely to ever work for a company with
> current hardware again.
>
The C compiler (typically) does not issue such instructions.
The NULL pointer is 'special', in that it is definitionally
not a pointer. Thus, technically, it cannot be validly dereferenced.
That is, value of the NULL pointer value may be assigned to
any pointer; indicating that the pointer is invalid. The NULL
pointer value definitionally does not point to anything.
The actual value of the NULL pointer value is typically 0x0, but
the C standard does not require that.
This definition is critical to understand; as it's the reason
why invoking, say, strlen() and passing the NULL pointer value
results in undefined behavior. The reason is that strlen()
is defined to accept a pointer to a NUL-terminated (note, that
is NUL with one-'L', not NULL with two L's; different idea)
character string. The NULL pointer value is *not* a pointer
to a character string, it is definitionally not a pointer to
anything. Thus, when passing NULL to strlen(), you are outside
the language definition and the runtime is free to do whatever
it wants. Typically, on many platforms, this causes a dereference
of address X'00000000'; which causes some kind of runtime exception.
Note that a dereference of address X'00000000' does not cause
an exception on MVS, because programs frequently want to look
at low-core for various values... so, programs that deference
the NULL pointer value happen to "work" there (for some rather
loose definition of "work"), and not when ported to other environments.
This frequently lulls C developers on MVS into believing the
runtime there checks for dereferencing NULL and does something
"meaningful" with it; or that, for example, strlen(NULL) returns
0... but nope - it's just luck.
I think the problem with an enhancement to check for NULL
dereferences is the question of "what to do?" THat is, when
the dereference is discovered, what is the proper result?
It could be, say, to issue an exception of some kind; which I
suppose invokes ABEND processing and does something "meaningful"
(I suppose the program could catch the ABEND, etc...)
Wouldn't that be just as well handled with a COMPARE + BRANCH-to-error?
And, can you then make the argument that the programmer would know
more about when such a comparison would be prudent, and when
it's better to not waste time on the comparison?
So, then, wouldn't it just be easier to put it in the source
code?
Just some vacation-time thoughts :-)
- Dave Rivers -
--
[email protected] Work: (919) 676-0847
Get your mainframe programming tools at http://www.dignus.com
