Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive:	<http://sourceware.org/ml/cygwin/>
List-Post:	<mailto:cygwin AT cygwin DOT com>
List-Help:	<mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender:	cygwin-owner AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
Delivered-To:	mailing list cygwin AT cygwin DOT com
Date:	Thu, 11 Nov 2004 15:47:14 -0500
From:	Christopher Faylor <cgf-no-personal-reply-please AT cygwin DOT com>
To:	cygwin AT cygwin DOT com
Subject:	Re: howto register process
Message-ID:	<20041111204714.GC17251@trixie.casa.cgf.cx>
Reply-To:	cygwin AT cygwin DOT com
Mail-Followup-To:	cygwin AT cygwin DOT com
References:	<87u0rwury2 DOT fsf AT zlatenlist DOT homelinux DOT net> <NUTMEGuOlvX6D96doCe000006ac AT NUTMEG DOT CAM DOT ARTIMI DOT COM>
Mime-Version:	1.0
In-Reply-To:	<NUTMEGuOlvX6D96doCe000006ac@NUTMEG.CAM.ARTIMI.COM>
User-Agent:	Mutt/1.4.1i

On Thu, Nov 11, 2004 at 08:05:07PM -0000, Dave Korn wrote:
>>kill() prints int STDERR the error message - it is not returned by it.
>
>That strikes me as very very wrong indeed for a library function.  A
>quick scan through signal.cc doesn't seem to show anything in kill,
>kill0, or kill_worker, that would have that effect, though as always
>with C++, an awful lot of the detail can be hidden inside implied
>constructors or overloaded operators.  Are you _quite_ sure you're
>calling cygwin's kill?

The only time that cygwin prints anything to stderr is when there is a
serious problem in the DLL.  In most cases this causes the application
to die.

kill() is certainly not supposed to be printing "no such pid" type of
messages on stderr.

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/

- Raw text -