From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Reuben Thomas Newsgroups: gmane.emacs.bugs Subject: bug#18238: Fix for DOS build when using more accurate config[.h].in Date: Sun, 10 Aug 2014 17:47:11 +0100 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1133a8d89c4f6705004930e0 X-Trace: ger.gmane.org 1407689294 15783 80.91.229.3 (10 Aug 2014 16:48:14 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 10 Aug 2014 16:48:14 +0000 (UTC) To: 18238@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Aug 10 18:48:08 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XGWHw-0004A7-6Q for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Aug 2014 18:48:08 +0200 Original-Received: from localhost ([::1]:60328 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGWHv-0000Q7-Sb for geb-bug-gnu-emacs@m.gmane.org; Sun, 10 Aug 2014 12:48:07 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33406) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGWHr-0000Q2-WA for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 12:48:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGWHq-0002Oq-Rg for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 12:48:03 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:59179) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGWHq-0002Om-Oj for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 12:48:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XGWHq-0007i6-8n for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 12:48:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Reuben Thomas Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 10 Aug 2014 16:48:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 18238 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-emacs Original-Received: via spool by submit@debbugs.gnu.org id=B.140768924929583 (code B ref -1); Sun, 10 Aug 2014 16:48:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 10 Aug 2014 16:47:29 +0000 Original-Received: from localhost ([127.0.0.1]:37889 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XGWHI-0007h5-IW for submit@debbugs.gnu.org; Sun, 10 Aug 2014 12:47:29 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:59824) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XGWHF-0007gr-1i for submit@debbugs.gnu.org; Sun, 10 Aug 2014 12:47:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGWH8-00029x-9O for submit@debbugs.gnu.org; Sun, 10 Aug 2014 12:47:19 -0400 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:41572) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGWH8-00029t-5w for submit@debbugs.gnu.org; Sun, 10 Aug 2014 12:47:18 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33308) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGWH6-0000On-C9 for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 12:47:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGWH5-000295-A0 for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 12:47:16 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56247) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGWH5-000291-6l for bug-gnu-emacs@gnu.org; Sun, 10 Aug 2014 12:47:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57457) by fencepost.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1XGWH4-0008Oy-Tz for bug-emacs@gnu.org; Sun, 10 Aug 2014 12:47:15 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XGWH3-00028n-KO for bug-emacs@gnu.org; Sun, 10 Aug 2014 12:47:14 -0400 Original-Received: from mail-la0-x234.google.com ([2a00:1450:4010:c03::234]:44387) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XGWH3-00028b-7F for bug-emacs@gnu.org; Sun, 10 Aug 2014 12:47:13 -0400 Original-Received: by mail-la0-f52.google.com with SMTP id b17so4896148lan.39 for ; Sun, 10 Aug 2014 09:47:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sc3d.org; s=google; h=mime-version:date:message-id:subject:from:to:content-type; bh=4ZWbwTOwk4RpcgWYdE6l2t+sDWI/N5YcV/2FkZub7Rk=; b=kLiE3w7NWX+xiN+a1imhNhmwJ5N+H1h1ohPdp9ho1vmMGKNVhXBJ58wTgDMAToOwrF tdtntoMXkV3VX3MrDUUrH6SRhn0OHqDRg+jA5wdf2SQgDuyUB/icpIyAiZaqaNBs0/xe etJ3P6aKCRhMEMglTXZm/+rzti4+Oj+3JAGqo= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=4ZWbwTOwk4RpcgWYdE6l2t+sDWI/N5YcV/2FkZub7Rk=; b=j4vJXaEiWlOLhx+TxLKBX7cY+9AcCkQg+wxdlq7r33jyAv0/oyHeggFSSHHcoJVdWX DJwj/CSukmqRdEihQvaJ5+1ayRVYY4SUriIJxH//LFygKbxe3G7aGBLEh5RYL2II16Nr l7PGnbJMw5GzIb5PUb0c37dF3B//11502Vxa5Yz84XJ4ej20K2qk8TgaPYTR/ZoEGnZC +4qzEc/YVPqS07158FtZIwoI/15s6ngBqlpSOhoc0yict1BQEht6NPdvZ6N/I/qAExJL qXdfZ+yt+XtqqqxDXiD0Pp7Jm8DCDHcEZPMLeZoYEtYeiChZvwoPeVK4fvttLI4zbvYl uuLw== X-Gm-Message-State: ALoCoQn8Ap+MXk3GyVbmlRi7pLhzPtcqmFMdgkfzxc1WmyGDAEvwqhzzRcQzn0y56uxO8o+6LTky X-Received: by 10.152.164.229 with SMTP id yt5mr2941072lab.19.1407689231708; Sun, 10 Aug 2014 09:47:11 -0700 (PDT) Original-Received: by 10.152.246.10 with HTTP; Sun, 10 Aug 2014 09:47:11 -0700 (PDT) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:92377 Archived-At: --001a1133a8d89c4f6705004930e0 Content-Type: text/plain; charset=UTF-8 DJGPP does actually have getrlimit. The special config[.h].in for MSDOS lies and says it hasn't. However, this is a white lie, because getrlimit on DJGPP doesn't support RLIMIT_AS/RLIMIT_DATA, which is what we want, so we still want the workaround code. The following patch simply reverses the order of a couple of tests in vm-limit.c so that being on MSDOS overrides HAVE_GETRLIMIT. Is it OK to install? === modified file 'src/vm-limit.c' --- src/vm-limit.c 2014-07-11 10:09:51 +0000 +++ src/vm-limit.c 2014-08-10 16:44:24 +0000 @@ -71,7 +71,27 @@ /* Number of bytes of writable memory we can expect to be able to get. */ static size_t lim_data; -#ifdef HAVE_GETRLIMIT +#ifdef MSDOS + +void +get_lim_data (void) +{ + unsigned long totalram, freeram, totalswap, freeswap; + + dos_memory_info (&totalram, &freeram, &totalswap, &freeswap); + lim_data = freeram; + /* Don't believe they will give us more that 0.5 GB. */ + if (lim_data > 512U * 1024U * 1024U) + lim_data = 512U * 1024U * 1024U; +} + +unsigned long +ret_lim_data (void) +{ + get_lim_data (); + return lim_data; +} +#elif defined HAVE_GETRLIMIT # ifndef RLIMIT_AS # define RLIMIT_AS RLIMIT_DATA @@ -101,26 +121,6 @@ lim_data = reserved_heap_size; } -#elif defined MSDOS - -void -get_lim_data (void) -{ - unsigned long totalram, freeram, totalswap, freeswap; - - dos_memory_info (&totalram, &freeram, &totalswap, &freeswap); - lim_data = freeram; - /* Don't believe they will give us more that 0.5 GB. */ - if (lim_data > 512U * 1024U * 1024U) - lim_data = 512U * 1024U * 1024U; -} - -unsigned long -ret_lim_data (void) -{ - get_lim_data (); - return lim_data; -} #else # error "get_lim_data not implemented on this machine" #endif -- http://rrt.sc3d.org --001a1133a8d89c4f6705004930e0 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
DJGPP does actually have getrlimit. The special confi= g[.h].in for MSDOS lies and says it hasn't. However, this is a white li= e, because getrlimit on DJGPP doesn't support RLIMIT_AS/RLIMIT_DATA, wh= ich is what we want, so we still want the workaround code. The following pa= tch simply reverses the order of a couple of tests in vm-limit.c so that be= ing on MSDOS overrides HAVE_GETRLIMIT.

Is it OK to install?

=3D=3D=3D mod= ified file 'src/vm-limit.c'
--- src/vm-limit.c=C2=A0=C2=A0=C2=A0= 2014-07-11 10:09:51 +0000
+++ src/vm-limit.c=C2=A0=C2=A0=C2=A0 2014-08-= 10 16:44:24 +0000
@@ -71,7 +71,27 @@
=C2=A0/* Number of bytes of writable memory we can expect to be able to get= .=C2=A0 */
=C2=A0static size_t lim_data;
=C2=A0

-#ifdef HAVE_G= ETRLIMIT
+#ifdef MSDOS
+
+void
+get_lim_data (void)
+{
+= =C2=A0 unsigned long totalram, freeram, totalswap, freeswap;
+
+=C2=A0 dos_memory_info (&totalram, &freeram, &totalswap, = &freeswap);
+=C2=A0 lim_data =3D freeram;
+=C2=A0 /* Don't be= lieve they will give us more that 0.5 GB.=C2=A0=C2=A0 */
+=C2=A0 if (lim= _data > 512U * 1024U * 1024U)
+=C2=A0=C2=A0=C2=A0 lim_data =3D 512U * 1024U * 1024U;
+}
+
+unsig= ned long
+ret_lim_data (void)
+{
+=C2=A0 get_lim_data ();
+=C2= =A0 return lim_data;
+}
+#elif defined HAVE_GETRLIMIT
=C2=A0
= =C2=A0# ifndef RLIMIT_AS
=C2=A0#=C2=A0 define RLIMIT_AS RLIMIT_DATA
@@ -101,26 +121,6 @@
=C2=A0=C2=A0 lim_data =3D reserved_heap_size;
= =C2=A0}
=C2=A0
-#elif defined MSDOS
-
-void
-get_lim_data (v= oid)
-{
-=C2=A0 unsigned long totalram, freeram, totalswap, freeswap;=
-
-=C2=A0 dos_memory_info (&totalram, &freeram, &totalsw= ap, &freeswap);
-=C2=A0 lim_data =3D freeram;
-=C2=A0 /* Don't believe they will giv= e us more that 0.5 GB.=C2=A0=C2=A0 */
-=C2=A0 if (lim_data > 512U * 1= 024U * 1024U)
-=C2=A0=C2=A0=C2=A0 lim_data =3D 512U * 1024U * 1024U;
= -}
-
-unsigned long
-ret_lim_data (void)
-{
-=C2=A0 get_lim_data ();
-=C2=A0 return lim_data;
-}
=C2=A0#= else
=C2=A0# error "get_lim_data not implemented on this machine&qu= ot;
=C2=A0#endif

--
http://rr= t.sc3d.org
--001a1133a8d89c4f6705004930e0--