[Emacs-bug-tracker] bug#8800: closed (24.0.50: At revno: 104484 alloc.c does not compile)

[GNU bug Tracking System]

Your message dated Sun, 05 Jun 2011 21:59:20 -0700
with message-id <address@hidden>
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
address@hidden)


-- 
8800: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=8800
GNU Bug Tracking System
Contact address@hidden with problems
> --- Begin Message ---
>
>
>
> 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
>
>
>
>
> --- End Message ---
> --- Begin Message ---
>
>
>
> Subject: 
>
> Re: Compilation error caused by SPARE_MEMORY
>
>
>
>
> Date: 
>
> Sun, 05 Jun 2011 21:59:20 -0700
>
>
>
>
> User-agent: 
>
> Mozilla/5.0 (X11; U; Linux i686; en-US;	rv:1.9.2.17) Gecko/20110424 Thunderbird/3.1.10
>
>
>
>
> 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  <address@hidden>
> +
> +       * 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  <address@hidden>
>  
>         * 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;
>         }
>      }
>
>
>
> --- End Message ---