Thread: windows system() call return codes shifted by one byte?

  1. 02-02-2011 #1
    leonv
    leonv is offline
    Registered User
    Join Date
    Dec 2006
    Posts
    15

    Question windows system() call return codes shifted by one byte?

    I am working on a cygwin compiled C program (GCC) that calls robocopy using the system() call function. Everything is working fine, except the return codes from the system call of the robocopy command have me confused.

    Code:
        
    sprintf(robocopyCallStr, "robocopy %s %s %s %s ", soureStr, DestStr,
                      optionsStr, excludeStr);
    returnValue = system(robocopyCallStr);
    if (returnValue.......
    According to robocopy documentation (ROBOCOPY Exit Codes), the return from robocopy is a bitmap with second least significant bit (0x2) being set for extra files. When I test this functionality by forcing an "extra files" condition, it returns 512 - the 10th least significant bit. This appears to be the bitmap shifted left by 8 bits, or one byte.

    The documented return for "some files copied" should be the least significant bit set to 1 (0x1). When I test this functionality by forcing a "some files copied" condition, it returns 256 - the 9th least significant bit. Again, this appears to be the bitmap shifted left by 8 bits, or one byte.

    Testing for "some files copied" and "extra files" returns 768 - the 9th and 10th least significant bits. Again, this appears to be the bitmap shifted left by 8 bits, or one byte.

    While I guess I could just code for the 256, 512, etc., I would really like to understand what is happening to be sure I am not hiding a problem down the road.

    Can anyone please enlighten me on what is happening here?
  2. 02-03-2011 #2
    Salem
    Salem is offline
    and the hat of int overfl Salem's Avatar
    Join Date
    Aug 2001
    Location
    The edge of the known universe
    Posts
    39,659
    Since you're using cygwin (the Unix-like wrapper for windows), you should probably read the manual page.

    Here's what my Linux manual page says
    Quote Originally Posted by the raven
    RETURN VALUE
    The value returned is -1 on error (e.g. fork(2) failed), and the return status of the command otherwise. This latter return status is in the format
    specified in wait(2). Thus, the exit code of the command will be WEXITSTATUS(status). In case /bin/sh could not be executed, the exit status will
    be that of a command that does exit(127).
    The LSB is typically used to return the status of the shell you invoked (or not as the case may be).
    If that is successful, the next byte returns the status of the sub-process.

    In any event, using the WEXIT macros to pick apart the status is the best way forward.
    If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
    If at first you don't succeed, try writing your phone number on the exam paper.
  3. 02-19-2011 #3
    leonv
    leonv is offline
    Registered User
    Join Date
    Dec 2006
    Posts
    15
    Salem - thanks for the help and guidance. I now understand the wexit macros, and all is well!
« Previous Thread | Next Thread »
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Working on a 6502. Could you tell me if this is efficient?
    By Syscal in forum C Programming
    Replies: 15
    Last Post: 08-30-2010, 09:26 AM
  2. Inserting a swf file in a windows application
    By face_master in forum Windows Programming
    Replies: 12
    Last Post: 05-03-2009, 11:29 AM
  3. Script errors - bool unrecognized and struct issues
    By ulillillia in forum Windows Programming
    Replies: 10
    Last Post: 12-18-2006, 04:44 AM
  4. C++ FTP class won't work
    By lord mazdak in forum C++ Programming
    Replies: 8
    Last Post: 12-18-2005, 07:57 AM
  5. oh me oh my hash maps up the wazoo
    By DarkDays in forum C++ Programming
    Replies: 5
    Last Post: 11-30-2001, 12:54 PM