GNU bug report logs - #9119
[PATCH] modernize function definitions in gmalloc.c

Previous Next

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

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

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

From: Daniel Colascione <dan.colascione <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: [PATCH] modernize function definitions in gmalloc.c
Date: Mon, 18 Jul 2011 16:46:36 -0700

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

The warnings were annoying me.

=== modified file 'src/ChangeLog'
--- src/ChangeLog	2011-07-18 20:32:34 +0000
+++ src/ChangeLog	2011-07-18 23:38:06 +0000
@@ -1,5 +1,7 @@
 2011-07-18  Daniel Colascione  <dan.colascione <at> gmail.com>

+	* gmalloc.c: modernize function definitions throughout.

 2011-07-18  Paul Eggert  <eggert <at> cs.ucla.edu>

=== modified file 'src/gmalloc.c'
--- src/gmalloc.c	2011-05-28 22:39:39 +0000
+++ src/gmalloc.c	2011-07-18 23:38:06 +0000
@@ -485,8 +485,7 @@
 /* Aligned allocation.  */
 static __ptr_t align PP ((__malloc_size_t));
 static __ptr_t
-align (size)
-     __malloc_size_t size;
+align (__malloc_size_t size)
 {
   __ptr_t result;
   unsigned long int adj;
@@ -520,9 +519,8 @@
    If we cannot get space at END, fail and return 0.  */
 static __ptr_t get_contiguous_space PP ((__malloc_ptrdiff_t, __ptr_t));
 static __ptr_t
-get_contiguous_space (size, position)
-     __malloc_ptrdiff_t size;
-     __ptr_t position;
+get_contiguous_space (__malloc_ptrdiff_t size,
+                      __ptr_t position)
 {
   __ptr_t before;
   __ptr_t after;
@@ -578,21 +576,21 @@
 int _malloc_thread_enabled_p;

 static void
-malloc_atfork_handler_prepare ()
+malloc_atfork_handler_prepare (void)
 {
   LOCK ();
   LOCK_ALIGNED_BLOCKS ();
 }

 static void
-malloc_atfork_handler_parent ()
+malloc_atfork_handler_parent (void)
 {
   UNLOCK_ALIGNED_BLOCKS ();
   UNLOCK ();
 }

 static void
-malloc_atfork_handler_child ()
+malloc_atfork_handler_child (void)
 {
   UNLOCK_ALIGNED_BLOCKS ();
   UNLOCK ();
@@ -600,7 +598,7 @@

 /* Set up mutexes and make malloc etc. thread-safe.  */
 void
-malloc_enable_thread ()
+malloc_enable_thread (void)
 {
   if (_malloc_thread_enabled_p)
     return;
@@ -619,7 +617,7 @@
 #endif

 static void
-malloc_initialize_1 ()
+malloc_initialize_1 (void)
 {
 #ifdef GC_MCHECK
   mcheck (NULL);
@@ -650,7 +648,7 @@
    main will call malloc which calls this function.  That is before any
threads
    or signal handlers has been set up, so we don't need thread
protection.  */
 int
-__malloc_initialize ()
+__malloc_initialize (void)
 {
   if (__malloc_initialized)
     return 0;
@@ -666,8 +664,7 @@
    growing the heap info table as necessary. */
 static __ptr_t morecore_nolock PP ((__malloc_size_t));
 static __ptr_t
-morecore_nolock (size)
-     __malloc_size_t size;
+morecore_nolock (__malloc_size_t size)
 {
   __ptr_t result;
   malloc_info *newinfo, *oldinfo;
@@ -780,8 +777,7 @@

 /* Allocate memory from the heap.  */
 __ptr_t
-_malloc_internal_nolock (size)
-     __malloc_size_t size;
+_malloc_internal_nolock (__malloc_size_t size)
 {
   __ptr_t result;
   __malloc_size_t block, blocks, lastblocks, start;
@@ -980,8 +976,7 @@
 }

 __ptr_t
-_malloc_internal (size)
-     __malloc_size_t size;
+_malloc_internal (__malloc_size_t size)
 {
   __ptr_t result;

@@ -993,8 +988,7 @@
 }

 __ptr_t
-malloc (size)
-     __malloc_size_t size;
+malloc (__malloc_size_t size)
 {
   __ptr_t (*hook) (__malloc_size_t);

@@ -1019,23 +1013,19 @@
    and _realloc.  Make them use the GNU functions.  */

 __ptr_t
-_malloc (size)
-     __malloc_size_t size;
+_malloc (__malloc_size_t size)
 {
   return malloc (size);
 }

 void
-_free (ptr)
-     __ptr_t ptr;
+_free (__ptr_t ptr)
 {
   free (ptr);
 }

 __ptr_t
-_realloc (ptr, size)
-     __ptr_t ptr;
-     __malloc_size_t size;
+_realloc (__ptr_t ptr, __malloc_size_t size)
 {
   return realloc (ptr, size);
 }
@@ -1341,8 +1331,7 @@
 /* Return memory to the heap.
    Like `free' but don't call a __free_hook if there is one.  */
 void
-_free_internal (ptr)
-     __ptr_t ptr;
+_free_internal (__ptr_t ptr)
 {
   LOCK ();
   _free_internal_nolock (ptr);
@@ -1352,8 +1341,7 @@
 /* Return memory to the heap.  */

 void
-free (ptr)
-     __ptr_t ptr;
+free (__ptr_t ptr)
 {
   void (*hook) (__ptr_t) = __free_hook;

@@ -1368,8 +1356,7 @@
 weak_alias (free, cfree)
 #else
 void
-cfree (ptr)
-     __ptr_t ptr;
+cfree (__ptr_t ptr)
 {
   free (ptr);
 }
@@ -1417,10 +1404,9 @@
 /* Like bcopy except never gets confused by overlap.  */

 void
-__malloc_safe_bcopy (afrom, ato, size)
-     __ptr_t afrom;
-     __ptr_t ato;
-     __malloc_size_t size;
+__malloc_safe_bcopy (__ptr_t afrom,
+                     __ptr_t ato,
+                     __malloc_size_t size)
 {
   char *from = afrom, *to = ato;

@@ -1493,9 +1479,7 @@
    new region.  This module has incestuous knowledge of the
    internals of both free and malloc. */
 __ptr_t
-_realloc_internal_nolock (ptr, size)
-     __ptr_t ptr;
-     __malloc_size_t size;
+_realloc_internal_nolock (__ptr_t ptr, __malloc_size_t size)
 {
   __ptr_t result;
   int type;
@@ -1611,9 +1595,8 @@
 }

 __ptr_t
-_realloc_internal (ptr, size)
-     __ptr_t ptr;
-     __malloc_size_t size;
+_realloc_internal (__ptr_t ptr,
+                   __malloc_size_t size)
 {
   __ptr_t result;

@@ -1625,9 +1608,8 @@
 }

 __ptr_t
-realloc (ptr, size)
-     __ptr_t ptr;
-     __malloc_size_t size;
+realloc (__ptr_t ptr,
+         __malloc_size_t size)
 {
   __ptr_t (*hook) (__ptr_t, __malloc_size_t);

@@ -1665,9 +1647,8 @@
 /* Allocate an array of NMEMB elements each SIZE bytes long.
    The entire array is initialized to zeros.  */
 __ptr_t
-calloc (nmemb, size)
-     register __malloc_size_t nmemb;
-     register __malloc_size_t size;
+calloc (register __malloc_size_t nmemb,
+        register __malloc_size_t size)
 {
   register __ptr_t result = malloc (nmemb * size);

@@ -1719,8 +1700,7 @@
    and return the start of data space, or NULL on errors.
    If INCREMENT is negative, shrink data space.  */
 __ptr_t
-__default_morecore (increment)
-     __malloc_ptrdiff_t increment;
+__default_morecore (__malloc_ptrdiff_t increment)
 {
   __ptr_t result;
 #if defined(CYGWIN)
@@ -1760,9 +1740,8 @@
 				__malloc_size_t __alignment));

 __ptr_t
-memalign (alignment, size)
-     __malloc_size_t alignment;
-     __malloc_size_t size;
+memalign (__malloc_size_t alignment,
+          __malloc_size_t size)
 {
   __ptr_t result;
   unsigned long int adj, lastadj;
@@ -1843,10 +1822,9 @@
 #endif

 int
-posix_memalign (memptr, alignment, size)
-     __ptr_t *memptr;
-     __malloc_size_t alignment;
-     __malloc_size_t size;
+posix_memalign (__ptr_t *memptr,
+                __malloc_size_t alignment,
+                __malloc_size_t size)
 {
   __ptr_t mem;

@@ -1917,8 +1895,7 @@
 static __malloc_size_t pagesize;

 __ptr_t
-valloc (size)
-     __malloc_size_t size;
+valloc (__malloc_size_t size)
 {
   if (pagesize == 0)
     pagesize = __getpagesize ();
@@ -2001,8 +1978,7 @@

 static enum mcheck_status checkhdr (const struct hdr *);
 static enum mcheck_status
-checkhdr (hdr)
-     const struct hdr *hdr;
+checkhdr (const struct hdr *hdr)
 {
   enum mcheck_status status;
   switch (hdr->magic)
@@ -2025,10 +2001,8 @@
   return status;
 }

-static void freehook (__ptr_t);
 static void
-freehook (ptr)
-     __ptr_t ptr;
+freehook (__ptr_t ptr)
 {
   struct hdr *hdr;

@@ -2047,10 +2021,8 @@
   __free_hook = freehook;
 }

-static __ptr_t mallochook (__malloc_size_t);
 static __ptr_t
-mallochook (size)
-     __malloc_size_t size;
+mallochook (__malloc_size_t size)
 {
   struct hdr *hdr;

@@ -2067,11 +2039,9 @@
   return (__ptr_t) (hdr + 1);
 }

-static __ptr_t reallochook (__ptr_t, __malloc_size_t);
 static __ptr_t
-reallochook (ptr, size)
-     __ptr_t ptr;
-     __malloc_size_t size;
+reallochook (__ptr_t ptr,
+             __malloc_size_t size)
 {
   struct hdr *hdr = NULL;
   __malloc_size_t osize = 0;
@@ -2105,8 +2075,7 @@
 }

 static void
-mabort (status)
-     enum mcheck_status status;
+mabort (enum mcheck_status status)
 {
   const char *msg;
   switch (status)
@@ -2139,8 +2108,7 @@
 static int mcheck_used = 0;

 int
-mcheck (func)
-     void (*func) (enum mcheck_status);
+mcheck (void (*func) (enum mcheck_status))
 {
   abortfunc = (func != NULL) ? func : &mabort;

[signature.asc (application/pgp-signature, attachment)]

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

From: Glenn Morris <rgm <at> gnu.org>
To: Daniel Colascione <dan.colascione <at> gmail.com>
Cc: 9119 <at> debbugs.gnu.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Tue, 19 Jul 2011 13:57:52 -0400

IIRC, traditionally this file has been left alone as much as possible,
so that it does not diverge from the glibc version (although it probably
has). I don't know if this is still the case. Ref eg

http://lists.gnu.org/archive/html/emacs-devel/2003-01/msg00247.html

Also apparently not appropriate for gnulib:

http://lists.gnu.org/archive/html/bug-gnulib/2010-10/msg00268.html

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 9119 <at> debbugs.gnu.org, Daniel Colascione <dan.colascione <at> gmail.com>
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Tue, 19 Jul 2011 21:04:50 +0200

Glenn Morris <rgm <at> gnu.org> writes:

> IIRC, traditionally this file has been left alone as much as possible,
> so that it does not diverge from the glibc version (although it probably
> has).

The contents of this file have been removed from glibc nearly 15 years
ago.

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."

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

From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Glenn Morris <rgm <at> gnu.org>, 9119 <at> debbugs.gnu.org,
	Daniel Colascione <dan.colascione <at> gmail.com>
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Thu, 12 Apr 2012 21:42:15 +0200

Andreas Schwab <schwab <at> linux-m68k.org> writes:

>> IIRC, traditionally this file has been left alone as much as possible,
>> so that it does not diverge from the glibc version (although it probably
>> has).
>
> The contents of this file have been removed from glibc nearly 15 years
> ago.

So would it be OK to apply this patch, then?

-- 
(domestic pets only, the antidote for overdose, milk.)
  bloggy blog http://lars.ingebrigtsen.no/

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
Cc: dan.colascione <at> gmail.com, 9119 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Fri, 13 Apr 2012 11:15:15 +0300

> From: Lars Magne Ingebrigtsen <larsi <at> gnus.org>
> Date: Thu, 12 Apr 2012 21:42:15 +0200
> MailScanner-NULL-Check: 1334864536.4355 <at> naLKYcv0obmsenG/4Sd/Qg
> Cc: 9119 <at> debbugs.gnu.org, Daniel Colascione <dan.colascione <at> gmail.com>
> 
> Andreas Schwab <schwab <at> linux-m68k.org> writes:
> 
> >> IIRC, traditionally this file has been left alone as much as possible,
> >> so that it does not diverge from the glibc version (although it probably
> >> has).
> >
> > The contents of this file have been removed from glibc nearly 15 years
> > ago.
> 
> So would it be OK to apply this patch, then?

Yes, please.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dan.colascione <at> gmail.com, 9119 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Fri, 13 Apr 2012 23:31:56 +0200

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

>> So would it be OK to apply this patch, then?
>
> Yes, please.

For some reason or other, patch won't accept the, er, patch:

patch: **** malformed patch at line 19: === modified file 'src/gmalloc.c'

I can't really see anything wrong with the patch by eyeballing it,
though.  Odd.

Dan, could you resend the patch as an attachment, by any chance?

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: Eli Zaretskii <eliz <at> gnu.org>, dan.colascione <at> gmail.com,
	9119 <at> debbugs.gnu.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Fri, 13 Apr 2012 23:43:47 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>>> So would it be OK to apply this patch, then?
>>
>> Yes, please.
>
> For some reason or other, patch won't accept the, er, patch:
>
> patch: **** malformed patch at line 19: === modified file 'src/gmalloc.c'
>
> I can't really see anything wrong with the patch by eyeballing it,
> though.  Odd.

The first hunk is obviously broken.  It claims to add two lines but adds
only one.

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."

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, dan.colascione <at> gmail.com,
	9119 <at> debbugs.gnu.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Fri, 13 Apr 2012 18:35:54 -0400

On 4/13/2012 5:43 PM, Andreas Schwab wrote:
> Lars Ingebrigtsen<larsi <at> gnus.org>  writes:
>
>> Eli Zaretskii<eliz <at> gnu.org>  writes:
>>
>>>> So would it be OK to apply this patch, then?
>>>
>>> Yes, please.
>>
>> For some reason or other, patch won't accept the, er, patch:
>>
>> patch: **** malformed patch at line 19: === modified file 'src/gmalloc.c'
>>
>> I can't really see anything wrong with the patch by eyeballing it,
>> though.  Odd.
>
> The first hunk is obviously broken.  It claims to add two lines but adds
> only one.

A more recent version of the patch was submitted in

  http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00609.html

with improvements by Paul and me.  Maybe that should be applied instead.

Ken

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, dan.colascione <at> gmail.com,
	9119 <at> debbugs.gnu.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Fri, 13 Apr 2012 18:42:15 -0400

On 4/13/2012 6:35 PM, Ken Brown wrote:
> On 4/13/2012 5:43 PM, Andreas Schwab wrote:
>> Lars Ingebrigtsen<larsi <at> gnus.org> writes:
>>
>>> Eli Zaretskii<eliz <at> gnu.org> writes:
>>>
>>>>> So would it be OK to apply this patch, then?
>>>>
>>>> Yes, please.
>>>
>>> For some reason or other, patch won't accept the, er, patch:
>>>
>>> patch: **** malformed patch at line 19: === modified file
>>> 'src/gmalloc.c'
>>>
>>> I can't really see anything wrong with the patch by eyeballing it,
>>> though. Odd.
>>
>> The first hunk is obviously broken. It claims to add two lines but adds
>> only one.
>
> A more recent version of the patch was submitted in
>
> http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00609.html
>
> with improvements by Paul and me. Maybe that should be applied instead.

Sorry, what I wrote was unclear.  The patch I just cited isn't really a 
more recent version of the one being discussed, but (with the 
improvements by Paul and me) supersedes the latter.

Ken

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: dan.colascione <at> gmail.com, larsi <at> gnus.org, schwab <at> linux-m68k.org,
	9119 <at> debbugs.gnu.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Sat, 14 Apr 2012 10:07:19 +0300

> Date: Fri, 13 Apr 2012 18:42:15 -0400
> From: Ken Brown <kbrown <at> cornell.edu>
> Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, dan.colascione <at> gmail.com,
> 	9119 <at> debbugs.gnu.org
> 
> > A more recent version of the patch was submitted in
> >
> > http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00609.html
> >
> > with improvements by Paul and me. Maybe that should be applied instead.
> 
> Sorry, what I wrote was unclear.  The patch I just cited isn't really a 
> more recent version of the one being discussed, but (with the 
> improvements by Paul and me) supersedes the latter.

Are you sure you got the URL right?  Perhaps you meant one of the 2
below instead?

  http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00716.html
  http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00720.html

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

From: Ken Brown <kbrown <at> cornell.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: dan.colascione <at> gmail.com, larsi <at> gnus.org, Paul Eggert <eggert <at> cs.ucla.edu>,
	schwab <at> linux-m68k.org, 9119 <at> debbugs.gnu.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Sat, 14 Apr 2012 07:15:14 -0400

On 4/14/2012 3:07 AM, Eli Zaretskii wrote:
>> Date: Fri, 13 Apr 2012 18:42:15 -0400
>> From: Ken Brown<kbrown <at> cornell.edu>
>> Cc: Lars Ingebrigtsen<larsi <at> gnus.org>, dan.colascione <at> gmail.com,
>> 	9119 <at> debbugs.gnu.org
>>
>>> A more recent version of the patch was submitted in
>>>
>>> http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00609.html
>>>
>>> with improvements by Paul and me. Maybe that should be applied instead.
>>
>> Sorry, what I wrote was unclear.  The patch I just cited isn't really a
>> more recent version of the one being discussed, but (with the
>> improvements by Paul and me) supersedes the latter.
>
> Are you sure you got the URL right?  Perhaps you meant one of the 2
> below instead?
>
>    http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00716.html
>    http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00720.html

I was just giving the URL of the beginning of the thread.  The URLs you 
cited contain the improvements by Paul and me that I referred to.  I 
should have said that.

The most recent version of the patch is in

  http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00720.html

in which Paul says, "And there's more where this came from -- that code 
is pretty crufty...."

So I don't know if that patch should just be applied now or if Paul 
plans to do more cleanup.

Ken

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: dan.colascione <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
	Paul Eggert <eggert <at> cs.ucla.edu>, schwab <at> linux-m68k.org,
	9119 <at> debbugs.gnu.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Sat, 14 Apr 2012 13:21:56 +0200

Ken Brown <kbrown <at> cornell.edu> writes:

> The most recent version of the patch is in
>
>   http://lists.gnu.org/archive/html/emacs-devel/2011-12/msg00720.html
>
> in which Paul says, "And there's more where this came from -- that
> code is pretty crufty...."

And again, patch complains about this, too, being invalid:

patching file src/gmalloc.c
patch: **** malformed patch at line 145: @@ -473,9 +444,8 @@

Perhaps Paul can just apply his changes directly...

-- 
(domestic pets only, the antidote for overdose, milk.)
  http://lars.ingebrigtsen.no  *  Sent from my Rome

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

From: Chong Yidong <cyd <at> gnu.org>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: dan.colascione <at> gmail.com, 9119 <at> debbugs.gnu.org,
	Paul Eggert <eggert <at> cs.ucla.edu>, schwab <at> linux-m68k.org,
	Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Sat, 14 Apr 2012 21:38:56 +0800

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> And again, patch complains about this, too, being invalid:
>
> patching file src/gmalloc.c
> patch: **** malformed patch at line 145: @@ -473,9 +444,8 @@

How the heck does that happen anyway?

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> gnu.org>
Cc: dan.colascione <at> gmail.com, larsi <at> gnus.org, eggert <at> cs.ucla.edu,
	schwab <at> linux-m68k.org, 9119 <at> debbugs.gnu.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Sat, 14 Apr 2012 17:46:51 +0300

> From: Chong Yidong <cyd <at> gnu.org>
> Date: Sat, 14 Apr 2012 21:38:56 +0800
> Cc: schwab <at> linux-m68k.org, 9119 <at> debbugs.gnu.org,
> 	Paul Eggert <eggert <at> cs.ucla.edu>, dan.colascione <at> gmail.com
> 
> Lars Ingebrigtsen <larsi <at> gnus.org> writes:
> 
> > And again, patch complains about this, too, being invalid:
> >
> > patching file src/gmalloc.c
> > patch: **** malformed patch at line 145: @@ -473,9 +444,8 @@
> 
> How the heck does that happen anyway?

Manual editing of the diffs?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: dan.colascione <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
	schwab <at> linux-m68k.org, 9119 <at> debbugs.gnu.org, Ken Brown <kbrown <at> cornell.edu>
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Mon, 16 Apr 2012 00:23:54 -0700

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

On 04/14/2012 04:21 AM, Lars Ingebrigtsen wrote:
> Perhaps Paul can just apply his changes directly...

I installed the non-tricky parts into the trunk,
in bzrs 107916 through 107919.
The gmalloc.c part remains.  Attached is a more up-to-date
version of the remaining part, with some more stuff added
that we've already talked about (e.g., replacing __malloc_size_t
with size_t) and some of the iffier stuff removed
(e.g., removing valloc).

I'd like to test it a bit more internally, before
installing it on the trunk.  The testing is a bit
tricky since the current Emacs trunk fails the
GC_MALLOC_CHECK tests on a "make bootstrap" when
using gmalloc.c.  I don't know if that is a longstanding
problem that can't easily be fixed, or what...

[gmalloc-diff.txt (text/plain, attachment)]

Message #52 received at 9119-done <at> debbugs.gnu.org (full text, mbox):

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Ken Brown <kbrown <at> cornell.edu>
Cc: dan.colascione <at> gmail.com, Eli Zaretskii <eliz <at> gnu.org>,
	schwab <at> linux-m68k.org, larsi <at> gnus.org, 9119-done <at> debbugs.gnu.org
Subject: Re: bug#9119: [PATCH] modernize function definitions in gmalloc.c
Date: Sun, 22 Apr 2012 12:27:56 -0700

On 04/14/2012 04:15 AM, Ken Brown wrote:
> So I don't know if that patch should just be applied now
> or if Paul plans to do more cleanup.

I just now applied a slightly-updated version of the last
patch that I suggested in this thread, into the trunk as
bzr 107999, and I'm marking this as done.  The code is
still pretty crufty and I'm sure it still has bugs on some
platforms but someone who regularly debugs on those
platforms would need to look at it.

Previous Next

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