This is the mail archive of the
mailing list for the Cygwin project.
Re: [PATCH 1/1] Cygwin: don't allow getpgrp() to fail
- From: Ken Brown <kbrown at cornell dot edu>
- To: "cygwin-patches at cygwin dot com" <cygwin-patches at cygwin dot com>
- Date: Wed, 24 Jul 2019 15:04:37 +0000
- Subject: Re: [PATCH 1/1] Cygwin: don't allow getpgrp() to fail
- Arc-authentication-results: i=1; mx.microsoft.com 1;spf=pass smtp.mailfrom=cornell.edu;dmarc=pass action=none header.from=cornell.edu;dkim=pass header.d=cornell.edu;arc=none
- Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=8czdgs+9UZtHSvF2LObPdlyMr2jdgE8MLd9LnBX0H9E=; b=N43dO+ypJ5eKhhc8UjP7YKvwbK/9xqORjhWSxlkZnElZeANB5xGtdNjUzudiepQmNOnidqJpwVBGvkaYfPyVN3GoBMg7qhDTBU1Aic1FN/g9rhGoOenPp8BTYjnATwc5D+YzFV4Darn2VXLEHZKKInxc5j5MrLPBZ51xunhUJ4RP+aD2W09MtdD+jPQuMy71EObso789nSd+lY3t/rCB1ujMfPediKuck8h1FLyxKb+kdU9fMFCGexkmG9npLHzlhxJ9VV+B+UM8R1ht2V7rZm5pc1FPF2Ij206mSpI03g9d1cm1CiUEibwI+ngd44uytshomaahEuCobF0lBtrOYQ==
- Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gIa30Zus0sJZVW90iMsWxKF8OFVAb1CYMd1CARCfKIIKcRVUgBx6leG1J/scYE2LuqhHNTC9zavPtZgUG5zapaMAAZgEZovqHhYty282XIXtQaGSxuVlKkKS5ErwGDEEhlT5bIbOmPwG1U7cuj5I4ne7vmKgGpQQ/qDaMA9848JitEcLVK5RbaE+YoXTY8GcBFfh34Y13pJU3PqJi7OnqtFtMChPMWao69IMwT5dif1zO5L1KB6ep9WozxTOk6yWrDDUlRVnn9A3viJEvb93/WTUNuweYyFhTpnoz1aHgkzoUnjncC5X46O52zaxO3Jf1hpthE9J9p8d5UxaohsAhw==
- References: <email@example.com> <firstname.lastname@example.org> <20190723165458.GM21169@calimero.vinschen.de> <email@example.com> <20190723191648.GP21169@calimero.vinschen.de>
On 7/23/2019 3:16 PM, Corinna Vinschen wrote:
> On Jul 23 19:07, Jon Turney wrote:
>> On 23/07/2019 17:54, Corinna Vinschen wrote:
>>> Hi Ken,
>>> On Jul 23 16:12, Ken Brown wrote:
>>>> According to POSIX, "The getpgrp() function shall always be successful
>>>> and no return value is reserved to indicate an error." Cygwin's
>>>> getpgrp() is defined in terms of getpgid(), which is allowed to fail.
>>> But it shouldn't fail for the current process. Why should pinfo::init
>>> fail for myself if it begins like this?
>>> if (myself && n == myself->pid)
>>> procinfo = myself;
>>> destroy = 0;
>>> I fear this patch would only cover up the problem still persisting
>>> under the hood.
>> I agree.
>> There is presumably a class of programs which require getpgrp() to return
>> the correct value for correct operation, which cannot be 0 (since that
>> cannot be a pid).
> However, did we ever see this problem outside of GDB?
I think I've found the problem, as I just reported on the main cygwin list. And
I agree that my patch was misguided.
But I still think getpgrp() should be changed, perhaps by having it just return
myself->pgid as you suggested earlier. There's no point in having getpgrp()
call getpgid(), which does error checking, when POSIX specifically says "no
return value [of getpgrp()] is reserved to indicate an error". POSIX-compatible
applications should call getpgid(0) instead of getpgrp() if they want to do
I'll send a couple of patches, one for this issue and one for the tcsetpgrp()
problem, so that we can discuss it further.