Donald Sharp wrote:
>
> This makes no sense to me( I'm not saying your wrong ). I just
> don't fully understand what you are trying to say here...
>
I have been unclear.
> Comments inline....
>
> > In Unix, for example, the null pointer value is all-bits-zero,
> > zero is a successful program exit code, and other values are
> > various sorts of errors. Following this, in C, 0 (cast to
> > pointer type) is a null pointer value, and 0 is an exit code
> > that represents success.
>
> Where does it cast the exit code( in this case a int ) into
> a pointer?
>
Nope. This was intended as another example of the way the C
system handles certain things behind the scenes, to allow
standard-conforming programs to be executed on systems that
do not conform to the Unix assumptions.
> Here's my test program:
>
> int main( void )
> {
> exit( 5 );
> }
>
> in the debugger:
> (gdb) disassemble main
> Dump of assembler code for function main:
> 0x10538 <main>: save %sp, -112, %sp
> 0x1053c <main+4>: mov 5, %o0
> 0x10540 <main+8>: call 0x20634 <exit>
> 0x10544 <main+12>: nop
> 0x10548 <main+16>: ret
> 0x1054c <main+20>: restore
>
> this is the exit program?
> (gdb) disassemble 0x20634
> Dump of assembler code for function exit:
> 0x20634 <exit>: sethi %hi(0x12000), %g1
> 0x20638 <exit+4>: b,a 0x205ec <__DTOR_END__+4>
> 0x2063c <exit+8>: nop
> 0x20640 <exit+12>: sethi %hi(0x15000), %g1
> 0x20644 <exit+16>: b,a 0x205ec <__DTOR_END__+4>
> 0x20648 <exit+20>: nop
> 0x2064c <exit+24>: sethi %hi(0x18000), %g1
> 0x20650 <exit+28>: b,a 0x205ec <__DTOR_END__+4>
> 0x20654 <exit+32>: nop
> 0x20658 <exit+36>: nop
>
Which is how it is implemented there. This is not a completely
portable program, as the meaning of exit(5) is implementation-
defined (so that the implementation is required to pick
a meaning and document it).
On all Unix systems I know of, the exit() function passes a
numeric value straight back to the operating system. On a VMS
system, it can't do that with exit(0).
> >
> > On some platforms, all-bits-zero is a valid pointer, and there
> > is some other invalid pointer. This does not break working
> > code, as the C system simply translates (void *)0 (or whatever)
> > to the appropriate pointer value.
>
> I don't understand this either. Now suppose the null pointer
> on a system is 0x01. How does the c standard distinguish this between a 0
> or a 1 as a return code?
>
As a return code to malloc()? On any conforming implementation,
int *ip;
ip = malloc(10 * sizeof(*ip));
if (ip == 0)...
is a valid way to test if ip received the null pointer from its
call to malloc(). In this case, ip is a pointer variable, and
therefore 0 has to be cast to a pointer value, which in this
case would be 0x01. (Just like, after "int i; double d;...",
"if (i < d)" requires that the value of i be converted to a
double for purposes of comparison.)
There are restrictions. The 0 has to be a constant integer zero,
not a variable set to zero. It is not necessarily all-bits-zero,
and therefore memset() and calloc() don't necessarily produce
null pointers.
What happens is that the C standard says that an invalid pointer
value will compare equal to a constant integral zero, and such
a zero will convert to the canonical invalid pointer value, and
so any implementation has to do whatever it needs to make this
true.
> My missunderstanding centers around the conversion to a pointer.
> Why? This makes no sense, it's a integer, why convert it to
> a pointer?
>
Because 0 is defined that way, basically. It might have been
better if C had started without 0 being used as the null
pointer value, but rather some sort of symbol (like "NULL" or
"nil") that could perhaps be #defined to the proper value.
It would have saved a great deal of confusion down the road.
(The same applies to exit status. There would be much to be
said for just having "EXIT_SUCCESS" and "EXIT_FAILURE" as portable
values to exit with, but by the time C was codified it was too
late.) There's lots of things about C that are the way they
are because things that seemed like good ideas at the time
got used in many megabytes of source code widely distributed
before people realized they weren't very good ideas after all.
--
David H. Thornley Software Engineer
at CES International, Inc.: [EMAIL PROTECTED] or (763)-694-2556
at home: (612)-623-0552 or [EMAIL PROTECTED] or
http://www.visi.com/~thornley/david/
_______________________________________________
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
