This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: negative error status: gcc vs. cl


On Thu, Jul 08, 2004 at 11:23:41AM -0400, Igor Pechtchanski wrote:
>On Thu, 8 Jul 2004, Christopher Faylor wrote:
>
>> On Thu, Jul 08, 2004 at 10:25:09AM -0400, Igor Pechtchanski wrote:
>> >On Thu, 8 Jul 2004, Corinna Vinschen wrote:
>> >
>> >> On Jul  8 11:49, Daniel Lungu wrote:
>> >> > Feel like bash tcsh on Cygwin mess up with negative exit status
>> >> > from a cl compiled .exe
>              ^^^^^^^^^^^^^^^^
>> >> The answer is "don't do that".  Use positive values in the range from
>> >> 0 to 255.  See
>> >> http://www.opengroup.org/onlinepubs/009695399/functions/exit.html
>> >
>> >Actually, it looks like another buglet in Cygwin.  The code in
>> >spawn_guts() in spawn.cc (line 847 in CVS HEAD) simply binary-ORs the
>> >exitcode value returned by GetExitCodeProcess with the "res" variable.
>> >However, the "res" variable is also used to carry some flags, and a
>> >negative exitcode, being a full DWORD, accidentally sets those, so all
>> >sorts of havoc can potentially occur (and I'm surprised that all that
>> >happens is the wrong exit code).
>>
>> This is not a bug.  A cygwin program can't set a negative exit code.
>> Only the lower order 16 bits are used.  This is enforced by _exit.
>>
>> If someone uses ExitProcess in a cygwin program, then well, err...
>> cgf
>
>You would be right if spawn() could only be used for Cygwin programs.

It's not spawn*().  It's exec*().  spawn would be unaffected.

The effect of a windows program setting a higher order bit would most
likely be an eventual system_printf warning from cygwin.

>Unfortunately, it can also be used for non-Cygwin programs (as shown by
>the underlined phrase above) which don't operate under the above
>restriction.  So, I'd say that binary-ANDing the exitcode value with 0xFF
>(or 0xFFFF if you want 16 bits) is a healthy precaution.  It will
>certainly do no harm, and it will make absolutely sure that the other
>flags (e.g., EXIT_REPARENTING) are never tread upon.

I wouldn't make a change like that without inspecting the impact of
how this affects EXIT_SIGNAL.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]