X-Recipient: archive-cygwin@delorie.com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE17F3857705
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cygwin.com;
	s=default; t=1682005289;
	bh=xh6jGzvtcI279EGwzzDKv7RUUkPQRaGGPZHKanomXqg=;
	h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe:
	 List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc:
	 From;
	b=JkU/x8PYsVYx8pBDme+Ju2C+qsLNzhWfQi+SgWz/Uwy3zpfjXEpbMGtZVCoQtLOfL
	 u1cVpQUsjlJFoPcP35M2FdLY1hl/Pa2nKI2UzXNmpsE8wAgSVTb+hmgxHEqSOdI0im
	 IYJoYvMNZc9Uiyj3Ozk8MgOTPgM2BjBtHuZ1BFIY=
X-Original-To: cygwin@cygwin.com
Delivered-To: cygwin@cygwin.com
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 85ECB3858C83
Date: Thu, 20 Apr 2023 17:40:52 +0200
To: Bruno Haible <bruno@clisp.org>
Subject: Re: posix_spawn facility
Message-ID: <ZEFdBAODKA2c61pg@calimero.vinschen.de>
Mail-Followup-To: Bruno Haible <bruno@clisp.org>, cygwin@cygwin.com
References: <1752276.7aRn1RRit1@nimes> <ZEFKW/rbAS8x4QbV@calimero.vinschen.de>
 <ZEFO9ELNzIliSGPv@calimero.vinschen.de> <4892432.0VBMTVartN@nimes>
MIME-Version: 1.0
Content-Disposition: inline
In-Reply-To: <4892432.0VBMTVartN@nimes>
X-BeenThere: cygwin@cygwin.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: General Cygwin discussions and problem reports <cygwin.cygwin.com>
List-Unsubscribe: <https://cygwin.com/mailman/options/cygwin>,
 <mailto:cygwin-request@cygwin.com?subject=unsubscribe>
List-Archive: <https://cygwin.com/pipermail/cygwin/>
List-Post: <mailto:cygwin@cygwin.com>
List-Help: <mailto:cygwin-request@cygwin.com?subject=help>
List-Subscribe: <https://cygwin.com/mailman/listinfo/cygwin>,
 <mailto:cygwin-request@cygwin.com?subject=subscribe>
From: Corinna Vinschen via Cygwin <cygwin@cygwin.com>
Reply-To: cygwin@cygwin.com
Cc: Corinna Vinschen <corinna-cygwin@cygwin.com>, cygwin@cygwin.com
Content-Type: text/plain; charset="utf-8"
Errors-To: cygwin-bounces+archive-cygwin=delorie.com@cygwin.com
Sender: "Cygwin" <cygwin-bounces+archive-cygwin=delorie.com@cygwin.com>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from base64 to 8bit by delorie.com id 33KFfrmm001219

On Apr 20 16:58, Bruno Haible via Cygwin wrote:
> Corinna Vinschen wrote:
> > > Hmm.  Your code uses lpReserved2 for that, but the functionality is
> > > one implemented in MSVCRT.  For obvious reasons, Cygwin executables
> > > are not linked against msvcrt.dll and we're using lpReserved2 for our
> > > own purposes.
> > 
> > Oh, btw., did you know that there's a newer mechanism for defining
> > specific inheritable handles to CreateProcess, which is implemented
> > in kernel32.dll, so it does not depend on MSVCRT?
> > 
> > There's a STARTUPINFOEX structure which allows to specify the 
> > additional handles.  See
> > 
> > https://learn.microsoft.com/en-us/windows/win32/api/winbase/ns-winbase-startupinfoexa
> > 
> > and the PROC_THREAD_ATTRIBUTE_HANDLE_LIST argument described in
> > 
> > https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-updateprocthreadattribute
> 
> Indeed, this appears to be a more "official" way to pass handles for fd ≥ 3,
> instead of lpReserved2 — albeit without associated 'flags'. Not sure how
> O_APPEND is handled then...

Yeah, theoretically, that should be handled by CreateFile opening the
file with FILE_APPEND_DATA attribute, and in the child MSVCRT should
test with NtQueryInformationFile(FILE_ACCESS_INFORMATION) if the
FILE_APPEND_DATA flag is set.

But then again, if MSVCRT implements fcntl (F_SETFL) to allow
manipulating the O_APPEND flag... unfortunately there's no such
operation via Win32 or native calls.  That would require to reopen the
file with different access mask and replace the HANDLE under the hood of
the descriptor.  I'm not aware if and how MSVCRT performs this action.


Corinna

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

