GNU bug report logs - #8800
24.0.50: At revno: 104484 alloc.c does not compile

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#8800: closed (24.0.50: At revno: 104484 alloc.c does not compile)
Date: Mon, 06 Jun 2011 05:00:04 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 05 Jun 2011 21:59:20 -0700
with message-id <4DEC5EA8.6000904 <at> cs.ucla.edu>
and subject line Re: Compilation error caused by SPARE_MEMORY
has caused the GNU bug report #8800,
regarding 24.0.50: At revno: 104484 alloc.c does not compile
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
8800: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8800
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Peter Dyballa <Peter_Dyballa <at> Freenet.DE>
To: bug-gnu-emacs <at> gnu.org
Subject: 24.0.50: At revno: 104484 alloc.c does not compile
Date: Sat, 4 Jun 2011 12:34:04 +0200

Hello!

The is the report of GCC 4.5.2:

alloc.c: In function ‘memory_full’:
alloc.c:3286:7: error: ‘SPARE_MEMORY’ undeclared (first use in this  
function)
alloc.c:3286:7: note: each undeclared identifier is reported only once  
for each function it appears in

In src/alloc.c I have:

  187	/* Points to memory space allocated as "spare", to be freed if  
we run
  188	   out of memory.  We keep one large block, four cons-blocks, and
  189	   two string blocks.  */
  190	
  191	static char *spare_memory[7];
  192	
  193	#ifndef SYSTEM_MALLOC
  194	/* Amount of spare memory to keep in large reserve block.  */
  195	
  196	#define SPARE_MEMORY (1 << 14)
  197	#endif

In src/config.h I have, around line #1060:

	#define SYSTEM_MALLOC 1

so SPARE_MEMORY does not get defined.

--
Greetings

  Pete

And always remember the last words of my grandfather, who said: “A  
truck!”
				— Emo Phillips

[Message part 3 (message/rfc822, inline)]

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 8800-done <at> debbugs.gnu.org, Emacs Development <Emacs-devel <at> gnu.org>
Subject: Re: Compilation error caused by SPARE_MEMORY
Date: Sun, 05 Jun 2011 21:59:20 -0700

On 06/05/11 14:54, Glenn Morris wrote:

> As reported in http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8800

Thanks, that is a bug I recently introduced; it affects hosts such
as MacOS that define SYSTEM_MALLOC.  I fixed it in the trunk with
bzr 104508, as follows:

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-06-05 22:46:26 +0000
+++ src/ChangeLog	2011-06-06 04:54:23 +0000
@@ -1,3 +1,11 @@
+2011-06-06  Paul Eggert  <eggert <at> cs.ucla.edu>
+
+	* alloc.c (memory_full) [SYSTEM_MALLOC]: Port to MacOS (Bug#8800).
+	Do not assume that spare memory exists; that assumption is valid
+	only if SYSTEM_MALLOC.
+	(LARGE_REQUEST): New macro, so that the issue of large requests
+	is separated from the issue of spare memory.
+
 2011-06-05  Andreas Schwab  <schwab <at> linux-m68k.org>
 
 	* editfns.c (Fformat): Correctly handle zero flag with hexadecimal

=== modified file 'src/alloc.c'
--- src/alloc.c	2011-06-02 08:35:28 +0000
+++ src/alloc.c	2011-06-06 04:54:23 +0000
@@ -196,6 +196,12 @@
 #define SPARE_MEMORY (1 << 14)
 #endif
 
+#ifdef SYSTEM_MALLOC
+# define LARGE_REQUEST (1 << 14)
+#else
+# define LARGE_REQUEST SPARE_MEMORY
+#endif
+
 /* Number of extra blocks malloc should get when it needs more core.  */
 
 static int malloc_hysteresis;
@@ -3283,15 +3289,12 @@
 {
   /* Do not go into hysterics merely because a large request failed.  */
   int enough_free_memory = 0;
-  if (SPARE_MEMORY < nbytes)
+  if (LARGE_REQUEST < nbytes)
     {
-      void *p = malloc (SPARE_MEMORY);
+      void *p = malloc (LARGE_REQUEST);
       if (p)
 	{
-	  if (spare_memory[0])
-	    free (p);
-	  else
-	    spare_memory[0] = p;
+	  free (p);
 	  enough_free_memory = 1;
 	}
     }

Previous Next

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