Re: incorrect return code on vms...

[Donald Sharp]

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...

Comments inline....

On Fri, Dec 01, 2000 at 11:05:46AM -0600, David H. Thornley wrote:
> Donald Sharp wrote:
> > On Fri, Dec 01, 2000 at 09:47:52AM -0600, David H. Thornley wrote:
<snip>
> No, it has to do with what happens between the writing of the
> C program and the status return to the operating system.  That
> is where the C compiler comes in.
> 
> 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?

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 

> 
> 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?

My missunderstanding centers around the conversion to a pointer.
Why?  This makes no sense, it's a integer, why convert it to 
a pointer?

donald
> 
> Similarly, on some platforms, 0 is the failure exit, and the
> C system simply translates appropriately.
> 
> > Original code did this:
> > 
> >         exit( err ? EXIT_FAILURE : 0 );
> > 
> > Within cvs err is set to 0 for program success and >0 for failure.
> > 
> In other words, the program is completely correct here.  That is
> perfectly good code according to the standard.
> 
> > stdlib.h on vms should set EXIT_FAILURE to 0.  Therefore the
> > above exit() code will always return 0 on vms.  I assumed that EXIT_SUCCESS
> > would be set to the correct thing.  Hence:
> > 
> If stdlib.h on vms sets EXIT_FAILURE to 0, it is not a conforming
> C compiler, and, as I said, you should find a better one or
> gripe to your vendor if you run into this problem.  0 is, by
> definition in the Standard, a successful value.  If the exit()
> function has something like "return !exit_value" in it, it will
> pass the correct value to the operating system.  (This is
> platform-specific code, of course, which the standard libraries
> pretty much have to be.)
> 
> EXIT_SUCCESS may be set to 0, or it may be set to some other
> value the system finds convenient.  However, EXIT_FAILURE
> may not be set to 0.
> 
> >         exit( err ? EXIT_FAILURE : EXIT_SUCCESS );
> > 
> > I #defined EXIT_SUCCESS in system.h ostensibly for old sun boxes
> > see the comment above the EXIT_FAILURE line in system.h.
> > 
> If this is catering for pre-standard compilers, then my only
> problem with it is that people should get standard C compilers
> if they want to compile code on multiple platforms.
> 
> > If vms isn't setting EXIT_FAILURE or EXIT_SUCCESS then we
> > need to fix the #defines in system.h to do the right thing
> > on vms.
> > 
> If <stdlib.h> doesn't set EXIT_FAILURE or EXIT_SUCCESS, the C
> compiler (with libraries) probably has other problems also.
> I just don't see how, in December 2000, I can advise using
> compilers that do not try to conform to an eleven-year-old
> standard.
> 
> > Also we should not be returning 0, we should be using EXIT_SUCCESS
> > in the code in main() in order for the right thing to be done...
> > 
> Returning 0 is the right thing.  So is returning EXIT_SUCCESS.
> Returning anything else would be the wrong thing in a program
> expected to run on several different platforms.  (It could be
> the right thing to do for a platform-specific program, which
> CVS is not.)
> 
> > Having said all that I bet this is a moot point in a lot of respects.
> > Is anyone even using VMS?
> > 
> I heard that DEC has dumped all support for the Vaxen, but that
> VMS still runs on Alphas.  Some people are still using it,
> and are presumably happy with it.
> 
> 
> -- 
> David H. Thornley                          Software Engineer
> at CES International, Inc.:  address@hidden or (763)-694-2556
> at home: (612)-623-0552 or address@hidden or
> http://www.visi.com/~thornley/david/
> 
> _______________________________________________
> Info-cvs mailing list
> address@hidden
> http://mail.gnu.org/mailman/listinfo/info-cvs