unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* md5 broken?
@ 2011-05-28  9:32 Antoine Levitt
  2011-05-28 12:23 ` Jim Meyering
  0 siblings, 1 reply; 16+ messages in thread
From: Antoine Levitt @ 2011-05-28  9:32 UTC (permalink / raw)
  To: emacs-devel

Hi,

I've got this code, that hashes ERC nicks to get a color (the same every
time) for every nick.

(defun erc-get-color-for-nick (nick)
  "Gets a color for NICK. If NICK is specified
  in erc-nick-color-alist, use it, else hash
  the nick and get a color from that"
  (or (cdr (assoc nick erc-nick-color-alist))
      (nth
       (mod (string-to-number
	     (substring (md5 nick) 0 6) 16)
	    (length erc-colors-list))
       erc-colors-list)))

Recently (between yesterday and today), some colors have changed.

From an emacs compiled 2011-05-26 13:47 (GMT+1) (just the binary, with
same elisp),

(md5 "truc")
=> 45723a2af3788c4ff17f8d1114760e62
(which is the same thing as md5sum)

From an emacs just compiled,

(md5 "truc")
=> 45723a2aff78ff4fff7fff1114760e62
(it seems some digits have been randomly replaced by f, for some reason)

The only likely culprit I can see is the integer overflow fixes:

revno: 104390 [merge]
committer: Paul Eggert <eggert@cs.ucla.edu>
timestamp: Fri 2011-05-27 13:32:41 -0700
  Merge: Integer overflow fixes.

Could someone look into that, please? I'm on x86-64 by the way.




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28  9:32 md5 broken? Antoine Levitt
@ 2011-05-28 12:23 ` Jim Meyering
  2011-05-28 12:28   ` Antoine Levitt
  2011-05-28 12:51   ` Eli Zaretskii
  0 siblings, 2 replies; 16+ messages in thread
From: Jim Meyering @ 2011-05-28 12:23 UTC (permalink / raw)
  To: Antoine Levitt; +Cc: Paul Eggert, emacs-devel

Antoine Levitt wrote:
...
> (md5 "truc")
> => 45723a2af3788c4ff17f8d1114760e62
> (which is the same thing as md5sum)
>
>>From an emacs just compiled,
>
> (md5 "truc")
> => 45723a2aff78ff4fff7fff1114760e62
> (it seems some digits have been randomly replaced by f, for some reason)
...

Thanks for the report.
That was due to yesterday's crypto_hash_function change.
It switched from unsigned to signed char pointers.
The patch below fixes it by introducing the tiny "to_uchar" function
from coreutils/src/system.h.  It's safer to use a tiny helper
function like that rather than a cast.

I fixed it with this:

2011-05-28  Jim Meyering  <meyering@redhat.com>

	avoid a sign-extension bug in crypto_hash_function
	* fns.c (to_uchar): Define.
	(crypto_hash_function): Use it to convert some newly-signed
	variables to unsigned, to avoid sign-extension bugs.  For example,
	without this change, (md5 "truc") would evaluate to
	45723a2aff78ff4fff7fff1114760e62 rather than the expected
	45723a2af3788c4ff17f8d1114760e62.  Reported by Antoine Levitt in
	http://thread.gmane.org/gmane.emacs.devel/139824


=== modified file 'src/fns.c'
--- src/fns.c	2011-05-27 19:37:32 +0000
+++ src/fns.c	2011-05-28 12:09:59 +0000
@@ -4520,6 +4520,11 @@
 #include "md5.h"
 #include "sha1.h"

+/* Convert a possibly-signed character to an unsigned character.  This is
+   a bit safer than casting to unsigned char, since it catches some type
+   errors that the cast doesn't.  */
+static inline unsigned char to_uchar (char ch) { return ch; }
+
 /* TYPE: 0 for md5, 1 for sha1. */

 static Lisp_Object
@@ -4717,7 +4722,7 @@
 	  {
 	    char value[33];
 	    for (i = 0; i < 16; i++)
-	      sprintf (&value[2 * i], "%02x", digest[i]);
+	      sprintf (&value[2 * i], "%02x", to_uchar (digest[i]));
 	    res = make_string (value, 32);
 	  }
 	else
@@ -4735,7 +4740,7 @@
 	  {
 	    char value[41];
 	    for (i = 0; i < 20; i++)
-	      sprintf (&value[2 * i], "%02x", digest[i]);
+	      sprintf (&value[2 * i], "%02x", to_uchar (digest[i]));
 	    res = make_string (value, 40);
 	  }
 	else



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28 12:23 ` Jim Meyering
@ 2011-05-28 12:28   ` Antoine Levitt
  2011-05-28 12:51   ` Eli Zaretskii
  1 sibling, 0 replies; 16+ messages in thread
From: Antoine Levitt @ 2011-05-28 12:28 UTC (permalink / raw)
  To: Jim Meyering; +Cc: Paul Eggert, emacs-devel

28/05/11 14:23, Jim Meyering
> Antoine Levitt wrote:
> ...
>> (md5 "truc")
>> => 45723a2af3788c4ff17f8d1114760e62
>> (which is the same thing as md5sum)
>>
>>>From an emacs just compiled,
>>
>> (md5 "truc")
>> => 45723a2aff78ff4fff7fff1114760e62
>> (it seems some digits have been randomly replaced by f, for some reason)
> ...
>
> Thanks for the report.
> That was due to yesterday's crypto_hash_function change.
> It switched from unsigned to signed char pointers.
> The patch below fixes it by introducing the tiny "to_uchar" function
> from coreutils/src/system.h.  It's safer to use a tiny helper
> function like that rather than a cast.
>
> I fixed it with this:
>
> 2011-05-28  Jim Meyering  <meyering@redhat.com>
>
> 	avoid a sign-extension bug in crypto_hash_function
> 	* fns.c (to_uchar): Define.
> 	(crypto_hash_function): Use it to convert some newly-signed
> 	variables to unsigned, to avoid sign-extension bugs.  For example,
> 	without this change, (md5 "truc") would evaluate to
> 	45723a2aff78ff4fff7fff1114760e62 rather than the expected
> 	45723a2af3788c4ff17f8d1114760e62.  Reported by Antoine Levitt in
> 	http://thread.gmane.org/gmane.emacs.devel/139824

Thanks for the fix! Awesome that the word "truc" ("thingy" in french)
has made its way into the emacs Changelog ;)



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28 12:23 ` Jim Meyering
  2011-05-28 12:28   ` Antoine Levitt
@ 2011-05-28 12:51   ` Eli Zaretskii
  2011-05-28 13:32     ` Jim Meyering
  1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2011-05-28 12:51 UTC (permalink / raw)
  To: Jim Meyering; +Cc: eggert, emacs-devel, antoine.levitt

> From: Jim Meyering <jim@meyering.net>
> Date: Sat, 28 May 2011 14:23:43 +0200
> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org
> 
> +static inline unsigned char to_uchar (char ch) { return ch; }

I think this should use "INLINE", upper-cased, rather than "inline",
for those compilers that don't support the `inline' keyword.  See
src/config.in.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28 12:51   ` Eli Zaretskii
@ 2011-05-28 13:32     ` Jim Meyering
  2011-05-28 14:10       ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Jim Meyering @ 2011-05-28 13:32 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: eggert, emacs-devel, antoine.levitt

Eli Zaretskii wrote:
>> From: Jim Meyering <jim@meyering.net>
>> Date: Sat, 28 May 2011 14:23:43 +0200
>> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org
>>
>> +static inline unsigned char to_uchar (char ch) { return ch; }
>
> I think this should use "INLINE", upper-cased, rather than "inline",
> for those compilers that don't support the `inline' keyword.  See
> src/config.in.

Using "inline" is fine because of the configure-time test that
defines "inline" to nothing when it is not supported:

    $ grep -A4 to..__inline src/config.h                                         :
    /* Define to `__inline__' or `__inline' if that's what the C compiler
       calls it, or to nothing if 'inline' is not supported under any name.  */
    #ifndef __cplusplus
    /* #undef inline */
    #endif

There is one other use already:

    lread.c:2256:static inline int

There are far more uses of INLINE:

    $ git grep -w INLINE|grep -cw INLINE
    144

Is there any reason not to replace all uses of INLINE with "inline"
and to remove the following from configure.in?  I see no use of
"extern INLINE" anywhere in emacs:

    /* If using GNU, then support inline function declarations.  */
    /* Don't try to switch on inline handling as detected by AC_C_INLINE
       generally, because even if non-gcc compilers accept `inline', they
       may reject `extern inline'.  */
    #if defined (__GNUC__)
    #define INLINE __inline__
    #else
    #define INLINE
    #endif



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28 13:32     ` Jim Meyering
@ 2011-05-28 14:10       ` Eli Zaretskii
  2011-05-28 16:09         ` Paul Eggert
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2011-05-28 14:10 UTC (permalink / raw)
  To: Jim Meyering; +Cc: eggert, emacs-devel, antoine.levitt

> From: Jim Meyering <jim@meyering.net>
> Cc: antoine.levitt@gmail.com,  eggert@cs.ucla.edu,  emacs-devel@gnu.org
> Date: Sat, 28 May 2011 15:32:50 +0200
> 
> Eli Zaretskii wrote:
> >> From: Jim Meyering <jim@meyering.net>
> >> Date: Sat, 28 May 2011 14:23:43 +0200
> >> Cc: Paul Eggert <eggert@cs.ucla.edu>, emacs-devel@gnu.org
> >>
> >> +static inline unsigned char to_uchar (char ch) { return ch; }
> >
> > I think this should use "INLINE", upper-cased, rather than "inline",
> > for those compilers that don't support the `inline' keyword.  See
> > src/config.in.
> 
> Using "inline" is fine because of the configure-time test that
> defines "inline" to nothing when it is not supported:

You obviously assume that every supported build runs the `configure'
script.  But that is false, of course.

> There is one other use already:
> 
>     lread.c:2256:static inline int
> 
> There are far more uses of INLINE:
> 
>     $ git grep -w INLINE|grep -cw INLINE
>     144

Yes.  I believe Emacs used "INLINE" for far longer than "inline".

> Is there any reason not to replace all uses of INLINE with "inline"
> and to remove the following from configure.in?  I see no use of
> "extern INLINE" anywhere in emacs:

I don't know enough about the "extern INLINE" issue to answer that,
sorry.  But if it is decided to switch to "inline" everywhere, we
should make sure it works with all the supported builds, not only with
those that run `configure'.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28 14:10       ` Eli Zaretskii
@ 2011-05-28 16:09         ` Paul Eggert
  2011-05-28 16:55           ` Eli Zaretskii
  2011-05-30  2:47           ` md5 broken? Ken Raeburn
  0 siblings, 2 replies; 16+ messages in thread
From: Paul Eggert @ 2011-05-28 16:09 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, Jim Meyering, antoine.levitt

On 05/28/11 07:10, Eli Zaretskii wrote:
> if it is decided to switch to "inline" everywhere, we
> should make sure it works with all the supported builds, not only with
> those that run `configure'.

Plain 'inline' has been in use for over a month,
and it builds on MS-DOS (according to the log for
bzr 104154), so it does appear that it works with
all supported builds.

The "extern inline" issue is that C99 has a different
semantics for "extern inline" than GCC traditionally did.
As long as we stay away from "extern inline" we shouldn't
have to worry about that porting problem.  (This issue
applies equally to 'inline' and to 'INLINE'.)

By the way, thanks, Jim, for fixing the signed char bug
that I introduced.  I really should have caught that.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28 16:09         ` Paul Eggert
@ 2011-05-28 16:55           ` Eli Zaretskii
  2011-05-28 19:12             ` Paul Eggert
  2011-05-30  2:47           ` md5 broken? Ken Raeburn
  1 sibling, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2011-05-28 16:55 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel, jim, antoine.levitt

> Date: Sat, 28 May 2011 09:09:58 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: Jim Meyering <jim@meyering.net>, antoine.levitt@gmail.com, 
>  emacs-devel@gnu.org
> 
> On 05/28/11 07:10, Eli Zaretskii wrote:
> > if it is decided to switch to "inline" everywhere, we
> > should make sure it works with all the supported builds, not only with
> > those that run `configure'.
> 
> Plain 'inline' has been in use for over a month,
> and it builds on MS-DOS (according to the log for
> bzr 104154)

"Builds" is not enough.  We also want to assure that every compiler
that supports inline functions really sees the inline keyword there.

> so it does appear that it works with all supported builds.

There's also the Windows build, which still supports non-GCC
compilers.

> The "extern inline" issue is that C99 has a different
> semantics for "extern inline" than GCC traditionally did.
> As long as we stay away from "extern inline" we shouldn't
> have to worry about that porting problem.  (This issue
> applies equally to 'inline' and to 'INLINE'.)

I don't mind using either one, but I think we only need to use one,
not both.  Using both is a maintenance headache.  That's all I'm
saying.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28 16:55           ` Eli Zaretskii
@ 2011-05-28 19:12             ` Paul Eggert
  2011-05-28 19:35               ` Eli Zaretskii
  0 siblings, 1 reply; 16+ messages in thread
From: Paul Eggert @ 2011-05-28 19:12 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, jim, antoine.levitt

On 05/28/11 09:55, Eli Zaretskii wrote:
> "Builds" is not enough.  We also want to assure that every compiler
> that supports inline functions really sees the inline keyword there.

No, "#define inline /* empty */" is a perfectly adequate workaround.
This is the standard workaround on typical older hosts, and it
doesn't break anything, as the C Standard allows compilers to
ignore 'inline' entirely (on static functions, anyway, which is
what we're talking about here).

>> > so it does appear that it works with all supported builds.
> There's also the Windows build, which still supports non-GCC
> compilers.

Evidently it's not a significant problem with Windows, since it's been
in use for over a month without complaint.  If there turns
out to be a problem with some rarely-used ancient Windows compiler,
the Windows configuration file can just add a
"#define inline /* empty */" if that compiler is in use.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28 19:12             ` Paul Eggert
@ 2011-05-28 19:35               ` Eli Zaretskii
  2011-05-28 22:47                 ` INLINE -> inline (was: md5 broken?) Paul Eggert
  0 siblings, 1 reply; 16+ messages in thread
From: Eli Zaretskii @ 2011-05-28 19:35 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel, jim, antoine.levitt

> Date: Sat, 28 May 2011 12:12:19 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: jim@meyering.net, antoine.levitt@gmail.com, emacs-devel@gnu.org
> 
> On 05/28/11 09:55, Eli Zaretskii wrote:
> > "Builds" is not enough.  We also want to assure that every compiler
> > that supports inline functions really sees the inline keyword there.
> 
> No, "#define inline /* empty */" is a perfectly adequate workaround.

Not if wed want the result be a decent binary with reasonable
performance.  See bidi.c, for example.

> >> > so it does appear that it works with all supported builds.
> > There's also the Windows build, which still supports non-GCC
> > compilers.
> 
> Evidently it's not a significant problem with Windows, since it's been
> in use for over a month without complaint.

Yeah, and guess who took care of that.

But you are missing the point.  I'm saying that we should have only
one of "INLINE" and "inline", not both.  I don't care much which one;
I only mentioned the former because it is used widely in Emacs and for
a long time.

Is there any reasons to keep both?



^ permalink raw reply	[flat|nested] 16+ messages in thread

* INLINE -> inline (was: md5 broken?)
  2011-05-28 19:35               ` Eli Zaretskii
@ 2011-05-28 22:47                 ` Paul Eggert
  2011-05-29  4:51                   ` Eli Zaretskii
  2011-05-29  8:05                   ` INLINE -> inline Jim Meyering
  0 siblings, 2 replies; 16+ messages in thread
From: Paul Eggert @ 2011-05-28 22:47 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel, jim, antoine.levitt

On 05/28/11 12:35, Eli Zaretskii wrote:
> I'm saying that we should have only
> one of "INLINE" and "inline", not both.

Yes, that makes sense.  Since 'inline' is standard and is widely
used in other GNU packages, it makes sense to use it in Emacs too.
That will shorten the Emacs source code and make it easier for
others to understand.  Here's a proposed patch to do that.
I've tested it on Fedora 14 x86_64.

[ChangeLog]
Use 'inline', not 'INLINE'.
* configure.in, autogen/config.in (INLINE): Remove.
[lib-src/ChangeLog]
Use 'inline', not 'INLINE'.
* etags.c (hash): Now inline unconditionally.
* make-docfile.c (put_char): inline, not INLINE.
[nt/ChangeLog]
Use 'inline', not 'INLINE'.
* config.nt (INLINE): Remove.
[src/ChangeLog]
Use 'inline', not 'INLINE'.
* alloc.c, fontset.c (INLINE): Remove.
* alloc.c, bidi.c, charset.c, coding.c, dispnew.c, fns.c, image.c:
* intervals.c, keyboard.c, process.c, syntax.c, textprop.c, w32term.c:
* xdisp.c, xfaces.c, xterm.c: Replace all uses of INLINE with inline.
* gmalloc.c (register_heapinfo): Use inline unconditionally.
* lisp.h (LISP_MAKE_RVALUE): Use inline, not __inline__.
=== modified file 'autogen/config.in'
--- autogen/config.in	2011-05-20 00:42:04 +0000
+++ autogen/config.in	2011-05-28 21:23:53 +0000
@@ -1278,16 +1278,6 @@
 /* Turned on June 1996 supposing nobody will mind it.  */
 #define AMPERSAND_FULL_NAME

-/* If using GNU, then support inline function declarations.  */
-/* Don't try to switch on inline handling as detected by AC_C_INLINE
-   generally, because even if non-gcc compilers accept `inline', they
-   may reject `extern inline'.  */
-#if defined (__GNUC__)
-#define INLINE __inline__
-#else
-#define INLINE
-#endif
-
 /* `subprocesses' should be defined if you want to
    have code for asynchronous subprocesses
    (as used in M-x compile and M-x shell).
@@ -1438,4 +1428,3 @@
 mode: c
 End:
 */
-

=== modified file 'configure.in'
--- configure.in	2011-05-26 00:55:14 +0000
+++ configure.in	2011-05-28 21:59:11 +0000
@@ -1286,9 +1286,6 @@
 AC_C_PROTOTYPES
 AC_C_VOLATILE
 AC_C_CONST
-dnl This isn't useful because we can't turn on use of `inline' unless
-dnl the compiler groks `extern inline'.
-dnl AC_C_INLINE
 AC_CACHE_CHECK([for void * support], emacs_cv_void_star,
   [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([], [[void * foo;]])],
                    emacs_cv_void_star=yes, emacs_cv_void_star=no)])
@@ -3449,16 +3446,6 @@
 /* Turned on June 1996 supposing nobody will mind it.  */
 #define AMPERSAND_FULL_NAME

-/* If using GNU, then support inline function declarations.  */
-/* Don't try to switch on inline handling as detected by AC_C_INLINE
-   generally, because even if non-gcc compilers accept `inline', they
-   may reject `extern inline'.  */
-#if defined (__GNUC__)
-#define INLINE __inline__
-#else
-#define INLINE
-#endif
-
 /* `subprocesses' should be defined if you want to
    have code for asynchronous subprocesses
    (as used in M-x compile and M-x shell).

=== modified file 'lib-src/etags.c'
--- lib-src/etags.c	2011-05-21 02:27:00 +0000
+++ lib-src/etags.c	2011-05-28 22:01:45 +0000
@@ -2360,14 +2360,7 @@
 struct C_stab_entry { const char *name; int c_ext; enum sym_type type; };
 /* maximum key range = 33, duplicates = 0 */

-#ifdef __GNUC__
-__inline
-#else
-#ifdef __cplusplus
-inline
-#endif
-#endif
-static unsigned int
+static inline unsigned int
 hash (register const char *str, register unsigned int len)
 {
   static unsigned char asso_values[] =

=== modified file 'lib-src/make-docfile.c'
--- lib-src/make-docfile.c	2011-04-01 20:28:50 +0000
+++ lib-src/make-docfile.c	2011-05-28 21:27:52 +0000
@@ -291,7 +291,7 @@
 /* Output CH to the file or buffer in STATE.  Any pending newlines or
    spaces are output first.  */

-static INLINE void
+static inline void
 put_char (int ch, struct rcsoc_state *state)
 {
   int out_ch;

=== modified file 'nt/config.nt'
--- nt/config.nt	2011-05-09 13:35:56 +0000
+++ nt/config.nt	2011-05-28 21:27:20 +0000
@@ -362,14 +362,6 @@

 /* End of gnulib-related stuff.  */

-/* If using GNU, then support inline function declarations. */
-#ifdef __GNUC__
-#define INLINE __inline__
-#define inline __inline__
-#else
-#define INLINE
-#endif
-
 #if __GNUC__ >= 3  /* On GCC 3.0 we might get a warning.  */
 #define NO_INLINE __attribute__((noinline))
 #else

=== modified file 'src/alloc.c'
--- src/alloc.c	2011-05-23 00:31:35 +0000
+++ src/alloc.c	2011-05-28 21:52:17 +0000
@@ -22,10 +22,6 @@
 #include <limits.h>		/* For CHAR_BIT.  */
 #include <setjmp.h>

-#ifdef ALLOC_DEBUG
-#undef INLINE
-#endif
-
 #include <signal.h>

 #ifdef HAVE_GTK_AND_PTHREAD
@@ -408,7 +404,7 @@
 static void mem_rotate_right (struct mem_node *);
 static void mem_delete (struct mem_node *);
 static void mem_delete_fixup (struct mem_node *);
-static INLINE struct mem_node *mem_find (void *);
+static inline struct mem_node *mem_find (void *);


 #if GC_MARK_STACK == GC_MARK_STACK_CHECK_GCPROS
@@ -3376,7 +3372,7 @@
 /* Value is a pointer to the mem_node containing START.  Value is
    MEM_NIL if there is no node in the tree containing START.  */

-static INLINE struct mem_node *
+static inline struct mem_node *
 mem_find (void *start)
 {
   struct mem_node *p;
@@ -3752,7 +3748,7 @@
 /* Value is non-zero if P is a pointer to a live Lisp string on
    the heap.  M is a pointer to the mem_block for P.  */

-static INLINE int
+static inline int
 live_string_p (struct mem_node *m, void *p)
 {
   if (m->type == MEM_TYPE_STRING)
@@ -3775,7 +3771,7 @@
 /* Value is non-zero if P is a pointer to a live Lisp cons on
    the heap.  M is a pointer to the mem_block for P.  */

-static INLINE int
+static inline int
 live_cons_p (struct mem_node *m, void *p)
 {
   if (m->type == MEM_TYPE_CONS)
@@ -3801,7 +3797,7 @@
 /* Value is non-zero if P is a pointer to a live Lisp symbol on
    the heap.  M is a pointer to the mem_block for P.  */

-static INLINE int
+static inline int
 live_symbol_p (struct mem_node *m, void *p)
 {
   if (m->type == MEM_TYPE_SYMBOL)
@@ -3827,7 +3823,7 @@
 /* Value is non-zero if P is a pointer to a live Lisp float on
    the heap.  M is a pointer to the mem_block for P.  */

-static INLINE int
+static inline int
 live_float_p (struct mem_node *m, void *p)
 {
   if (m->type == MEM_TYPE_FLOAT)
@@ -3851,7 +3847,7 @@
 /* Value is non-zero if P is a pointer to a live Lisp Misc on
    the heap.  M is a pointer to the mem_block for P.  */

-static INLINE int
+static inline int
 live_misc_p (struct mem_node *m, void *p)
 {
   if (m->type == MEM_TYPE_MISC)
@@ -3877,7 +3873,7 @@
 /* Value is non-zero if P is a pointer to a live vector-like object.
    M is a pointer to the mem_block for P.  */

-static INLINE int
+static inline int
 live_vector_p (struct mem_node *m, void *p)
 {
   return (p == m->start && m->type == MEM_TYPE_VECTORLIKE);
@@ -3887,7 +3883,7 @@
 /* Value is non-zero if P is a pointer to a live buffer.  M is a
    pointer to the mem_block for P.  */

-static INLINE int
+static inline int
 live_buffer_p (struct mem_node *m, void *p)
 {
   /* P must point to the start of the block, and the buffer
@@ -3953,7 +3949,7 @@

 /* Mark OBJ if we can prove it's a Lisp_Object.  */

-static INLINE void
+static inline void
 mark_maybe_object (Lisp_Object obj)
 {
   void *po;
@@ -4022,7 +4018,7 @@
 /* If P points to Lisp data, mark that as live if it isn't already
    marked.  */

-static INLINE void
+static inline void
 mark_maybe_pointer (void *p)
 {
   struct mem_node *m;

=== modified file 'src/bidi.c'
--- src/bidi.c	2011-04-19 00:34:42 +0000
+++ src/bidi.c	2011-05-28 21:54:57 +0000
@@ -137,7 +137,7 @@

 /* Return the bidi type of a character CH, subject to the current
    directional OVERRIDE.  */
-static INLINE bidi_type_t
+static inline bidi_type_t
 bidi_get_type (int ch, bidi_dir_t override)
 {
   bidi_type_t default_type;
@@ -188,7 +188,7 @@
 }

 /* Given a bidi TYPE of a character, return its category.  */
-static INLINE bidi_category_t
+static inline bidi_category_t
 bidi_get_category (bidi_type_t type)
 {
   switch (type)
@@ -252,7 +252,7 @@

 /* Copy the bidi iterator from FROM to TO.  To save cycles, this only
    copies the part of the level stack that is actually in use.  */
-static INLINE void
+static inline void
 bidi_copy_it (struct bidi_it *to, struct bidi_it *from)
 {
   int i;
@@ -275,14 +275,14 @@
 static int bidi_cache_idx;	/* next unused cache slot */
 static int bidi_cache_last_idx;	/* slot of last cache hit */

-static INLINE void
+static inline void
 bidi_cache_reset (void)
 {
   bidi_cache_idx = 0;
   bidi_cache_last_idx = -1;
 }

-static INLINE void
+static inline void
 bidi_cache_shrink (void)
 {
   if (bidi_cache_size > BIDI_CACHE_CHUNK)
@@ -294,7 +294,7 @@
   bidi_cache_reset ();
 }

-static INLINE void
+static inline void
 bidi_cache_fetch_state (int idx, struct bidi_it *bidi_it)
 {
   int current_scan_dir = bidi_it->scan_dir;
@@ -311,7 +311,7 @@
    level less or equal to LEVEL.  if LEVEL is -1, disregard the
    resolved levels in cached states.  DIR, if non-zero, means search
    in that direction from the last cache hit.  */
-static INLINE int
+static inline int
 bidi_cache_search (EMACS_INT charpos, int level, int dir)
 {
   int i, i_start;
@@ -402,7 +402,7 @@
   return -1;
 }

-static INLINE void
+static inline void
 bidi_cache_iterator_state (struct bidi_it *bidi_it, int resolved)
 {
   int idx;
@@ -460,7 +460,7 @@
     bidi_cache_idx = idx + 1;
 }

-static INLINE bidi_type_t
+static inline bidi_type_t
 bidi_cache_find (EMACS_INT charpos, int level, struct bidi_it *bidi_it)
 {
   int i = bidi_cache_search (charpos, level, bidi_it->scan_dir);
@@ -480,7 +480,7 @@
   return UNKNOWN_BT;
 }

-static INLINE int
+static inline int
 bidi_peek_at_next_level (struct bidi_it *bidi_it)
 {
   if (bidi_cache_idx == 0 || bidi_cache_last_idx == -1)
@@ -519,7 +519,7 @@
    embedding levels on either side of the run boundary.  Also, update
    the saved info about previously seen characters, since that info is
    generally valid for a single level run.  */
-static INLINE void
+static inline void
 bidi_set_sor_type (struct bidi_it *bidi_it, int level_before, int level_after)
 {
   int higher_level = level_before > level_after ? level_before : level_after;
@@ -729,7 +729,7 @@

 /* Do whatever UAX#9 clause X8 says should be done at paragraph's
    end.  */
-static INLINE void
+static inline void
 bidi_set_paragraph_end (struct bidi_it *bidi_it)
 {
   bidi_it->invalid_levels = 0;
@@ -772,7 +772,7 @@

 /* Push the current embedding level and override status; reset the
    current level to LEVEL and the current override status to OVERRIDE.  */
-static INLINE void
+static inline void
 bidi_push_embedding_level (struct bidi_it *bidi_it,
 			   int level, bidi_dir_t override)
 {
@@ -785,7 +785,7 @@

 /* Pop the embedding level and directional override status from the
    stack, and return the new level.  */
-static INLINE int
+static inline int
 bidi_pop_embedding_level (struct bidi_it *bidi_it)
 {
   /* UAX#9 says to ignore invalid PDFs.  */
@@ -795,7 +795,7 @@
 }

 /* Record in SAVED_INFO the information about the current character.  */
-static INLINE void
+static inline void
 bidi_remember_char (struct bidi_saved_info *saved_info,
 		    struct bidi_it *bidi_it)
 {
@@ -811,7 +811,7 @@

 /* Resolve the type of a neutral character according to the type of
    surrounding strong text and the current embedding level.  */
-static INLINE bidi_type_t
+static inline bidi_type_t
 bidi_resolve_neutral_1 (bidi_type_t prev_type, bidi_type_t next_type, int lev)
 {
   /* N1: European and Arabic numbers are treated as though they were R.  */
@@ -828,7 +828,7 @@
     return STRONG_R;
 }

-static INLINE int
+static inline int
 bidi_explicit_dir_char (int c)
 {
   /* FIXME: this should be replaced with a lookup table with suitable

=== modified file 'src/charset.c'
--- src/charset.c	2011-05-01 16:27:34 +0000
+++ src/charset.c	2011-05-28 21:52:42 +0000
@@ -418,7 +418,7 @@
 /* Read a hexadecimal number (preceded by "0x") from the file FP while
    paying attention to comment character '#'.  */

-static INLINE unsigned
+static inline unsigned
 read_hex (FILE *fp, int *eof)
 {
   int c;

=== modified file 'src/coding.c'
--- src/coding.c	2011-05-12 07:07:06 +0000
+++ src/coding.c	2011-05-28 21:53:03 +0000
@@ -864,21 +864,21 @@
 static Lisp_Object get_translation_table (Lisp_Object, int, int *);
 static Lisp_Object get_translation (Lisp_Object, int *, int *);
 static int produce_chars (struct coding_system *, Lisp_Object, int);
-static INLINE void produce_charset (struct coding_system *, int *,
+static inline void produce_charset (struct coding_system *, int *,
                                     EMACS_INT);
 static void produce_annotation (struct coding_system *, EMACS_INT);
 static int decode_coding (struct coding_system *);
-static INLINE int *handle_composition_annotation (EMACS_INT, EMACS_INT,
+static inline int *handle_composition_annotation (EMACS_INT, EMACS_INT,
                                                   struct coding_system *,
                                                   int *, EMACS_INT *);
-static INLINE int *handle_charset_annotation (EMACS_INT, EMACS_INT,
+static inline int *handle_charset_annotation (EMACS_INT, EMACS_INT,
                                               struct coding_system *,
                                               int *, EMACS_INT *);
 static void consume_chars (struct coding_system *, Lisp_Object, int);
 static int encode_coding (struct coding_system *);
 static Lisp_Object make_conversion_work_buffer (int);
 static Lisp_Object code_conversion_restore (Lisp_Object);
-static INLINE int char_encodable_p (int, Lisp_Object);
+static inline int char_encodable_p (int, Lisp_Object);
 static Lisp_Object make_subsidiaries (Lisp_Object);

 static void
@@ -6829,7 +6829,7 @@
      [ -LENGTH ANNOTATION_MASK NCHARS NBYTES METHOD [ COMPONENTS... ] ]
  */

-static INLINE void
+static inline void
 produce_composition (struct coding_system *coding, int *charbuf, EMACS_INT pos)
 {
   int len;
@@ -6873,7 +6873,7 @@
      [ -LENGTH ANNOTATION_MASK NCHARS CHARSET-ID ]
  */

-static INLINE void
+static inline void
 produce_charset (struct coding_system *coding, int *charbuf, EMACS_INT pos)
 {
   EMACS_INT from = pos - charbuf[2];
@@ -7101,7 +7101,7 @@
    position of a composition after POS (if any) or to LIMIT, and
    return BUF.  */

-static INLINE int *
+static inline int *
 handle_composition_annotation (EMACS_INT pos, EMACS_INT limit,
 			       struct coding_system *coding, int *buf,
 			       EMACS_INT *stop)
@@ -7184,7 +7184,7 @@
    If the property value is nil, set *STOP to the position where the
    property value is non-nil (limiting by LIMIT), and return BUF.  */

-static INLINE int *
+static inline int *
 handle_charset_annotation (EMACS_INT pos, EMACS_INT limit,
 			   struct coding_system *coding, int *buf,
 			   EMACS_INT *stop)
@@ -8435,7 +8435,7 @@
 }


-static INLINE int
+static inline int
 char_encodable_p (int c, Lisp_Object attrs)
 {
   Lisp_Object tail;

=== modified file 'src/dispnew.c'
--- src/dispnew.c	2011-05-25 03:45:04 +0000
+++ src/dispnew.c	2011-05-28 21:28:13 +0000
@@ -1101,7 +1101,7 @@

 /* Exchange pointers to glyph memory between glyph rows A and B.  */

-static INLINE void
+static inline void
 swap_glyph_pointers (struct glyph_row *a, struct glyph_row *b)
 {
   int i;
@@ -1117,7 +1117,7 @@
 /* Copy glyph row structure FROM to glyph row structure TO, except
    that glyph pointers in the structures are left unchanged.  */

-static INLINE void
+static inline void
 copy_row_except_pointers (struct glyph_row *to, struct glyph_row *from)
 {
   struct glyph *pointers[1 + LAST_AREA];
@@ -1138,7 +1138,7 @@
    exchanged between TO and FROM.  Pointers must be exchanged to avoid
    a memory leak.  */

-static INLINE void
+static inline void
 assign_row (struct glyph_row *to, struct glyph_row *from)
 {
   swap_glyph_pointers (to, from);
@@ -1304,7 +1304,7 @@
    and B have equal contents.  MOUSE_FACE_P non-zero means compare the
    mouse_face_p flags of A and B, too.  */

-static INLINE int
+static inline int
 row_equal_p (struct glyph_row *a, struct glyph_row *b, int mouse_face_p)
 {
   if (a == b)
@@ -2729,7 +2729,7 @@
    function must be called before updates to make explicit that we are
    working on frame matrices or not.  */

-static INLINE void
+static inline void
 set_frame_matrix_frame (struct frame *f)
 {
   frame_matrix_frame = f;
@@ -2744,7 +2744,7 @@
    done in frame matrices, and that we have to perform analogous
    operations in window matrices of frame_matrix_frame.  */

-static INLINE void
+static inline void
 make_current (struct glyph_matrix *desired_matrix, struct glyph_matrix *current_matrix, int row)
 {
   struct glyph_row *current_row = MATRIX_ROW (current_matrix, row);
@@ -4246,7 +4246,7 @@

 /* Add glyph row ROW to the scrolling hash table.  */

-static INLINE struct row_entry *
+static inline struct row_entry *
 add_row_entry (struct glyph_row *row)
 {
   struct row_entry *entry;

=== modified file 'src/fns.c'
--- src/fns.c	2011-05-28 12:19:08 +0000
+++ src/fns.c	2011-05-28 21:55:19 +0000
@@ -3704,7 +3704,7 @@
 /* Resize hash table H if it's too full.  If H cannot be resized
    because it's already too large, throw an error.  */

-static INLINE void
+static inline void
 maybe_resize_hash_table (struct Lisp_Hash_Table *h)
 {
   if (NILP (h->next_free))

=== modified file 'src/fontset.c'
--- src/fontset.c	2011-04-14 05:04:02 +0000
+++ src/fontset.c	2011-05-28 21:54:36 +0000
@@ -58,8 +58,6 @@
 #undef xassert
 #ifdef FONTSET_DEBUG
 #define xassert(X)	do {if (!(X)) abort ();} while (0)
-#undef INLINE
-#define INLINE
 #else   /* not FONTSET_DEBUG */
 #define xassert(X)	(void) 0
 #endif	/* not FONTSET_DEBUG */

=== modified file 'src/gmalloc.c'
--- src/gmalloc.c	2011-01-17 19:01:01 +0000
+++ src/gmalloc.c	2011-05-28 22:33:33 +0000
@@ -552,12 +552,8 @@
 /* This is called when `_heapinfo' and `heapsize' have just
    been set to describe a new info table.  Set up the table
    to describe itself and account for it in the statistics.  */
-static void register_heapinfo PP ((void));
-#ifdef __GNUC__
-__inline__
-#endif
-static void
-register_heapinfo ()
+static inline void
+register_heapinfo (void)
 {
   __malloc_size_t block, blocks;

@@ -2170,4 +2166,3 @@
 }

 #endif /* GC_MCHECK */
-

=== modified file 'src/image.c'
--- src/image.c	2011-05-15 17:17:44 +0000
+++ src/image.c	2011-05-28 21:52:50 +0000
@@ -623,7 +623,7 @@
 /* Look up image type SYMBOL, and return a pointer to its image_type
    structure.  Value is null if SYMBOL is not a known image type.  */

-static INLINE struct image_type *
+static inline struct image_type *
 lookup_image_type (Lisp_Object symbol)
 {
   struct image_type *type;

=== modified file 'src/intervals.c'
--- src/intervals.c	2011-04-20 08:30:52 +0000
+++ src/intervals.c	2011-05-28 21:51:01 +0000
@@ -313,7 +313,7 @@
      c		  c
 */

-static INLINE INTERVAL
+static inline INTERVAL
 rotate_right (INTERVAL interval)
 {
   INTERVAL i;
@@ -360,7 +360,7 @@
     c               c
 */

-static INLINE INTERVAL
+static inline INTERVAL
 rotate_left (INTERVAL interval)
 {
   INTERVAL i;
@@ -438,7 +438,7 @@
 /* Balance INTERVAL, potentially stuffing it back into its parent
    Lisp Object.  */

-static INLINE INTERVAL
+static inline INTERVAL
 balance_possible_root_interval (register INTERVAL interval)
 {
   Lisp_Object parent;
@@ -1427,7 +1427,7 @@
    at position START.  Addition or deletion is indicated by the sign
    of LENGTH.  */

-INLINE void
+inline void
 offset_intervals (struct buffer *buffer, EMACS_INT start, EMACS_INT length)
 {
   if (NULL_INTERVAL_P (BUF_INTERVALS (buffer)) || length == 0)
@@ -1883,7 +1883,7 @@
 /* Set point in BUFFER "temporarily" to CHARPOS, which corresponds to
    byte position BYTEPOS.  */

-INLINE void
+inline void
 temp_set_point_both (struct buffer *buffer,
 		     EMACS_INT charpos, EMACS_INT bytepos)
 {
@@ -1903,7 +1903,7 @@

 /* Set point "temporarily", without checking any text properties.  */

-INLINE void
+inline void
 temp_set_point (struct buffer *buffer, EMACS_INT charpos)
 {
   temp_set_point_both (buffer, charpos,
@@ -2392,7 +2392,7 @@

 /* Give STRING the properties of BUFFER from POSITION to LENGTH.  */

-INLINE void
+inline void
 copy_intervals_to_string (Lisp_Object string, struct buffer *buffer,
 			  EMACS_INT position, EMACS_INT length)
 {

=== modified file 'src/keyboard.c'
--- src/keyboard.c	2011-05-15 17:17:44 +0000
+++ src/keyboard.c	2011-05-28 21:55:13 +0000
@@ -3742,7 +3742,7 @@
 \f
 /* Clear input event EVENT.  */

-static INLINE void
+static inline void
 clear_event (struct input_event *event)
 {
   event->kind = NO_EVENT;

=== modified file 'src/lisp.h'
--- src/lisp.h	2011-05-22 07:12:24 +0000
+++ src/lisp.h	2011-05-28 22:32:52 +0000
@@ -317,7 +317,7 @@
 #endif /* WORDS_BIGENDIAN */

 #ifdef __GNUC__
-static __inline__ Lisp_Object
+static inline Lisp_Object
 LISP_MAKE_RVALUE (Lisp_Object o)
 {
     return o;

=== modified file 'src/process.c'
--- src/process.c	2011-05-12 07:07:06 +0000
+++ src/process.c	2011-05-28 21:54:16 +0000
@@ -4162,7 +4162,7 @@
    impossible to step through wait_reading_process_output.  */

 #ifndef select
-static INLINE int
+static inline int
 select_wrapper (int n, fd_set *rfd, fd_set *wfd, fd_set *xfd, struct timeval *tmo)
 {
   return select (n, rfd, wfd, xfd, tmo);

=== modified file 'src/syntax.c'
--- src/syntax.c	2011-05-12 07:07:06 +0000
+++ src/syntax.c	2011-05-28 21:55:06 +0000
@@ -367,7 +367,7 @@
 /* Return the bytepos one character before BYTEPOS.
    We assume that BYTEPOS is not at the start of the buffer.  */

-static INLINE EMACS_INT
+static inline EMACS_INT
 dec_bytepos (EMACS_INT bytepos)
 {
   if (NILP (BVAR (current_buffer, enable_multibyte_characters)))

=== modified file 'src/textprop.c'
--- src/textprop.c	2011-05-12 07:07:06 +0000
+++ src/textprop.c	2011-05-28 21:55:28 +0000
@@ -248,7 +248,7 @@
 /* Return nonzero if the plist of interval I has any of the
    properties of PLIST, regardless of their values.  */

-static INLINE int
+static inline int
 interval_has_some_properties (Lisp_Object plist, INTERVAL i)
 {
   register Lisp_Object tail1, tail2, sym;
@@ -270,7 +270,7 @@
 /* Return nonzero if the plist of interval I has any of the
    property names in LIST, regardless of their values.  */

-static INLINE int
+static inline int
 interval_has_some_properties_list (Lisp_Object list, INTERVAL i)
 {
   register Lisp_Object tail1, tail2, sym;
@@ -499,7 +499,7 @@
 /* Remove all properties from interval I.  Return non-zero
    if this changes the interval.  */

-static INLINE int
+static inline int
 erase_properties (INTERVAL i)
 {
   if (NILP (i->plist))

=== modified file 'src/w32term.c'
--- src/w32term.c	2011-05-12 07:07:06 +0000
+++ src/w32term.c	2011-05-28 21:52:34 +0000
@@ -1002,7 +1002,7 @@
    Faces to use in the mode line have already been computed when the
    matrix was built, so there isn't much to do, here.  */

-static INLINE void
+static inline void
 x_set_mode_line_face_gc (struct glyph_string *s)
 {
   s->gc = s->face->gc;
@@ -1013,7 +1013,7 @@
    S->stippled_p to a non-zero value if the face of S has a stipple
    pattern.  */

-static INLINE void
+static inline void
 x_set_glyph_string_gc (struct glyph_string *s)
 {
   PREPARE_FACE_FOR_DISPLAY (s->f, s->face);
@@ -1058,7 +1058,7 @@
 /* Set clipping for output of glyph string S.  S may be part of a mode
    line or menu if we don't have X toolkit support.  */

-static INLINE void
+static inline void
 x_set_glyph_string_clipping (struct glyph_string *s)
 {
   RECT *r = s->clip;
@@ -1128,7 +1128,7 @@

 /* Fill rectangle X, Y, W, H with background color of glyph string S.  */

-static INLINE void
+static inline void
 x_clear_glyph_string_rect (struct glyph_string *s,
 			   int x, int y, int w, int h)
 {

=== modified file 'src/xdisp.c'
--- src/xdisp.c	2011-05-25 03:45:04 +0000
+++ src/xdisp.c	2011-05-28 21:53:28 +0000
@@ -926,7 +926,7 @@

    This is the height of W minus the height of a mode line, if any.  */

-INLINE int
+inline int
 window_text_bottom_y (struct window *w)
 {
   int height = WINDOW_TOTAL_HEIGHT (w);
@@ -940,7 +940,7 @@
    means return the total width of W, not including fringes to
    the left and right of the window.  */

-INLINE int
+inline int
 window_box_width (struct window *w, int area)
 {
   int cols = XFASTINT (w->total_cols);
@@ -979,7 +979,7 @@
 /* Return the pixel height of the display area of window W, not
    including mode lines of W, if any.  */

-INLINE int
+inline int
 window_box_height (struct window *w)
 {
   struct frame *f = XFRAME (w->frame);
@@ -1026,7 +1026,7 @@
    area AREA of window W.  AREA < 0 means return the left edge of the
    whole window, to the right of the left fringe of W.  */

-INLINE int
+inline int
 window_box_left_offset (struct window *w, int area)
 {
   int x;
@@ -1058,7 +1058,7 @@
    area AREA of window W.  AREA < 0 means return the right edge of the
    whole window, to the left of the right fringe of W.  */

-INLINE int
+inline int
 window_box_right_offset (struct window *w, int area)
 {
   return window_box_left_offset (w, area) + window_box_width (w, area);
@@ -1068,7 +1068,7 @@
    area AREA of window W.  AREA < 0 means return the left edge of the
    whole window, to the right of the left fringe of W.  */

-INLINE int
+inline int
 window_box_left (struct window *w, int area)
 {
   struct frame *f = XFRAME (w->frame);
@@ -1088,7 +1088,7 @@
    area AREA of window W.  AREA < 0 means return the right edge of the
    whole window, to the left of the right fringe of W.  */

-INLINE int
+inline int
 window_box_right (struct window *w, int area)
 {
   return window_box_left (w, area) + window_box_width (w, area);
@@ -1101,7 +1101,7 @@
    coordinates of the upper-left corner of the box.  Return in
    *BOX_WIDTH, and *BOX_HEIGHT the pixel width and height of the box.  */

-INLINE void
+inline void
 window_box (struct window *w, int area, int *box_x, int *box_y,
 	    int *box_width, int *box_height)
 {
@@ -1128,7 +1128,7 @@
    *BOTTOM_RIGHT_Y the coordinates of the bottom-right corner of the
    box.  */

-static INLINE void
+static inline void
 window_box_edges (struct window *w, int area, int *top_left_x, int *top_left_y,
 		   int *bottom_right_x, int *bottom_right_y)
 {
@@ -1328,7 +1328,7 @@
    returns an invalid character.  If we find one, we return a `?', but
    with the length of the invalid character.  */

-static INLINE int
+static inline int
 string_char_and_length (const unsigned char *str, int *len)
 {
   int c;
@@ -1376,7 +1376,7 @@
 /* Value is the text position, i.e. character and byte position,
    for character position CHARPOS in STRING.  */

-static INLINE struct text_pos
+static inline struct text_pos
 string_pos (EMACS_INT charpos, Lisp_Object string)
 {
   struct text_pos pos;
@@ -11061,7 +11061,7 @@
    buffer position, END is given as a distance from Z.  Used in
    redisplay_internal for display optimization.  */

-static INLINE int
+static inline int
 text_outside_line_unchanged_p (struct window *w,
 			       EMACS_INT start, EMACS_INT end)
 {
@@ -11322,7 +11322,7 @@
 /* Reconsider the setting of B->clip_changed which is displayed
    in window W.  */

-static INLINE void
+static inline void
 reconsider_clip_changes (struct window *w, struct buffer *b)
 {
   if (b->clip_changed
@@ -12883,7 +12883,7 @@

    We assume that the window's buffer is really current.  */

-static INLINE struct text_pos
+static inline struct text_pos
 run_window_scroll_functions (Lisp_Object window, struct text_pos startp)
 {
   struct window *w = XWINDOW (window);
@@ -20417,7 +20417,7 @@
 /* Append the list of glyph strings with head H and tail T to the list
    with head *HEAD and tail *TAIL.  Set *HEAD and *TAIL to the result.  */

-static INLINE void
+static inline void
 append_glyph_string_lists (struct glyph_string **head, struct glyph_string **tail,
 			   struct glyph_string *h, struct glyph_string *t)
 {
@@ -20437,7 +20437,7 @@
    list with head *HEAD and tail *TAIL.  Set *HEAD and *TAIL to the
    result.  */

-static INLINE void
+static inline void
 prepend_glyph_string_lists (struct glyph_string **head, struct glyph_string **tail,
 			    struct glyph_string *h, struct glyph_string *t)
 {
@@ -20456,7 +20456,7 @@
 /* Append glyph string S to the list with head *HEAD and tail *TAIL.
    Set *HEAD and *TAIL to the resulting list.  */

-static INLINE void
+static inline void
 append_glyph_string (struct glyph_string **head, struct glyph_string **tail,
 		     struct glyph_string *s)
 {
@@ -20471,7 +20471,7 @@
    Value is a pointer to a realized face that is ready for display if
    DISPLAY_P is non-zero.  */

-static INLINE struct face *
+static inline struct face *
 get_char_face_and_encoding (struct frame *f, int c, int face_id,
 			    XChar2b *char2b, int display_p)
 {
@@ -20504,7 +20504,7 @@
    The encoding of GLYPH->u.ch is returned in *CHAR2B.  Value is
    a pointer to a realized face that is ready for display.  */

-static INLINE struct face *
+static inline struct face *
 get_glyph_face_and_encoding (struct frame *f, struct glyph *glyph,
 			     XChar2b *char2b, int *two_byte_p)
 {
@@ -20541,7 +20541,7 @@
 /* Get glyph code of character C in FONT in the two-byte form CHAR2B.
    Retunr 1 if FONT has a glyph for C, otherwise return 0.  */

-static INLINE int
+static inline int
 get_char_glyph_code (int c, struct font *font, XChar2b *char2b)
 {
   unsigned code;
@@ -21005,7 +21005,7 @@
    first glyph following S.  LAST_X is the right-most x-position + 1
    in the drawing area.  */

-static INLINE void
+static inline void
 set_glyph_string_background_width (struct glyph_string *s, int start, int last_x)
 {
   /* If the face of this glyph string has to be drawn to the end of
@@ -21567,7 +21567,7 @@
 /* Store one glyph for IT->char_to_display in IT->glyph_row.
    Called from x_produce_glyphs when IT->glyph_row is non-null.  */

-static INLINE void
+static inline void
 append_glyph (struct it *it)
 {
   struct glyph *glyph;
@@ -21641,7 +21641,7 @@
    IT->glyph_row.  Called from x_produce_glyphs when IT->glyph_row is
    non-null.  */

-static INLINE void
+static inline void
 append_composite_glyph (struct it *it)
 {
   struct glyph *glyph;
@@ -21710,7 +21710,7 @@
 /* Change IT->ascent and IT->height according to the setting of
    IT->voffset.  */

-static INLINE void
+static inline void
 take_vertical_position_into_account (struct it *it)
 {
   if (it->voffset)

=== modified file 'src/xfaces.c'
--- src/xfaces.c	2011-05-12 07:07:06 +0000
+++ src/xfaces.c	2011-05-28 21:27:51 +0000
@@ -646,7 +646,7 @@
 /* Create and return a GC for use on frame F.  GC values and mask
    are given by XGCV and MASK.  */

-static INLINE GC
+static inline GC
 x_create_gc (struct frame *f, long unsigned int mask, XGCValues *xgcv)
 {
   GC gc;
@@ -660,7 +660,7 @@

 /* Free GC which was used on frame F.  */

-static INLINE void
+static inline void
 x_free_gc (struct frame *f, GC gc)
 {
   eassert (interrupt_input_blocked);
@@ -673,7 +673,7 @@
 #ifdef WINDOWSNT
 /* W32 emulation of GCs */

-static INLINE GC
+static inline GC
 x_create_gc (struct frame *f, unsigned long mask, XGCValues *xgcv)
 {
   GC gc;
@@ -687,7 +687,7 @@

 /* Free GC which was used on frame F.  */

-static INLINE void
+static inline void
 x_free_gc (struct frame *f, GC gc)
 {
   IF_DEBUG (xassert (--ngcs >= 0));
@@ -699,7 +699,7 @@
 #ifdef HAVE_NS
 /* NS emulation of GCs */

-static INLINE GC
+static inline GC
 x_create_gc (struct frame *f,
              unsigned long mask,
              XGCValues *xgcv)
@@ -710,7 +710,7 @@
   return gc;
 }

-static INLINE void
+static inline void
 x_free_gc (struct frame *f, GC gc)
 {
   xfree (gc);
@@ -746,7 +746,7 @@
    CHECK_LIVE_FRAME.  This is here because it's a frequent pattern in
    Lisp function definitions.  */

-static INLINE struct frame *
+static inline struct frame *
 frame_or_selected_frame (Lisp_Object frame, int nparam)
 {
   if (NILP (frame))
@@ -1976,7 +1976,7 @@
    FACE_NAME and NAMED_MERGE_POINT_KIND, as the head of the linked list
    pointed to by NAMED_MERGE_POINTS, and return 1.  */

-static INLINE int
+static inline int
 push_named_merge_point (struct named_merge_point *new_named_merge_point,
 			Lisp_Object face_name,
 			enum named_merge_point_kind named_merge_point_kind,
@@ -2078,7 +2078,7 @@
    face text properties; Ediff uses that).  If SIGNAL_P is non-zero,
    signal an error if FACE_NAME is not a valid face name.  If SIGNAL_P
    is zero, value is nil if FACE_NAME is not a valid face name.  */
-static INLINE Lisp_Object
+static inline Lisp_Object
 lface_from_face_name_no_resolve (struct frame *f, Lisp_Object face_name, int signal_p)
 {
   Lisp_Object lface;
@@ -2106,7 +2106,7 @@
    non-zero, signal an error if FACE_NAME is not a valid face name.
    If SIGNAL_P is zero, value is nil if FACE_NAME is not a valid face
    name.  */
-static INLINE Lisp_Object
+static inline Lisp_Object
 lface_from_face_name (struct frame *f, Lisp_Object face_name, int signal_p)
 {
   face_name = resolve_face_name (face_name, signal_p);
@@ -2120,7 +2120,7 @@
    is non-zero, signal an error if FACE_NAME does not name a face.
    Otherwise, value is zero if FACE_NAME is not a face.  */

-static INLINE int
+static inline int
 get_lface_attributes_no_remap (struct frame *f, Lisp_Object face_name, Lisp_Object *attrs, int signal_p)
 {
   Lisp_Object lface;
@@ -2141,7 +2141,7 @@
    non-zero, signal an error if FACE_NAME does not name a face.
    Otherwise, value is zero if FACE_NAME is not a face.  */

-static INLINE int
+static inline int
 get_lface_attributes (struct frame *f, Lisp_Object face_name, Lisp_Object *attrs, int signal_p, struct named_merge_point *named_merge_points)
 {
   Lisp_Object face_remapping;
@@ -2307,7 +2307,7 @@
    loops in face inheritance/remapping; it should be 0 when called from
    other places.  */

-static INLINE void
+static inline void
 merge_face_vectors (struct frame *f, Lisp_Object *from, Lisp_Object *to, struct named_merge_point *named_merge_points)
 {
   int i;
@@ -3903,7 +3903,7 @@
    all attributes are `equal'.  Tries to be fast because this function
    is called quite often.  */

-static INLINE int
+static inline int
 face_attr_equal_p (Lisp_Object v1, Lisp_Object v2)
 {
   /* Type can differ, e.g. when one attribute is unspecified, i.e. nil,
@@ -3936,7 +3936,7 @@
    all attributes are `equal'.  Tries to be fast because this function
    is called quite often.  */

-static INLINE int
+static inline int
 lface_equal_p (Lisp_Object *v1, Lisp_Object *v2)
 {
   int i, equal_p = 1;
@@ -4021,7 +4021,7 @@
 /* Return a hash code for Lisp string STRING with case ignored.  Used
    below in computing a hash value for a Lisp face.  */

-static INLINE unsigned
+static inline unsigned
 hash_string_case_insensitive (Lisp_Object string)
 {
   const unsigned char *s;
@@ -4035,7 +4035,7 @@

 /* Return a hash code for face attribute vector V.  */

-static INLINE unsigned
+static inline unsigned
 lface_hash (Lisp_Object *v)
 {
   return (hash_string_case_insensitive (v[LFACE_FAMILY_INDEX])
@@ -4054,7 +4054,7 @@
    family, point size, weight, width, slant, and font.  Both
    LFACE1 and LFACE2 must be fully-specified.  */

-static INLINE int
+static inline int
 lface_same_font_attributes_p (Lisp_Object *lface1, Lisp_Object *lface2)
 {
   xassert (lface_fully_specified_p (lface1)
@@ -4460,7 +4460,7 @@
    Value is the ID of the face found.  If no suitable face is found,
    realize a new one.  */

-static INLINE int
+static inline int
 lookup_face (struct frame *f, Lisp_Object *attr)
 {
   struct face_cache *cache = FRAME_FACE_CACHE (f);

=== modified file 'src/xterm.c'
--- src/xterm.c	2011-05-27 16:17:59 +0000
+++ src/xterm.c	2011-05-28 21:53:44 +0000
@@ -1010,7 +1010,7 @@
    Faces to use in the mode line have already been computed when the
    matrix was built, so there isn't much to do, here.  */

-static INLINE void
+static inline void
 x_set_mode_line_face_gc (struct glyph_string *s)
 {
   s->gc = s->face->gc;
@@ -1021,7 +1021,7 @@
    S->stippled_p to a non-zero value if the face of S has a stipple
    pattern.  */

-static INLINE void
+static inline void
 x_set_glyph_string_gc (struct glyph_string *s)
 {
   PREPARE_FACE_FOR_DISPLAY (s->f, s->face);
@@ -1066,7 +1066,7 @@
 /* Set clipping for output of glyph string S.  S may be part of a mode
    line or menu if we don't have X toolkit support.  */

-static INLINE void
+static inline void
 x_set_glyph_string_clipping (struct glyph_string *s)
 {
   XRectangle *r = s->clip;
@@ -1139,7 +1139,7 @@

 /* Fill rectangle X, Y, W, H with background color of glyph string S.  */

-static INLINE void
+static inline void
 x_clear_glyph_string_rect (struct glyph_string *s, int x, int y, int w, int h)
 {
   XGCValues xgcv;




^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: INLINE -> inline (was: md5 broken?)
  2011-05-28 22:47                 ` INLINE -> inline (was: md5 broken?) Paul Eggert
@ 2011-05-29  4:51                   ` Eli Zaretskii
  2011-05-29  8:05                   ` INLINE -> inline Jim Meyering
  1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2011-05-29  4:51 UTC (permalink / raw)
  To: Paul Eggert; +Cc: emacs-devel, jim, antoine.levitt

> Date: Sat, 28 May 2011 15:47:13 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: jim@meyering.net, antoine.levitt@gmail.com, emacs-devel@gnu.org
> 
> On 05/28/11 12:35, Eli Zaretskii wrote:
> > I'm saying that we should have only
> > one of "INLINE" and "inline", not both.
> 
> Yes, that makes sense.  Since 'inline' is standard and is widely
> used in other GNU packages, it makes sense to use it in Emacs too.
> That will shorten the Emacs source code and make it easier for
> others to understand.  Here's a proposed patch to do that.

Looks good to me, thanks.



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: INLINE -> inline
  2011-05-28 22:47                 ` INLINE -> inline (was: md5 broken?) Paul Eggert
  2011-05-29  4:51                   ` Eli Zaretskii
@ 2011-05-29  8:05                   ` Jim Meyering
  1 sibling, 0 replies; 16+ messages in thread
From: Jim Meyering @ 2011-05-29  8:05 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Eli Zaretskii, emacs-devel, antoine.levitt

Paul Eggert wrote:
> On 05/28/11 12:35, Eli Zaretskii wrote:
>> I'm saying that we should have only
>> one of "INLINE" and "inline", not both.
>
> Yes, that makes sense.  Since 'inline' is standard and is widely
> used in other GNU packages, it makes sense to use it in Emacs too.
> That will shorten the Emacs source code and make it easier for
> others to understand.  Here's a proposed patch to do that.
> I've tested it on Fedora 14 x86_64.

Nice.  I wrote nearly the same patch, but prefer yours for the additional
changes like this and the ones in gmalloc.c and lisp.h that further
normalize __inline and __inline__ to inline and remove those ifdefs.

> === modified file 'lib-src/etags.c'
> --- lib-src/etags.c	2011-05-21 02:27:00 +0000
> +++ lib-src/etags.c	2011-05-28 22:01:45 +0000
> @@ -2360,14 +2360,7 @@
>  struct C_stab_entry { const char *name; int c_ext; enum sym_type type; };
>  /* maximum key range = 33, duplicates = 0 */
>
> -#ifdef __GNUC__
> -__inline
> -#else
> -#ifdef __cplusplus
> -inline
> -#endif
> -#endif
> -static unsigned int
> +static inline unsigned int
>  hash (register const char *str, register unsigned int len)
>  {
>    static unsigned char asso_values[] =



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-28 16:09         ` Paul Eggert
  2011-05-28 16:55           ` Eli Zaretskii
@ 2011-05-30  2:47           ` Ken Raeburn
  2011-05-30  5:31             ` Paul Eggert
  1 sibling, 1 reply; 16+ messages in thread
From: Ken Raeburn @ 2011-05-30  2:47 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Eli Zaretskii, antoine.levitt, Jim Meyering, emacs-devel

On May 28, 2011, at 12:09, Paul Eggert wrote:
> The "extern inline" issue is that C99 has a different
> semantics for "extern inline" than GCC traditionally did.
> As long as we stay away from "extern inline" we shouldn't
> have to worry about that porting problem.  (This issue
> applies equally to 'inline' and to 'INLINE'.)

My understanding is that the traditional GCC and C99 interpretations for "inline" and "extern inline" are basically reversed.  So "inline" is just as much a problem as "extern inline" -- although we seem to have been getting away with "inline" for a while in intervals.c and elsewhere (unless we're defining it away on more platforms than I would hope necessary).  Even so, I generally consider "static inline" to be the only safe form, unless you want to jump through hoops to figure out or force the interpretation of "inline" or "extern inline" with your particular compiler.

Ken


^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-30  2:47           ` md5 broken? Ken Raeburn
@ 2011-05-30  5:31             ` Paul Eggert
  2011-05-31  4:22               ` Ken Raeburn
  0 siblings, 1 reply; 16+ messages in thread
From: Paul Eggert @ 2011-05-30  5:31 UTC (permalink / raw)
  To: Ken Raeburn; +Cc: Eli Zaretskii, antoine.levitt, Jim Meyering, emacs-devel

On 05/29/11 19:47, Ken Raeburn wrote:
> My understanding is that the traditional GCC and C99 interpretations
> for "inline" and "extern inline" are basically reversed.

Although the two interpretations of "inline" are different, Emacs
sticks to the intersection of the two, so it should be OK.

One part of this intersection is "static inline".  Another part
is when a function is first declared without "inline" and then
defined with "inline".  Emacs always done one or the other;
otherwise its current use of "INLINE" wouldn't be safe.

Here's where this is documented:

http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Inline.html



^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: md5 broken?
  2011-05-30  5:31             ` Paul Eggert
@ 2011-05-31  4:22               ` Ken Raeburn
  0 siblings, 0 replies; 16+ messages in thread
From: Ken Raeburn @ 2011-05-31  4:22 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Emacs Dev

On May 30, 2011, at 01:31, Paul Eggert wrote:
>   Another part
> is when a function is first declared without "inline" and then
> defined with "inline".  Emacs always done one or the other;
> otherwise its current use of "INLINE" wouldn't be safe.
> 
> Here's where this is documented:
> 
> http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/Inline.html

Ah, interesting.  I hadn't known about the second case.  I'll have to look at that a little more closely.  Thanks!

Ken


^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2011-05-31  4:22 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-05-28  9:32 md5 broken? Antoine Levitt
2011-05-28 12:23 ` Jim Meyering
2011-05-28 12:28   ` Antoine Levitt
2011-05-28 12:51   ` Eli Zaretskii
2011-05-28 13:32     ` Jim Meyering
2011-05-28 14:10       ` Eli Zaretskii
2011-05-28 16:09         ` Paul Eggert
2011-05-28 16:55           ` Eli Zaretskii
2011-05-28 19:12             ` Paul Eggert
2011-05-28 19:35               ` Eli Zaretskii
2011-05-28 22:47                 ` INLINE -> inline (was: md5 broken?) Paul Eggert
2011-05-29  4:51                   ` Eli Zaretskii
2011-05-29  8:05                   ` INLINE -> inline Jim Meyering
2011-05-30  2:47           ` md5 broken? Ken Raeburn
2011-05-30  5:31             ` Paul Eggert
2011-05-31  4:22               ` Ken Raeburn

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).