From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Warnings in mingw64 build on emacs-28 branch Date: Sun, 07 Nov 2021 20:39:45 +0200 Message-ID: <8335o795e6.fsf@gnu.org> References: <86y260c9b8.fsf@gmail.com> <83fss880qc.fsf@gnu.org> <87r1bsezfn.fsf@telefonica.net> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19466"; mail-complaints-to="usenet@ciao.gmane.io" Cc: emacs-devel@gnu.org To: =?utf-8?Q?=C3=93scar?= Fuentes Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Nov 07 19:44:16 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mjn9M-0004tr-7T for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Nov 2021 19:44:16 +0100 Original-Received: from [::1] (port=58610 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mjn9K-0004o3-5L for ged-emacs-devel@m.gmane-mx.org; Sun, 07 Nov 2021 13:44:14 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:39726) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjn5C-0001z5-BL for emacs-devel@gnu.org; Sun, 07 Nov 2021 13:39:59 -0500 Original-Received: from [2001:470:142:3::e] (port=52790 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjn5B-00063o-Ni; Sun, 07 Nov 2021 13:39:57 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=biCy2aBNEWT8JhppIKdAwVxdBG16QPWXsZCBJKKtmC0=; b=A2NrVGmc6rfDrGfcrzvj lKCk7Kkjf3gC1g1t2l/yQrw3NhWfmVjOU+jShraWZ9n5VPI4286rjr36GS1ZF2wzHwcKSSFLKG45h umO7uCGxvzKL9FTkZwhjumTI5piN95DF/kDw5SDizVO68VZ3gKGMDogaSYVV0wciMVe8+mYfzuMtY 6udCQBXMyjZ74P1Q+ikFPXSEJved5khjGasd9OLaDggCXT5xAV98Rmcqd8HNWCZFiCy5Q5qLjbCCW VaYOyqF20bBzMVqPMBLsJ2rVJ+N/c1rMthZY6AY8Bx5lQpSqc7fL5jMY1SVO2AxvWvFzm84ZwFbIJ 4ML7Rvgkv5VeSA==; Original-Received: from [87.69.77.57] (port=3691 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mjn5A-00023I-MO; Sun, 07 Nov 2021 13:39:57 -0500 In-Reply-To: <87r1bsezfn.fsf@telefonica.net> (message from =?utf-8?Q?=C3=93scar?= Fuentes on Sun, 07 Nov 2021 16:51:56 +0100) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:278974 Archived-At: > From: Óscar Fuentes > Date: Sun, 07 Nov 2021 16:51:56 +0100 > > AFAIU that call to VirtualQuery does not do what we want. When lpAddress > is provided the function rounds down the address to a page boundary and > starts scanning pages *up*. Since we want information about the capacity > of the stack, the scan ignores all the space below the current page > boundary. How do you see that it _ignores_ that space? The code does this: rlp->rlim_cur = (DWORD_PTR) &m - (DWORD_PTR) m.AllocationBase; m.AllocationBase is not the page of 'm', it's the base address of a range of pages to which 'm' belongs. And since Emacs calls getrlimit very early during its startup, directly from 'main', 'm' is not far from the beginning of the stack, and m.AllocationBase is very likely to be the base address of the memory initially allocated for the stack. It is a matter of fact that the result of this code produces the 8MB stack size that Emacs on Windows is compiled to use (see the link command in src/Makefile.in). So it isn't just the theory, that code actually works. So I think we are okay in that department.