* 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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.