bug#18238: Fix for DOS build when using more accurate config[.h].in

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 1767 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2202 bytes --]

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Andreas Schwab]

Reuben Thomas <rrt@sc3d.org> writes:

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

s/that/than/

Andreas.

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

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 320 bytes --]

On 10 August 2014 17:52, Andreas Schwab <schwab@linux-m68k.org> wrote:

> Reuben Thomas <rrt@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

[-- Attachment #2: Type: text/html, Size: 739 bytes --]

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Stefan Monnier]

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

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Eli Zaretskii]

> Date: Sun, 10 Aug 2014 17:47:11 +0100
> From: Reuben Thomas <rrt@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.

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Reuben Thomas]

[-- Attachment #1: Type: text/plain, Size: 993 bytes --]

On 10 August 2014 19:05, Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 10 Aug 2014 17:47:11 +0100
> > From: Reuben Thomas <rrt@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

[-- Attachment #2: Type: text/html, Size: 1557 bytes --]

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Eli Zaretskii]

> Date: Sun, 10 Aug 2014 19:20:48 +0100
> From: Reuben Thomas <rrt@sc3d.org>
> Cc: 18238@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.

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Eli Zaretskii]

> Date: Sun, 10 Aug 2014 21:28:34 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 18238@debbugs.gnu.org
> 
> > Date: Sun, 10 Aug 2014 19:20:48 +0100
> > From: Reuben Thomas <rrt@sc3d.org>
> > Cc: 18238@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.

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Stefan Kangas]

Reuben Thomas <rrt@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

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Reuben Thomas via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[-- Attachment #1: Type: text/plain, Size: 196 bytes --]

On Fri, 22 Oct 2021 at 20:02, Stefan Kangas <stefan@marxist.se> wrote:

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

(This is Eli's call.)

-- 
https://rrt.sc3d.org

[-- Attachment #2: Type: text/html, Size: 740 bytes --]

bug#18238: Fix for DOS build when using more accurate config[.h].in

[Eli Zaretskii]

tags 18238 wontfix
close 18238
thanks

> From: Stefan Kangas <stefan@marxist.se>
> Date: Fri, 22 Oct 2021 15:02:17 -0400
> Cc: 18238@debbugs.gnu.org
> 
> Reuben Thomas <rrt@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.