GNU bug report logs - #18238
Fix for DOS build when using more accurate config[.h].in

Previous Next

Package: emacs;

Reported by: Reuben Thomas <rrt <at> sc3d.org>

Date: Sun, 10 Aug 2014 16:48:01 UTC

Severity: wishlist

Tags: wontfix

Done: Eli Zaretskii <eliz <at> gnu.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 18238 in the body.
You can then email your comments to 18238 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Sun, 10 Aug 2014 16:48:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Reuben Thomas <rrt <at> sc3d.org>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 10 Aug 2014 16:48:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: bug-emacs <bug-emacs <at> gnu.org>
Subject: Fix for DOS build when using more accurate config[.h].in
Date: Sun, 10 Aug 2014 17:47:11 +0100
[Message part 1 (text/plain, inline)]
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
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Sun, 10 Aug 2014 16:53:01 GMT) Full text and rfc822 format available.

Message #8 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 18238 <at> debbugs.gnu.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Sun, 10 Aug 2014 18:52:05 +0200
Reuben Thomas <rrt <at> sc3d.org> writes:

> +  /* Don't believe they will give us more that 0.5 GB.   */

s/that/than/

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Sun, 10 Aug 2014 16:54:02 GMT) Full text and rfc822 format available.

Message #11 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: 18238 <at> debbugs.gnu.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Sun, 10 Aug 2014 17:53:21 +0100
[Message part 1 (text/plain, inline)]
On 10 August 2014 17:52, Andreas Schwab <schwab <at> linux-m68k.org> wrote:

> Reuben Thomas <rrt <at> sc3d.org> writes:
>
> > +  /* Don't believe they will give us more that 0.5 GB.   */
>
> s/that/than/
>

Thanks, I guess I can fix such a trivial typo in the same commit, rather
than in a separate one?

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Sun, 10 Aug 2014 18:00:04 GMT) Full text and rfc822 format available.

Message #14 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 18238 <at> debbugs.gnu.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Sun, 10 Aug 2014 13:59:12 -0400
> -#ifdef HAVE_GETRLIMIT
> +#ifdef MSDOS

Please add a comment here with your explanation about how DJGPP does
have getrlimit but it's not good enough.


        Stefan




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Sun, 10 Aug 2014 18:06:02 GMT) Full text and rfc822 format available.

Message #17 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 18238 <at> debbugs.gnu.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Sun, 10 Aug 2014 21:05:17 +0300
> Date: Sun, 10 Aug 2014 17:47:11 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
> 
> 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?

I don't see why the suggested code is better than the existing one.
HAVE_GETRLIMIT means more than its name says, as you point out, so
DJGPP is correct in not defining one.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Sun, 10 Aug 2014 18:21:02 GMT) Full text and rfc822 format available.

Message #20 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 18238 <at> debbugs.gnu.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Sun, 10 Aug 2014 19:20:48 +0100
[Message part 1 (text/plain, inline)]
On 10 August 2014 19:05, Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Sun, 10 Aug 2014 17:47:11 +0100
> > From: Reuben Thomas <rrt <at> sc3d.org>
> >
> > 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?
>
> I don't see why the suggested code is better than the existing one.
> HAVE_GETRLIMIT means more than its name says, as you point out, so
> DJGPP is correct in not defining one.
>

I think I was unclear, sorry: DJGPP does define getrlimit. It is only the
MSDOS config.in that says it is not defined. If you run ./configure, then
it detects getrlimit, and defines HAVE_GETRLIMIT.

-- 
http://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Sun, 10 Aug 2014 18:29:01 GMT) Full text and rfc822 format available.

Message #23 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 18238 <at> debbugs.gnu.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Sun, 10 Aug 2014 21:28:34 +0300
> Date: Sun, 10 Aug 2014 19:20:48 +0100
> From: Reuben Thomas <rrt <at> sc3d.org>
> Cc: 18238 <at> debbugs.gnu.org
> 
> > I don't see why the suggested code is better than the existing one.
> > HAVE_GETRLIMIT means more than its name says, as you point out, so
> > DJGPP is correct in not defining one.
> >
> 
> I think I was unclear, sorry: DJGPP does define getrlimit. It is only the
> MSDOS config.in that says it is not defined. If you run ./configure, then
> it detects getrlimit, and defines HAVE_GETRLIMIT.

Then it's a bug in the configure test for getrlimit: it should not
only test for the existence of the function, but also for RLIMIT_AS
and RLIMIT_DATA it actually needs.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Sun, 10 Aug 2014 19:37:01 GMT) Full text and rfc822 format available.

Message #26 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: rrt <at> sc3d.org
Cc: 18238 <at> debbugs.gnu.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Sun, 10 Aug 2014 22:35:58 +0300
> Date: Sun, 10 Aug 2014 21:28:34 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 18238 <at> debbugs.gnu.org
> 
> > Date: Sun, 10 Aug 2014 19:20:48 +0100
> > From: Reuben Thomas <rrt <at> sc3d.org>
> > Cc: 18238 <at> debbugs.gnu.org
> > 
> > > I don't see why the suggested code is better than the existing one.
> > > HAVE_GETRLIMIT means more than its name says, as you point out, so
> > > DJGPP is correct in not defining one.
> > >
> > 
> > I think I was unclear, sorry: DJGPP does define getrlimit. It is only the
> > MSDOS config.in that says it is not defined. If you run ./configure, then
> > it detects getrlimit, and defines HAVE_GETRLIMIT.
> 
> Then it's a bug in the configure test for getrlimit: it should not
> only test for the existence of the function, but also for RLIMIT_AS
> and RLIMIT_DATA it actually needs.

Alternatively, you could leave the configure test alone, and instead
test for RLIMIT_* constants in the conditional, like this:

 #if defined HAVE_GETRLIMIT && defined RLIMIT_DATA && defined RLIMIT_AS
  ...

etc.  This is what emacs.c does with HAVE_SETRLIMIT.




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Fri, 22 Oct 2021 19:03:03 GMT) Full text and rfc822 format available.

Message #29 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Reuben Thomas <rrt <at> sc3d.org>
Cc: 18238 <at> debbugs.gnu.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Fri, 22 Oct 2021 15:02:17 -0400
Reuben Thomas <rrt <at> sc3d.org> writes:

> 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?

(That was in 2014.)

It seems like this patch was never installed.  Is it still relevant?

> === 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Fri, 22 Oct 2021 21:15:01 GMT) Full text and rfc822 format available.

Message #32 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Reuben Thomas <rrt <at> sc3d.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 18238 <at> debbugs.gnu.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Fri, 22 Oct 2021 22:14:02 +0100
[Message part 1 (text/plain, inline)]
On Fri, 22 Oct 2021 at 20:02, Stefan Kangas <stefan <at> marxist.se> wrote:

>
> It seems like this patch was never installed.  Is it still relevant?
>

(This is Eli's call.)

-- 
https://rrt.sc3d.org
[Message part 2 (text/html, inline)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#18238; Package emacs. (Sat, 23 Oct 2021 06:20:02 GMT) Full text and rfc822 format available.

Message #35 received at 18238 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefan <at> marxist.se>
Cc: 18238 <at> debbugs.gnu.org, rrt <at> sc3d.org
Subject: Re: bug#18238: Fix for DOS build when using more accurate
 config[.h].in
Date: Sat, 23 Oct 2021 09:18:54 +0300
tags 18238 wontfix
close 18238
thanks

> From: Stefan Kangas <stefan <at> marxist.se>
> Date: Fri, 22 Oct 2021 15:02:17 -0400
> Cc: 18238 <at> debbugs.gnu.org
> 
> Reuben Thomas <rrt <at> sc3d.org> writes:
> 
> > 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?
> 
> (That was in 2014.)
> 
> It seems like this patch was never installed.  Is it still relevant?

It's as relevant as it was back then, but I see no reason to make a
change with no actual functionality changes, just so the world knows
that DJGPP does have (a limited version of) getrlimit.  So I'm closing
this bug (after fixing the typo pointed by Andreas).

Thanks.




Added tag(s) wontfix. Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Sat, 23 Oct 2021 06:20:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 18238 <at> debbugs.gnu.org and Reuben Thomas <rrt <at> sc3d.org> Request was from Eli Zaretskii <eliz <at> gnu.org> to control <at> debbugs.gnu.org. (Sat, 23 Oct 2021 06:20:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Sat, 20 Nov 2021 12:24:08 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 151 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.