From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-Status: No, score=-4.1 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id A10231F66E for ; Tue, 1 Sep 2020 01:11:48 +0000 (UTC) Received: from localhost ([::1]:49948 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kCupu-0000sd-TF for normalperson@yhbt.net; Mon, 31 Aug 2020 21:11:46 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35818) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCupo-0000sR-2u for bug-gnulib@gnu.org; Mon, 31 Aug 2020 21:11:40 -0400 Received: from atfriesa01.ssi-schaefer.com ([193.186.16.100]:21527) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kCupk-0002I8-J3 for bug-gnulib@gnu.org; Mon, 31 Aug 2020 21:11:38 -0400 IronPort-SDR: 4qtCq1l3mxAS/l/KTsPg+4x8maHh0dlPnKnvjwT9edFD4+N8gej6KKOp6eNx6uoPmG9RtYSHxa wmvCxiGQKh5fzegB2h7isewHHaXRjy9a42LiqPl9DmSElp5CrAMcK2Y4FqCykZQqeuusYGge5h ns5FlAdWb6CpVnSS/SxWGz7yfau4QE5OuyMzsSz7UR75uklXjJff14gQ7xdiQ+ma+Gvygb1Yc9 PSrxddep8nmZleHbzx8Rily0xfDINwNikFOFlgSzbJxY2BcH6dX1VCDXL50MVU9L98u0OMSDcS XEU= X-IronPort-AV: E=Sophos;i="5.76,376,1592863200"; d="scan'208";a="65959587" X-IPAS-Result: =?us-ascii?q?A2FKagBzn01f/+shHKxgHAEBATwBAQQEAQECAQEHAQEVg?= =?us-ascii?q?UEGAQEDAYE7AgGBWYVrkT2aIBOBLD0LAQEBAQEBAQEBCB8QBAEBAoRKAoJMJ?= =?us-ascii?q?ToEDQIDAQELAQEBBQEBAQEBBgMBAgKGRQyCcmKBAwEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBEgINVGkBBAEjVgULCxoCGQ0CAlc0gwyCXLBmgTKFVINmgTwGg?= =?us-ascii?q?Q4oAgEBAY0xgU0/gyN+PoJcAoEqARIBboJKgmAEj3WLS5sAKgeCaIELBAuHT?= =?us-ascii?q?pFroFYtmw2BIUSVMYFuCX9wTSODOk8ZDY4rF4NOiliBKQIGCgEBAwmQcgEB?= Received: from samail03.wamas.com (HELO mailhost.salomon.at) ([172.28.33.235]) by atfriesa01.ssi-schaefer.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Sep 2020 03:11:32 +0200 Received: from timw0248.wamas.com ([172.28.53.68]) by mailhost.salomon.at with esmtps (UNKNOWN:AES256-GCM-SHA384:256) (Exim 4.77) (envelope-from ) id 1kCupf-0001B5-51; Tue, 01 Sep 2020 03:11:31 +0200 Message-ID: <1598922690.7789.35.camel@ssi-schaefer.com> Subject: Re: pid_t on 64-bit Windows From: Martin Oberzalek To: bug-gnulib@gnu.org Date: Tue, 01 Sep 2020 03:11:30 +0200 In-Reply-To: <9000458.LPsGitB5CR@omega> References: <5981491.j28A7ECyTM@omega> <1598861594.19486.25.camel@ssi-schaefer.com> <9000458.LPsGitB5CR@omega> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.6 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=193.186.16.100; envelope-from=martin.oberzalek@ssi-schaefer.com; helo=atfriesa01.ssi-schaefer.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/08/31 21:11:31 X-ACL-Warn: Detected OS = FreeBSD 9.x or newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: bug-gnulib@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Gnulib discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bruno Haible Errors-To: bug-gnulib-bounces+normalperson=yhbt.net@gnu.org Sender: "bug-gnulib" Hi Bruno, > Your email is hardly readable, because I'm sorry for that. I hope it is fixed now. > > _spawnvp(), or _wspawnvp() are not returning a pid. It is a process handle. > > No one claimed that _spawnvp() is returning a pid. What I wan't to point out is that in gnulib on WIN32 API pid_t is not a process id like it is on linux. Functions in gnulib that are using pid_t eg waitpid() accepting a process handle instead. I'm using parity[1] in an gentoo prefix environment to compile in linux like style win32 as win64 applications. parity is a wrapper around the visual stdio compiler and it defines pid_t as int. Because getpid() return also int. And GetCurrentProcessId() as well. So if I compile a project that is using gnulib I might get a compiler error because of the different definition of pid_t. (In best case. Depending on the situation, the programm will simple crash) For my use case a better solution would be a compile time test in the configure script that tests the existance of pid_t. Another solution would be not using pid_t in gnulib at all. Just redefining it in a way like #if ( defined(_WIN64) || _defined(_WIN32) ) && !defined(__CYGWIN__) intprt_t GNULIB_PID_HANDLE #else pid_t GNULIB_PID_HANDLE #endif What do you think? Martin [1] https://github.com/mduft/parity