memset all bits to zero will let float/double to zero?

[Keith Thompson]

True, but do any of the ones you mention not have all-bits-zero -> 0.0?

For the VAX and Cray formats, 0.0 is represented as all-bits-zero
(confirmed just now by experiment). For the IBM mainframe format, I
think that's the case but I can't confirm it.

 

[Dan Pop]

For the VAX and Cray formats, 0.0 is represented as all-bits-zero
(confirmed just now by experiment).

The PDP-11 and VAX cases are still well documented.

For the IBM mainframe format, I
think that's the case but I can't confirm it.

Given the nature of IBM's representation (no "hidden" mantissa bits),
any all zeros mantissa should be a representation of zero, unless
it's a trap representation (I don't remember IBM 360 floating point
actually using any trap representations).

Dan

 

[Dan Pop]

True, but do any of the ones you mention not have all-bits-zero -> 0.0?

The obvious candidate for all-bits-zero != 0.0 is a binary representation
with "hidden" mantissa bit that doesn't use excess-whatever for the
exponent. On such a representation, all-bits-zero would be 1.0 or 0.5,
depending on the position of the "binary point". 0.0 would either not
be exactly representable (no big deal) or use a bit pattern with the
exponent set to its minimum value.

I am not aware of any hardware implementation of such a representation,
but I'm not sure that I haven't seen/used at least one software
implementation like this.

Dan

 

[Dik T. Winter]

>
> For the VAX and Cray formats, 0.0 is represented as all-bits-zero
> (confirmed just now by experiment). For the IBM mainframe format, I
> think that's the case but I can't confirm it.

The only computer I have used that did have 0.0 with not all bits zero
was the CDC Cyber 205. I understand that the f-p format it used is the
same as in some MIL-STD computer.

 

[Tim Prince]

In <[email protected]> (e-mail address removed)

The obvious candidate for all-bits-zero != 0.0 is a binary representation
with "hidden" mantissa bit that doesn't use excess-whatever for the
exponent. On such a representation, all-bits-zero would be 1.0 or 0.5,
depending on the position of the "binary point". 0.0 would either not
be exactly representable (no big deal) or use a bit pattern with the
exponent set to its minimum value.

I am not aware of any hardware implementation of such a representation,
but I'm not sure that I haven't seen/used at least one software
implementation like this.

On a machine with no bias in the exponent, without a hidden mantissa bit,
all-bits-zero is an un-normalized floating point zero. As such machines did
not have gradual underflow, performing arithmetic between such operands and
other operands of magnitude < 0.5 gave truncated results. For example, had
<float.h> been implemented at that time, 0.9*LDBL_EPSILON + <all-bits-zero>
would give 0.0. One of the early C implementations (gcos) was on such a
machine. I over-simplify, since "long double" was not supported as a memory
storage data type, only in register.

 

[Keith Thompson]

Just to add to the confusion, there are really two different questions
here. One, the issue raised by the OP, is whether using memset to
assign all-bits-zero to a floating-point object will result in a value
equal to 0.0. The other is whether assigning the value 0.0 to a
floating-point object will result in the object containing
all-bits-zero.

The possible existence of multiple representations for 0.0 means that
these are not the same question. However, I'd be very surprised if
there were an implementation for which these questions have different
answers. In other words, I'm guessing that if all-bits-zero is a
valid representation of 0.0, it's the default representation of 0.0
(for each floating-point type in each implementation).

 

[Christian Bau]

Just to add to the confusion, there are really two different questions
here. One, the issue raised by the OP, is whether using memset to
assign all-bits-zero to a floating-point object will result in a value
equal to 0.0. The other is whether assigning the value 0.0 to a
floating-point object will result in the object containing
all-bits-zero.

The possible existence of multiple representations for 0.0 means that
these are not the same question. However, I'd be very surprised if
there were an implementation for which these questions have different
answers. In other words, I'm guessing that if all-bits-zero is a
valid representation of 0.0, it's the default representation of 0.0
(for each floating-point type in each implementation).

I have seen one implementation where long double was 12 byte, with two
padding bytes.

 

[E. Robert Tisdale]

E. Robert Tisdale wrote:

... snip ...


Obviously you have secured and exhaustively examined
every std C implementation on any machine whatsoever.

Pretty much.

Sounds like a lot of work.

It is.

Was this funded by NASA,
Yes.

and how did you determine that you checked each and every one?
Where did you put those myriad systems?

I didn't put them anywhere.
I have access to literally thousands of machines.

Maybe we should all write NASA and ask for the report.
The exhaustive listing should be useful.
Being government funded it should be freely available.

I agree.
And, if there was a formal report that I was aware of,
I would provide you with a citation.
But I don't think that there is such a report.
This is just "common knowledge".
At least for someone who is supposed to be
some kind of expert in computer architecture and arithmetic.

I found a copy of your resume:

http://cbfalconer.home.att.net/cbf/cbfres03.txt

It says that you studied Mathematics and Physics at McGill University
but it doesn't mention a degree. Did you graduate from McGill
before going to work for the School of Medicine at Yale University
in 1974. Why did you choose to attend University in Canada
during the war in Vietnam?

I see that you've had your ups-and-downs with Otis Elevator.
What is your status now?
Are you a consultant again?
Or have you retired?

 

[Malcolm]

But, there are no implementations of the C 89 or C99 standard
that use anything but all zero bits to represent NULL or +0.0.

The problem is that the standard allows it. For instance, if an architecture
appeared that trapped whenever an illegal address (including 0) was loaded
into an address register, then obviously NULL would have to be some other
value. If someone invented a fast floating-point unit which relied on zero
not being all bits clear, then similarly an exception would have to be made.

The fact is that C is such a common language that most architectures are
designed with C compilers in mind, and many programs would break if NULL or
0.0 was not all bits zero. It's the problem of programs which are portable
enough for practical purposes, but not strictly compliant.

 

[Severian]

Trolling away again, I see.

WWKKWWWWWWKKWWWWWWKKWWWWWWKKWWKKWWWWKKWWWWKKWWWWWWWWKKWWWWKKWWWWWWWWWW
WWWWWWKKWWWWWWKKWWWWWWKKWWWWWWWWWWWWWWWWWWWWWWKKWWWWWWWWWWWWWWKKWWKKWW
WWKKWWWWKKWWWWWWWWKKWWWWWWWW.. WWWW WWWWWWKKWWKKWWKKWWWWWWWWWW
WWWWWWWWWWWWKKWWWWWWWWWW WWWWWWWWWWWWWWKKWWWWKK
WWKKWWKKWWWWWWWWKKWWWW WWWWKKWWKKWWWWWWWWWW
WWWWWWWWWWKKWWWWWW WWWWWWWWWWKKWWKKWW
WWKKWWKKWWWWKKWW WWWWKKWWWWWWWWWW
WWWWWWWWWWWWWW.. ,,::::.. WWWWWWWWKKWWWW
WWKKWWWWKKWWWW ,,iittttii,,::.. WWWWKKWWWWWWKK
WWWWWWWWWWKK ,,;;;;iittii;;,,,,,,:: ..,, WWWWKKWWWWWW
WWKKWWKKWWWW .. ::;;;;,,;;,,,,,,,,::.. :::: WWWWWWWWKKWW
WWWWWWWWWWWW ,,;;,,,,,,,,,,,,,,:: ,,.. ..KKWWWWWWWW
WWKKWWKKWW ..,,;;;;,,,,,,,,,,,,::.. ..,,,, ..WWKKWWKKWW
WWWWWWWWWW ::;;;;ii;;,,,,::,,::::::.. ::::;; WWWWWWWWWW
WWKKWWWWWW ..iiiiii;;,,,,,,::,,::,,::,,,,;;;;.. WWKKWWKKWW
WWWWWWKK ..;;iiiiii;;;;,,;;,,,,,,;;iiiiii;;.. WWWWWWWWWW
WWKKWWWW ,,;;iiiiii;;;;,,,,,,,,,,;;iiiiiiii.. WWWWKKWWWW
WWWWWWWW ::iiiiiiiiii;;;;;;,,,,,,;;;;;;;;ttii,, WWWWWWKK
WWKKWWKK ..;;;;iittLLGGttttttiiiiiiiittjjttiiiiii.. WWKKWWWW
WWWWWWWW ..;;;;iiffLLDDEEEEDDffttLLEEKKKKEELLfftt::.. WWWWWWWW
WWKKWWWW ..;;iittjjffffDDEEGGjjiiDDKKDDGGDDDDffjj;; WWKKWWWW
WWWWWWKKWW ..::;;;;iijjGGEEEEEEGGjj;;LLEEEEEEEEEELLjjii:: WWWWWWKK
WWKKWWWWWW ..,,;;;;iittiitttttttttt;;ffGGffffLLtt,,tttt:: WWWWKKWWWW
WWWWWWKKWWWW,,,,;;;;;;iiiiiiiiiitttt,,;;LLtttttt,,;;ttLL,,WWKKWWWWWWWW
WWKKWWWWWWKKii,,;;ii;;;;,,;;,,iiii;;;;,,jjjjii;;;;;;ttGG::WWWWWWWWKKWW
WWWWWWKKWWWWttiiiiii;;;;;;;;ttLLffttjjLLGGDDffiiiittttLL WWKKWWWWWWWW
WWKKWWWWWWWWiiii;;;;;;ii;;ttGGLLEEEEEEKKKKDDLLjjffffffff..WWWWWWKKWWWW
WWWWWWKKWWWWjjtt;;iiiiiittLLGGffLLLLDDEEDDDDGGLLffLLGGGG;;WWKKWWWWKKWW
WWKKWWWWKKWW;;iiiiiiiiiiffDDDDLLLLLLGGGGDDEEEEGGffGGGGGGttWWWWWWWWWWWW
WWWWWWWWWWWW,,iiiiiittttffDDEEDDEEEEGGEEKKKKEEffLLDDDDDDffKKWWKKWWKKWW
WWKKWWKKWW,,,,iittiiiittffGGttttttffLLGGGGGGLLjjLLDDEEEEttWWWWWWWWWWWW
WWWWWWWWiiiiiijjjjjjttffffffjjttjjGGGGGGLLGGLLGGDDDDEEEE;;WWWWKKWWKKWW
WWKKWWfftt;;LLjjffLLffffLLLLjjiittttjjLLffLLDDEEEEEEEEff;;iiWWWWWWWWWW
WWWWWW;;..ttEEttffLLGGGGLLLLffjjttttjjffLLDDEEKKKKKKKKLL,,ttttWWKKWWWW
WWWW::..,,ffEEffjjLLLLLLGGDDGGLLffLLLLLLDDEEKKKKKKEEKKDD,,::;;;;WWWWii
::....;;ffLLEEDDttffLLGGLLLLGGEEEEEEEEKKKKKKKKEEKKEEEEEEii;;..,,,,;;tt
.....::jjGGGGDDEEffjjffLLLLffffffGGEEEEEEEEEEKKEEKKEEKKEEfftt;;::..::tt
...::;;jjDDDDGGEEGGiijjffGGffLLLLLLGGGGDDEEKKEEKKEEKKKKDDLLjjtt;;::::..
,,,,iiiiEEDDDDDDDDttttffLLLLLLGGLLGGDDEEEEEEKKEEDDKKEEDDffjjLLGGtt,,..
,,;;ttffDDEEDDDDEELLttjjLLLLLLGGLLDDEEEEEEEEEEDDDDKKDDLLffGGEEEEtt,,::
,,;;iiGGGGEEKKEEEEDDjjttffffLLLLDDGGDDDDEEGGDDDDEEGGLLjjDDEEKKLLii,,,,
;;iiiiLLEEDDEEEEDDDDffffffjjffLLGGGGDDGGLLGGGGDDLLGGLLEEEEKKGGjjii;;;;
iiiittttLLEEEEEEKKKKjjttffffjjffffffjjffffLLDD;;GGKKKKKKEEDDffttii;;;;
iiiiiittffLLGGDDEEKKDDffffffjjjjttttiittffjjiittKKKKEEEEGGLLttiiii;;;;
iiiittiiffffjjffjjLLDDEEDDLLttjjjjjjttjjttffKKKKDDGGGGLLLLttttiiii;;;;
iiiiiittttjjffjjffffffLLDDEEEELLffffjjttDDKKKKDDGGGGffffffttiiii;;;;ii
iiiiiittttttjjjjjjjjffffffLLLLGGDDffffEEEEDDGGGGLLLLffjjttiiii;;iiiiii

 

[Keith Thompson]

The problem is that the standard allows it. For instance, if an architecture
appeared that trapped whenever an illegal address (including 0) was loaded
into an address register, then obviously NULL would have to be some other
value.

[...]

Maybe not. I think the only operation for which it matters is
equality comparison. If the compiler doesn't load a pointer value
into an address register for a pointer comparison, it might still be
able to use all-bits-zero for null pointers.

 

[Richard Tobin]

Maybe not. I think the only operation for which it matters is
equality comparison. If the compiler doesn't load a pointer value
into an address register for a pointer comparison, it might still be
able to use all-bits-zero for null pointers.

Surely it would have to ensure that it never loaded a pointer that
might be null into a register? Even, say, when assigning a
possibly-null pointer to a variable, or passing it to a procedure.
This would be possible on architectures with memory-to-memory move
instructions and which passed all arguments on the stack, but probably
inefficient.

-- Richard

 

[Keith Thompson]

Surely it would have to ensure that it never loaded a pointer that
might be null into a register? Even, say, when assigning a
possibly-null pointer to a variable, or passing it to a procedure.
This would be possible on architectures with memory-to-memory move
instructions and which passed all arguments on the stack, but probably
inefficient.

Assignment and argument passing are also an issue of course; thanks
for reminding me.

Note that we're talking specifically about address registers; data
registers might be separate. (The 68k has separate data and address
registers, though it doesn't do the trap-on-loading-NULL thing.)

For equality comparison, assignment, or argument passing, it doesn't
matter whether a value is an address or an integer of equal size
(assuming there aren't multiple representations for the same address),
so those operations could be done using data registers. Relational
operators ("<", "<=", ">", ">=") might or might not require an address
register; applying such an operator to NULL invokes undefined behavior
anyway. The only time you really need to use an address register is
if you're going to dereference the pointer; in that case, trapping on
NULL is a good thing.

 

[xarax]

Assignment and argument passing are also an issue of course; thanks
for reminding me.

Note that we're talking specifically about address registers; data
registers might be separate. (The 68k has separate data and address
registers, though it doesn't do the trap-on-loading-NULL thing.)

For equality comparison, assignment, or argument passing, it doesn't
matter whether a value is an address or an integer of equal size
(assuming there aren't multiple representations for the same address),
so those operations could be done using data registers. Relational
operators ("<", "<=", ">", ">=") might or might not require an address
register; applying such an operator to NULL invokes undefined behavior
anyway. The only time you really need to use an address register is
if you're going to dereference the pointer; in that case, trapping on
NULL is a good thing.

The IBM z/Architecture mainframe is 64-bit addresses. General
purpose registers are used for holding addresses. There is no
trap-on-bad-address-loaded-into-register thing. Location zero
is a valid address, and location 0x80000000 is never valid for
virtual addresses when running the z/OS operating system. Attempting
to dereference 0x80000000 will cause a hardware exception trap.

Therefore, a conforming compiler can translate NULL in the
source code into 0x80000000 for the run-time object code,
and then translate 0x80000000 at run-time to mean NULL. I do
not know of any conforming compilers that do this for z/Arch;
they all use zero for both NULL and the run-time bitwise
representation of NULL, and they expect the programmer to know
what he is doing.


--
----------------------------
Jeffrey D. Smith
Farsight Systems Corporation
24 BURLINGTON DRIVE
LONGMONT, CO 80501-6906
http://www.farsight-systems.com
z/Debug debugs your Systems/C programs running on IBM z/OS for FREE!

 

[Dan Pop]

I have seen one implementation where long double was 12 byte, with two
padding bytes.

That's quite common nowadays on x86 compilers, due to alignment issues.
E.g. gcc and the Intel C compiler on x86. The other common option for
x86 implementations is 8 bytes (the same as double).

Dan

 

[Dan Pop]

The problem is that the standard allows it. For instance, if an architecture
appeared that trapped whenever an illegal address (including 0) was loaded
into an address register, then obviously NULL would have to be some other
value.

[...]

Maybe not. I think the only operation for which it matters is
equality comparison. If the compiler doesn't load a pointer value
into an address register for a pointer comparison, it might still be
able to use all-bits-zero for null pointers.

OTOH, if the CPU has dedicated address registers, it may be that ALL
pointer operations are more efficient if using address registers.

Think about a CPU with 32-bit data registers and 48-bit address registers.

Dan

 

[Keith Thompson]

But, there are no implementations of the C 89 or C99 standard
that use anything but all zero bits to represent NULL or +0.0.

The problem is that the standard allows it. For instance, if an
architecture appeared that trapped whenever an illegal address
(including 0) was loaded into an address register, then obviously
NULL would have to be some other value.

[...]

Maybe not. I think the only operation for which it matters is
equality comparison. If the compiler doesn't load a pointer value
into an address register for a pointer comparison, it might still be
able to use all-bits-zero for null pointers.

OTOH, if the CPU has dedicated address registers, it may be that ALL
pointer operations are more efficient if using address registers.

Think about a CPU with 32-bit data registers and 48-bit address registers.

On any CPU, the code generated by a C compiler has to be able to do
assignments and equality comparisons on pointer values, including null
pointer values. If loading a null pointer into an address register
causes a trap, the C implementation won't be able to use the address
registers for pointer assignment and equality comparison (unless it
can recover in the trap handler, but that's likely to be inefficient).

If it's possible to perform these operations efficiently without using
the address registers, that's great; a C compiler will be able to use
all-bit-zero as the null pointer value, and everything will work. If
it isn't, either the C compiler will be forced to use a different
value for null pointers, or it won't be possible to implement C
efficiently. The same will probably be true for languages other than
C, which probably means that no such CPU will be designed for
general-purpose computers.

 

[Dan Pop]

But, there are no implementations of the C 89 or C99 standard
that use anything but all zero bits to represent NULL or +0.0.

The problem is that the standard allows it. For instance, if an
architecture appeared that trapped whenever an illegal address
(including 0) was loaded into an address register, then obviously
NULL would have to be some other value.
[...]

Maybe not. I think the only operation for which it matters is
equality comparison. If the compiler doesn't load a pointer value
into an address register for a pointer comparison, it might still be
able to use all-bits-zero for null pointers.

OTOH, if the CPU has dedicated address registers, it may be that ALL
pointer operations are more efficient if using address registers.

Think about a CPU with 32-bit data registers and 48-bit address registers.

On any CPU, the code generated by a C compiler has to be able to do
assignments and equality comparisons on pointer values, including null
pointer values. If loading a null pointer into an address register
causes a trap, the C implementation won't be able to use the address
registers for pointer assignment and equality comparison (unless it
can recover in the trap handler, but that's likely to be inefficient).

But there is nothing preventing the implementor to use a null pointer
representation that doesn't trap! Even if that representation is not
all bits zero.

If it's possible to perform these operations efficiently without using
the address registers, that's great;

Even then, why bother? If address registers exist in the first place,
there *must* be a reason. Not using them for pointer operation is very
likely to be inefficient, even if they have the same size as data
registers for the simple reason that data registers get under greater
pressure, while the address registers are unused. When the sizes are
different, as in my example, the difference is going to be even more
important.

a C compiler will be able to use
all-bit-zero as the null pointer value, and everything will work.

You make it sound as if there is any merit in having null pointers
represented as all bits zero. Why would the implementor try to use
that representation, if it's causing even the slightest inconvenience?

If it isn't, either the C compiler will be forced to use a different
value for null pointers,

The representation of null pointers is supposed to be the most convenient
and efficient for the implementation, so there is no reason to consider
all bits zero as an a priori solution, unless it is a convenient choice.

or it won't be possible to implement C efficiently.

Only an idiot would create an inefficient implementation for the sake of
having null pointers represented as all bits zero. See below.

The same will probably be true for languages other than
C, which probably means that no such CPU will be designed for
general-purpose computers.

Sheer nonsense. There is always an efficient solution: create a
"reserved" object at some address and use its address as the null pointer
representation. This is what most implementations are doing anyway, using
the address 0 for this purpose. But there is nothing magic about this
address, it just happens to be very convenient for this particular
purpose, on most architectures.

Since most modern machines treat addresses as unsigned integers,
address 0 happens to be at the beginning of the address space and it's
traditionally reserved anyway, on non-virtual memory architectures:
it's the address of a GPR or an interrupt vector or the entry point in
the boot loader (possibly ROM space). On virtual memory architectures,
it's simply a matter of either leaving page zero unmapped (best choice,
IMHO) or mapping but not using it (in read only mode, preferably).

Dan

 

[Keith Thompson]

This is generating a lot more discussion than it deserves.

Malcolm speculated upthread that on a hypothetical CPU that traps on
an attempt to load an illegal address, including all-bits-zero, into
an address register, a C implementation would have to use a
non-all-bits-zero value for the null pointer. I replied that, given a
couple of additional assumptions about the architecture, it still
could, and arguably should, use all-bits-zero for the null pointer.

More concretely, assume something similar to the 68k, with its
separate data and address registers, all the same size (32 bits, or
whatever). Assume that, unlike the 68k, loading any invalid address,
including all-bits-zero, into an address register causes a trap, and
that handling a trap is relatively expensive. Finally, assume that an
address is effectively an unsigned integer representing an index into
the (32-bit?) address space. On such an architecture, a C
implementation could reasonably use all-bits-zero as the null pointer
representation. Pointer assignment and equality comparison would use
the data registers, not the address registers, so they'll work
properly with null pointer values. Deferencing a pointer requires
loading its value into an address register, causing a trap if it's
invalid -- which is exactly what we want. Pointer arithmetic probably
uses the data registers as well, but if some operations are easier
using the address registers, the trap on a null pointer is again
exactly what we want. (It's undefined behavior, but I'd rather see it
blow up immediately than fail silently and cause further havoc later
on.)

[...]

But there is nothing preventing the implementor to use a null pointer
representation that doesn't trap! Even if that representation is not
all bits zero.

On the hypothetical CPU I describe above, there is nothing preventing
the implementor to use a null pointer that *does* trap.

Even then, why bother? If address registers exist in the first place,
there *must* be a reason. Not using them for pointer operation is very
likely to be inefficient, even if they have the same size as data
registers for the simple reason that data registers get under greater
pressure, while the address registers are unused. When the sizes are
different, as in my example, the difference is going to be even more
important.

If using a value other than all-bits-zero for null pointers makes it
possible to generate more efficient code, then by all means do so. I
suggested that using all-bits-zero for null pointers is possible; I
never suggested doing so if it's less efficient.

You make it sound as if there is any merit in having null pointers
represented as all bits zero. Why would the implementor try to use
that representation, if it's causing even the slightest inconvenience?

I said it's possible to use all-bits-zero as the null pointer, not
that there's any great merit in doing so. Now that I think about it,
though, there is some merit in not breaking badly written code that
assumes the null pointer is all-bits-zero. There is also some merit
in breaking such code so it can be corrected. But the vast majority
of C implementors, for whatever reason, have chosen to use
all-bits-zero as the null pointer, and they're likely to continue to
do so if there's no significant cost.

[...]

Sheer nonsense. There is always an efficient solution: create a
"reserved" object at some address and use its address as the null pointer
representation. This is what most implementations are doing anyway, using
the address 0 for this purpose. But there is nothing magic about this
address, it just happens to be very convenient for this particular
purpose, on most architectures.

And if an attempt to dereference this address causes a trap, that's an
advantage, not a disadvantage. If you're not going to deference it,
don't load it into an address register.

 

[Richard Bos]

This is generating a lot more discussion than it deserves.

Malcolm speculated upthread that on a hypothetical CPU that traps on
an attempt to load an illegal address, including all-bits-zero, into
an address register, a C implementation would have to use a
non-all-bits-zero value for the null pointer. I replied that, given a
couple of additional assumptions about the architecture, it still
could, and arguably should, use all-bits-zero for the null pointer.

I've seen you state that it could (and I agree), but I haven't seen you
arguing that it should. And IMO you'd need some pretty good arguments,
because sacrificing speed and safety just to cater for sloppy
programmers is rarely a good idea, IYAM.

Assume that, unlike the 68k, loading any invalid address,
including all-bits-zero, into an address register causes a trap, and
that handling a trap is relatively expensive.

On such an architecture, a C
implementation could reasonably use all-bits-zero as the null pointer
representation. Pointer assignment and equality comparison would use
the data registers, not the address registers, so they'll work
properly with null pointer values.

So does passing pointers to functions. Not nice, IMO.

I said it's possible to use all-bits-zero as the null pointer, not
that there's any great merit in doing so. Now that I think about it,
though, there is some merit in not breaking badly written code that
assumes the null pointer is all-bits-zero.

IMAO, there is no merit in it at all. Such code is broken, and always
will be broken. It is better to correct its programmers than to
discorrect the compiler.

Richard