GNU bug report logs - #15880
Compute C declarations for DEFSYMs automatically.

Previous Next

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

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

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Emacs bugs <bug-gnu-emacs <at> gnu.org>
Subject: Compute C declarations for DEFSYMs automatically.
Date: Tue, 12 Nov 2013 16:33:56 -0800

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

Tags: patch

Attached is a first cut to implement something along the lines
that Stefan has been suggesting for a while, namely, to compute
declarations for DEFSYM variables automatically.  This should
help avoid needless clutter in the C code and silly errors involving
mismatched decls etc.  This version is tested on Fedora 19 x86-64
and Solaris 10 sparc-32.  I plan to do a bit more testing before
installing it.  I don't know of any reason it wouldn't work with
Microsoft platforms but I'm no expert there.

[DEFSYM.diff (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 05:54:47 +0200

> Date: Tue, 12 Nov 2013 16:33:56 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
>  globals.h: gl-stamp; @true
>  
> -GLOBAL_SOURCES = $(base_obj:.o=.c) $(NS_OBJC_OBJ:.o=.m)
> -
> -gl-stamp: $(libsrc)/make-docfile$(EXEEXT) $(GLOBAL_SOURCES)
> -	$(libsrc)/make-docfile -d $(srcdir) -g $(obj) > gl.tmp
> +# Set this to 'false' to speed the build but bloat Emacs a bit, by causing
> +# the gl-stamp build process to bypass the preprocessor and access
> +# symbols directly, even symbols that would be preprocessed away.
> +GLOBALS_CPP = $(CPP)
> +
> +GLOBALS_SOURCES = $(base_obj:.o=.c) $(NS_OBJC_OBJ:.o=.m)
> +
> +gl-stamp: $(libsrc)/make-docfile$(EXEEXT) $(GLOBALS_SOURCES)
> +	test -f globals.h || echo '/* dummy */' >globals.h
> +	rm -f ok.tmp
> +	($(GLOBALS_CPP) -DGENERATE_GLOBALS $(NONDEP_CFLAGS) \
> +	   $(base_obj:.o=.c) \
> +	 && { set x $(NS_OBJC_OBJ:.o=.m); shift; \
> +	      test $$# -eq 0 \
> +	      || $(GLOBALS_CPP) -DGENERATE_GLOBALS $(NONDEP_OBJC_CFLAGS) \
> +		   "$$@"; } \
> +	 && touch ok.tmp) | $(libsrc)/make-docfile -g >gl.tmp
> +	test -f ok.tmp || $(libsrc)/make-docfile -d $(srcdir) -g $(obj) >gl.tmp
>  	$(srcdir)/../build-aux/move-if-change gl.tmp globals.h
>  	echo timestamp > $@

Is this use of "{..}" in shell commands portable enough?

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Tue, 12 Nov 2013 23:19:06 -0500

> Attached is a first cut to implement something along the lines
> that Stefan has been suggesting for a while, namely, to compute
> declarations for DEFSYM variables automatically.  This should
> help avoid needless clutter in the C code and silly errors involving
> mismatched decls etc.  This version is tested on Fedora 19 x86-64
> and Solaris 10 sparc-32.  I plan to do a bit more testing before
> installing it.  I don't know of any reason it wouldn't work with
> Microsoft platforms but I'm no expert there.

Thanks.  That looks good.
I'm wondering about one issue, tho: this creates a "big single file
dependency", so addition/removal of a DEFSYM somewhere causes
recompilation of all files.  Would it be possible to trick the deps/*
rules so they pretend this file is not a dependency?


        Stefan

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Tue, 12 Nov 2013 21:00:17 -0800

Eli Zaretskii wrote:
> Is this use of "{..}" in shell commands portable enough?

It should be.  It worked in the 7th Edition Unix Bourne shell
(1979), and I don't know of any plausible shell where it
doesn't work.  There are many uses of it in 'configure'
already.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Tue, 12 Nov 2013 21:12:21 -0800

Stefan Monnier wrote:
> this creates a "big single file
> dependency", so addition/removal of a DEFSYM somewhere causes
> recompilation of all files.  Would it be possible to trick the deps/*
> rules so they pretend this file is not a dependency?

Possibly, but that would run into the opposite problem.
If you add or remove DEFVAR_LISP somewhere so that
the layout of struct emacs_globals changes, then
omitting the dependency and compiling some files
but not others would make Emacs misbehave badly.

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

From: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 08:36:08 -0500

>> this creates a "big single file
>> dependency", so addition/removal of a DEFSYM somewhere causes
>> recompilation of all files.  Would it be possible to trick the deps/*
>> rules so they pretend this file is not a dependency?
> Possibly, but that would run into the opposite problem.
> If you add or remove DEFVAR_LISP somewhere so that
> the layout of struct emacs_globals changes, then
> omitting the dependency and compiling some files
> but not others would make Emacs misbehave badly.

Of course, we don't want that for DEFVARs or DEFUNs.
I was thinking of doing it only for the DEFSYMs (which would obviously
need to be kept in a separate file).


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eggert <at> cs.ucla.edu, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 18:07:18 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Date: Tue, 12 Nov 2013 23:19:06 -0500
> Cc: 15880 <at> debbugs.gnu.org
> 
> I'm wondering about one issue, tho: this creates a "big single file
> dependency", so addition/removal of a DEFSYM somewhere causes
> recompilation of all files.

How is that different from changing variables and functions exposed to
Lisp, and the dependency on globals.h?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 08:25:41 -0800

Stefan Monnier wrote:
> I was thinking of doing it only for the DEFSYMs (which would obviously
> need to be kept in a separate file).

There still might be problems with existing symbols that are not
DEFSYMed.  For example, suppose we add 'DEFSYM (Qprotected_field,
"protected-field");' to window.c.  The new include file will be rebuilt
and only window.c will be recompiled, and 'make' will succeed.  But
buffer.c (which declares Qprotected_field as a static var and
defines it by hand) will disagree with window.c about where
Qprotected_field is, so Emacs might not work right, and the
problems might be hard to find and diagnose.

While we're on the topic let me tell you of a couple more things
I've been thinking of doing, which this patch would make easier to do.

First, put all DEFSYMS into a single table, initialized statically
with the name of the symbol.  That way, during startup we can run
through the table and intern all the strings, and DEFSYM can turn
into a no-op; this should make Emacs smaller (no need to
staticpro the symbols, for example, since the g.c. can consult the
table).  (This idea is incompatible with the idea of removing
dependencies on a new DEFSYMs include file.)

Second, preallocate each DEFSYM's struct Lisp_Symbol, so that its
address is known at link-time.  This should measurably improve
runtime performance, e.g., NILP will run faster.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 17:00:36 -0500

>> I'm wondering about one issue, tho: this creates a "big single file
>> dependency", so addition/removal of a DEFSYM somewhere causes
>> recompilation of all files.
> How is that different from changing variables and functions exposed to
> Lisp, and the dependency on globals.h?

Fundamentally, it's no different, but I think that in practice it's
different for one reason: the type of a Qfoo variable is always
Lisp_Object, so there's never a need to recompile because that
object changed.  So the cases where recompilation is warranted are
less frequent.


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 19:26:08 -0500

>> I was thinking of doing it only for the DEFSYMs (which would obviously
>> need to be kept in a separate file).
> There still might be problems with existing symbols that are not
> DEFSYMed.  For example, suppose we add 'DEFSYM (Qprotected_field,
> "protected-field");' to window.c.  The new include file will be rebuilt
> and only window.c will be recompiled, and 'make' will succeed.  But
> buffer.c (which declares Qprotected_field as a static var and
> defines it by hand) will disagree with window.c about where
> Qprotected_field is, so Emacs might not work right, and the
> problems might be hard to find and diagnose.

Doesn't sound like a serious problem to me.  The two variables have the
same name and same content and are read-only, so the redundancy is harmless.

> Second, preallocate each DEFSYM's struct Lisp_Symbol, so that its
> address is known at link-time.

Not sure the performance impact would be significant.  But I'm not
opposed to such a change.

As for the other change: ideally, I'd like to get rid of DEFSYM and
introduce instead a new macro that would replace:

         ... Qfoo_bar ...

      syms_of_bar ()
      {
        ...
        DEFSYM (Qfoo_bar, "foo-bar");
        ...
      }

with

         ... INTERN ("foo-bar") ...

      syms_of_bar ()
      {
        ...
        /* nothing here */
        ...
      }

Now, I don't think we could do it with INTERN("foo-bar").  But we could
probably do it with:

         ... INTERN (Qfoo_bar) ...

      syms_of_bar ()
      {
        ...
        /* nothing here */
        ...
      }

such that make-docfile finds the "INTERN", infers the Lisp name from the
C name and writes a "syms.c" file which does little else but initialize
all those symbols.


        Stefan

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 17:32:15 -0800

Stefan Monnier wrote:

> The two variables have the
> same name and same content and are read-only, so the redundancy is harmless.

Hmm, well, I suppose you're right.  Still, the idea of removing the
dependency on DEFSYM-related globals would preclude the potential
optimization of putting these globals into a table at compile-time.
I suppose that part of the issue is that I don't add or remove
DEFSYMs very often, so even aside from the precluded optimization
I'm reluctant to complicate the build system just to save a few
build-time cycles on these rare occasions.

> such that make-docfile finds the "INTERN", infers the Lisp name from the
> C name and writes a "syms.c" file which does little else but initialize
> all those symbols.

I was thinking of something even simpler: no macros at all.
If the C source code mentions an identifier Qfoo_bar, make-docfile
automatically generates the Lisp symbol foo-bar.  To aid transition
we could make DEFSYM a no-op, or we could go through the code and
eliminate all the DEFSYM calls.  (This would all be done after the
current patch is installed, of course.)

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 21:29:09 -0500

> Hmm, well, I suppose you're right.  Still, the idea of removing the
> dependency on DEFSYM-related globals would preclude the potential
> optimization of putting these globals into a table at compile-time.

Actually, I'm not sure I understand what you're suggesting here as
a table, and what the optimization could be.  Are you thinking of
something like:

  struct Lisp_Symbol symbol_structs[N];
  const Lisp_Object symbol_vals[N]
    = {
      Lisp_Symbol + (EMACS_INT)(symbol_structs + 0),
      Lisp_Symbol + (EMACS_INT)(symbol_structs + 1),
      ...
    }
  #define Qfoo (symbol_vals[0])
  #define Qbar (symbol_vals[1])
  ...

but if so, would that really be faster?  I mean, can the C compiler
really presume that symbol_vals[0] won't be changed and constant-fold
its value at link-time?

> I suppose that part of the issue is that I don't add or remove
> DEFSYMs very often, so even aside from the precluded optimization
> I'm reluctant to complicate the build system just to save a few
> build-time cycles on these rare occasions.

You might be right (tho my computers tend to be slowish and make such
recompilation very noticeable).

>> such that make-docfile finds the "INTERN", infers the Lisp name from the
>> C name and writes a "syms.c" file which does little else but initialize
>> all those symbols.
> I was thinking of something even simpler: no macros at all.

Sounds good, indeed.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eggert <at> cs.ucla.edu, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Thu, 14 Nov 2013 05:47:43 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eggert <at> cs.ucla.edu,  15880 <at> debbugs.gnu.org
> Date: Wed, 13 Nov 2013 17:00:36 -0500
> 
> >> I'm wondering about one issue, tho: this creates a "big single file
> >> dependency", so addition/removal of a DEFSYM somewhere causes
> >> recompilation of all files.
> > How is that different from changing variables and functions exposed to
> > Lisp, and the dependency on globals.h?
> 
> Fundamentally, it's no different, but I think that in practice it's
> different for one reason: the type of a Qfoo variable is always
> Lisp_Object, so there's never a need to recompile because that
> object changed.  So the cases where recompilation is warranted are
> less frequent.

Recompilation of C files is so fast nowadays that this kind of
optimization gains very little, but can potentially cause waste of
developers' time, whereby they will sometimes need to debug problems
due to the fact that we did not recompile.

So I think this would be a step backward, to the era when the
dependency on lisp.h was suppressed for similar reasons.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 20:13:33 -0800

Stefan Monnier wrote:
> I mean, can the C compiler
> really presume that symbol_vals[0] won't be changed and constant-fold
> its value at link-time?

I was thinking of something that didn't have a symbol_vals table, like this:

struct Lisp_Symbol symbol_structs[N];
#define Qnil make_lisp_ptr (symbol_structs + 0, Lisp_Symbol)
#define Qt   make_lisp_ptr (symbol_structs + 1, Lisp_Symbol)
...

Qnil, Qt etc. should evaluate to compile-time constants for
any reasonably modern C compiler.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 23:59:52 -0500

> Recompilation of C files is so fast nowadays that this kind of

It probably depends on your computers, but mine aren't really much
faster than the ones I had 10 years ago.

> So I think this would be a step backward, to the era when the
> dependency on lisp.h was suppressed for similar reasons.

It can be made optional (and default to the safe setting).


        Stefan

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Thu, 14 Nov 2013 00:06:07 -0500

> I was thinking of something that didn't have a symbol_vals table, like this:

> struct Lisp_Symbol symbol_structs[N];
> #define Qnil make_lisp_ptr (symbol_structs + 0, Lisp_Symbol)
> #define Qt   make_lisp_ptr (symbol_structs + 1, Lisp_Symbol)
> ...

Oh, right.  So you need a mark_symbol_array function, but yes, that
could lead to slightly more efficient optimized code.  Of course,
without link-time optimization, it probably won't be any better than
what we have (tho not sure if it would be worse; probably a wash).


        Stefan

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 13 Nov 2013 21:26:46 -0800

Stefan Monnier wrote:
> without link-time optimization, it probably won't be any better than
> what we have

Actually, I would expect the reverse.
Suppose we run this:

   Lisp_Object x = !NILP (a) ? a : make_number (0);
   foo ();
   Lisp_Object y = !NILP (a) ? a : make_number (0);

With the implementation I suggested, any
decent compiler can do common subexpression elimination
and optimize away the calculation of y, even if foo is an external
function that does goodness knows what.  That optimization can't
be done with the current Emacs implementation, because the compiler
can't assume that Qnil remains unmodified across foo's call
(at least, not unless we have link time optimization
and can look inside foo's body).

If foo is a function pointer, even link time
optimization won't suffice for common subexpression
elimination, so the implementation I
suggested should be a win even if LTO is used,
even if the win isn't as large as it is in the
non-LTO case.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: monnier <at> iro.umontreal.ca, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Thu, 14 Nov 2013 18:28:46 +0200

> Date: Wed, 13 Nov 2013 20:13:33 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Cc: 15880 <at> debbugs.gnu.org
> 
> I was thinking of something that didn't have a symbol_vals table, like this:
> 
> struct Lisp_Symbol symbol_structs[N];
> #define Qnil make_lisp_ptr (symbol_structs + 0, Lisp_Symbol)
> #define Qt   make_lisp_ptr (symbol_structs + 1, Lisp_Symbol)
> ...
> 
> Qnil, Qt etc. should evaluate to compile-time constants for
> any reasonably modern C compiler.

Please leave at least Qnil and Qt out of this arrangement, so that
they continue being variables, not macros.  Macros are a nuisance in
the debugger (e.g., if the compilation was not with -g3, or with old
versions of GCC).  These two are very useful in the debugger, both for
calling functions and for comparing Lisp values against them.

The other symbols could become macros, although that, too, would cause
inconvenience.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eggert <at> cs.ucla.edu, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Thu, 14 Nov 2013 18:29:37 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: eggert <at> cs.ucla.edu,  15880 <at> debbugs.gnu.org
> Date: Wed, 13 Nov 2013 23:59:52 -0500
> 
> It can be made optional (and default to the safe setting).

That would be fine, indeed.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: monnier <at> iro.umontreal.ca, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Thu, 14 Nov 2013 12:25:45 -0800

On 11/14/2013 08:28 AM, Eli Zaretskii wrote:
> Please leave at least Qnil and Qt out of this arrangement, so that
> they continue being variables, not macros.

We can address that problem the way that we already address similar
problems with ARRAY_MARK_FLAG, VAL_MASK, etc.  That is, we can
define Qnil both as a macro (used by the C code) and as a
variable or better yet a constant (used by GDB on older systems
that lack -g3).

Since there are quite a few symbols it might be worth doing this
only when -g3 is not used, to keep the runtime a bit smaller.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: monnier <at> iro.umontreal.ca, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Fri, 15 Nov 2013 09:59:20 +0200

> Date: Thu, 14 Nov 2013 12:25:45 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: monnier <at> iro.umontreal.ca, 15880 <at> debbugs.gnu.org
> 
> Since there are quite a few symbols it might be worth doing this
> only when -g3 is not used, to keep the runtime a bit smaller.

That would be confusing, I think.  We shouldn't need to remember how
Emacs was compiled to debug it.  Having a "print Qfoo" display some
weird error message under obscure circumstances is an annoyance.

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Fri, 15 Nov 2013 08:58:15 -0500

>> Since there are quite a few symbols it might be worth doing this
>> only when -g3 is not used, to keep the runtime a bit smaller.
> That would be confusing, I think.  We shouldn't need to remember how
> Emacs was compiled to debug it.  Having a "print Qfoo" display some
> weird error message under obscure circumstances is an annoyance.

+1


        Stefan

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: 15880 <at> debbugs.gnu.org
Subject: Re: Compute C declarations for DEFSYMs automatically.
Date: Fri, 19 Dec 2014 17:55:37 -0800

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

Attached, finally, is an updated version of the patch which should 
address the points raised. As the ChangeLog notes, this patch uses a 
couple of ideas that improve overall performance a bit for Elisp code, 
since it means a decent C compiler can do better analysis of C code now 
that Qnil etc. are constants.  The constants are visible even to 
debuggers that don't grok macros, which I think was the main sticking 
point with the earlier approach.

[Qfoo.diff (text/x-patch, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Tue, 23 Dec 2014 12:15:45 -0500

> Attached, finally, is an updated version of the patch which should address
> the points raised. As the ChangeLog notes, this patch uses a couple of ideas
> that improve overall performance a bit for Elisp code, since it
> means a decent C compiler can do better analysis of C code now that Qnil
> etc. are constants.  The constants are visible even to debuggers that don't
> grok macros, which I think was the main sticking point with the
> earlier approach.

Could you split this patch into at least two parts:
- auto-generate the symbols from make-docfile.
- make Qnil be zero.
The other part (make those Q<foo> be link-time constants) could be
a third patch or folded into one of the other two.


        Stefan

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Tue, 23 Dec 2014 15:51:13 -0800

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

On 12/23/2014 09:15 AM, Stefan Monnier wrote:
> Could you split this patch into at least two parts:
> - auto-generate the symbols from make-docfile.
> - make Qnil be zero.
> The other part (make those Q<foo> be link-time constants) could be
> a third patch or folded into one of the other two.
>

Sure.  It's easy to create one patch for autogeneration and link-time 
constants, and a second patch for making Qnil be zero. Attached.  These 
are relative to trunk commit e55a467ec0f758c311d358ceb7d66a8a7d9482c3 
dated today.

[0001-Compute-C-decls-for-DEFSYMs-automatically.patch (text/x-patch, attachment)]

[0002-Use-0-for-Qnil.patch (text/x-patch, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Mon, 05 Jan 2015 11:51:04 -0500

> Sure.  It's easy to create one patch for autogeneration and link-time
> constants, and a second patch for making Qnil be zero. Attached.  These are
> relative to trunk commit e55a467ec0f758c311d358ceb7d66a8a7d9482c3
> dated today.

Thanks.  I'm worried about:

+/* Yield an integer that tags PTR as a symbol.  */
+#define TAG_SYMPTR(ptr) TAG_PTR (Lisp_Symbol, (char *) (ptr) - (char *) lispsym)

This subtraction can yield a negative number.  For the USE_LSB_TAG case,
that's not a problem, but for the case where we use the MSB for the tag,
a negative number will not have the expected 000 in the MSB.


        Stefan

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Mon, 05 Jan 2015 09:25:25 -0800

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

On 01/05/2015 08:51 AM, Stefan Monnier wrote:
> For the USE_LSB_TAG case,
> that's not a problem, but for the case where we use the MSB for the tag,
> a negative number will not have the expected 000 in the MSB.

Thanks, good catch.  This is a problem on !USE_LSB_TAG platforms where 
heap memory lives below statically-allocated memory.  That should be 
rare (I don't know of such a platform offhand), but for now the simplest 
fix is to avoid this optimization on !USE_LSB_TAG platforms.  Revised 
patches attached, updated to match the latest master.

[0001-Compute-C-decls-for-DEFSYMs-automatically.patch (text/x-patch, attachment)]

[0002-Use-0-for-Qnil.patch (text/x-patch, attachment)]

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Mon, 05 Jan 2015 12:55:56 -0500

> Thanks, good catch.  This is a problem on !USE_LSB_TAG platforms where heap
> memory lives below statically-allocated memory.  That should be rare (I
> don't know of such a platform offhand), but for now the simplest fix is to
> avoid this optimization on !USE_LSB_TAG platforms.  Revised patches
> attached, updated to match the latest master.

Thanks.  I'm not completely happy with the added complexity, but... OK
please install into master,


        Stefan

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 15880-done <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Mon, 05 Jan 2015 10:17:00 -0800

Thanks for the review.  I'll try to think of a simpler way for MSB 
hosts, though that isn't a high priority.  I installed it and am marking 
this as done.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Mon, 05 Jan 2015 20:56:36 +0200

> Date: Mon, 05 Jan 2015 10:17:00 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Cc: 15880-done <at> debbugs.gnu.org
> 
> Thanks for the review.  I'll try to think of a simpler way for MSB 
> hosts, though that isn't a high priority.  I installed it and am marking 
> this as done.

Did you try to build with --enable-checking?  It fails to compile for
me:

  In file included from dispnew.c:26:0:
  lisp.h:209:23: error: expected ')' before '||' token
      (suppress_checking || (cond)     \
			 ^
  lisp.h:360:5: note: in expansion of macro 'eassert'
      (eassert (SYMBOLP (a)), \
       ^
  lisp.h:405:21: note: in expansion of macro 'lisp_h_XSYMBOL'
   # define XSYMBOL(a) lisp_h_XSYMBOL (a)
		       ^
  lisp.h:612:28: note: in expansion of macro 'XSYMBOL'
   INLINE struct Lisp_Symbol *XSYMBOL (Lisp_Object);
			      ^
  lisp.h:360:26: error: expected ')' before ',' token
      (eassert (SYMBOLP (a)), \
			    ^
  lisp.h:405:21: note: in expansion of macro 'lisp_h_XSYMBOL'
   # define XSYMBOL(a) lisp_h_XSYMBOL (a)
		       ^
  lisp.h:612:28: note: in expansion of macro 'XSYMBOL'
   INLINE struct Lisp_Symbol *XSYMBOL (Lisp_Object);
			      ^
  In file included from lisp.h:743:0,
		   from dispnew.c:26:
  globals.h:1407:24: error: expected declaration specifiers or '...' before '(' token
   #define aQCloaded_from (&lispsym[70])
			  ^
  globals.h:1408:41: note: in expansion of macro 'aQCloaded_from'
   #define QCloaded_from make_lisp_symbol (aQCloaded_from)
					   ^
  w32.h:175:20: note: in expansion of macro 'QCloaded_from'
   extern Lisp_Object QCloaded_from;
		      ^
  Makefile:354: recipe for target `dispnew.o' failed

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Mon, 05 Jan 2015 11:24:52 -0800

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

On 01/05/2015 10:56 AM, Eli Zaretskii wrote:
> Did you try to build with --enable-checking?  It fails to compile for
> me:
Works for me.  But your diagnostics show a problem: I forgot to clean 
out the now-harmful static Q* declarations from the w32 files.  Does the 
attached patch fix the problem for you?  I can't easily test it on my 
GNU/Linux platform.

[w32q.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: eggert <at> cs.ucla.edu
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Mon, 05 Jan 2015 21:27:28 +0200

> Date: Mon, 05 Jan 2015 20:56:36 +0200
> From: Eli Zaretskii <eliz <at> gnu.org>
> Cc: 15880 <at> debbugs.gnu.org
> 
>   In file included from dispnew.c:26:0:
>   lisp.h:209:23: error: expected ')' before '||' token
>       (suppress_checking || (cond)     \
> 			 ^
>   lisp.h:360:5: note: in expansion of macro 'eassert'
>       (eassert (SYMBOLP (a)), \
>        ^
>   lisp.h:405:21: note: in expansion of macro 'lisp_h_XSYMBOL'
>    # define XSYMBOL(a) lisp_h_XSYMBOL (a)
> 		       ^
>   lisp.h:612:28: note: in expansion of macro 'XSYMBOL'
>    INLINE struct Lisp_Symbol *XSYMBOL (Lisp_Object);
> 			      ^
>   lisp.h:360:26: error: expected ')' before ',' token
>       (eassert (SYMBOLP (a)), \
> 			    ^
>   lisp.h:405:21: note: in expansion of macro 'lisp_h_XSYMBOL'
>    # define XSYMBOL(a) lisp_h_XSYMBOL (a)
> 		       ^
>   lisp.h:612:28: note: in expansion of macro 'XSYMBOL'
>    INLINE struct Lisp_Symbol *XSYMBOL (Lisp_Object);

Is this the right fix?

diff --git a/src/lisp.h b/src/lisp.h
index fc04ab9..d9f43cc 100644
--- a/src/lisp.h
+++ b/src/lisp.h
@@ -609,7 +609,9 @@ INLINE void set_sub_char_table_contents (Lisp_Object, ptrdiff_t,
 INLINE bool SUBRP (Lisp_Object);
 INLINE bool (SYMBOLP) (Lisp_Object);
 INLINE bool (VECTORLIKEP) (Lisp_Object);
+#ifndef XSYMBOL
 INLINE struct Lisp_Symbol *XSYMBOL (Lisp_Object);
+#endif
 INLINE void *(XUNTAGBASE) (Lisp_Object, int, void *);
 INLINE bool WINDOWP (Lisp_Object);
 INLINE struct Lisp_Save_Value *XSAVE_VALUE (Lisp_Object);

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Mon, 05 Jan 2015 21:48:42 +0200

> Date: Mon, 05 Jan 2015 11:24:52 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 15880 <at> debbugs.gnu.org
> 
> On 01/05/2015 10:56 AM, Eli Zaretskii wrote:
> > Did you try to build with --enable-checking?  It fails to compile for
> > me:
> Works for me.

Strange.  I don't understand how this:

  #define lisp_h_XSYMBOL(a) \
     (eassert (SYMBOLP (a)), \
      (struct Lisp_Symbol *) XUNTAGBASE (a, Lisp_Symbol, lispsym))
  # define XSYMBOL(a) lisp_h_XSYMBOL (a)

and this:

  INLINE struct Lisp_Symbol *XSYMBOL (Lisp_Object);

can live together.  Can you explain?

> But your diagnostics show a problem: I forgot to clean out the
> now-harmful static Q* declarations from the w32 files.  Does the
> attached patch fix the problem for you?  I can't easily test it on
> my GNU/Linux platform.

Thanks, I already fixed those, and will push shortly, as soon as the
lisp.h problem is resolved.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Mon, 05 Jan 2015 14:20:01 -0800

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

On 01/05/2015 11:48 AM, Eli Zaretskii wrote:
> I don't understand how this:
>
>    #define lisp_h_XSYMBOL(a) \
>       (eassert (SYMBOLP (a)), \
>        (struct Lisp_Symbol *) XUNTAGBASE (a, Lisp_Symbol, lispsym))
>    # define XSYMBOL(a) lisp_h_XSYMBOL (a)
>
> and this:
>
>    INLINE struct Lisp_Symbol *XSYMBOL (Lisp_Object);
>
> can live together.  Can you explain?

Ah, I see the problem now: I was compiling with optimization and you're 
not.  I installed the attached patch to fix that.  When optimizing, 
XSYMBOL is not defined as a macro.

[0001-lisp.h-XSYMBOL-Parenthesize-id-in-forward-decl.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Tue, 06 Jan 2015 05:28:00 +0200

> Date: Mon, 05 Jan 2015 14:20:01 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: 15880 <at> debbugs.gnu.org
> 
> On 01/05/2015 11:48 AM, Eli Zaretskii wrote:
> > I don't understand how this:
> >
> >    #define lisp_h_XSYMBOL(a) \
> >       (eassert (SYMBOLP (a)), \
> >        (struct Lisp_Symbol *) XUNTAGBASE (a, Lisp_Symbol, lispsym))
> >    # define XSYMBOL(a) lisp_h_XSYMBOL (a)
> >
> > and this:
> >
> >    INLINE struct Lisp_Symbol *XSYMBOL (Lisp_Object);
> >
> > can live together.  Can you explain?
> 
> Ah, I see the problem now: I was compiling with optimization and you're 
> not.  I installed the attached patch to fix that.  When optimizing, 
> XSYMBOL is not defined as a macro.

Thanks, this fixed the problem for me.

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

From: Glenn Morris <rgm <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>,  15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 07 Jan 2015 16:48:19 -0500

This change causes `make check' to fail; specifically in file-notify-tests.

http://hydra.nixos.org/build/18427569

Reproduced on RHEL7 with CFLAGS='-O0 -g3' and -lgio.

Problem is related to line 183 of gfilenotify.c.

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Glenn Morris <rgm <at> gnu.org>, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Wed, 07 Jan 2015 17:16:41 -0800

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

Glenn Morris wrote:
>
> This change causes `make check' to fail; specifically in file-notify-tests.

Thanks for reporting that bug.  I reproduced the problem and installed the 
attached patch, which fixes it for me.

[0001-Port-GFileMonitor-hack-to-Qnil-0-platforms.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rgm <at> gnu.org, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Thu, 08 Jan 2015 15:28:03 +0200

> Date: Wed, 07 Jan 2015 17:16:41 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> 
> Glenn Morris wrote:
> >
> > This change causes `make check' to fail; specifically in file-notify-tests.
> 
> Thanks for reporting that bug.  I reproduced the problem and installed the 
> attached patch, which fixes it for me.
> 
> >From d71659fed4eb87eb3edbf8f83fb0e9ed2633fa74 Mon Sep 17 00:00:00 2001
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> Date: Wed, 7 Jan 2015 17:12:16 -0800
> Subject: [PATCH] Port GFileMonitor * hack to Qnil==0 platforms
> 
> Reported by Glenn Morris in: http://bugs.gnu.org/15880#112
> * gfilenotify.c (monitor_to_lisp, lisp_to_monitor): New functions.
> (dir_monitor_callback, Fgfile_add_watch, Fgfile_rm_watch): Use them.
> ---
>  src/ChangeLog     |  7 +++++++
>  src/gfilenotify.c | 33 +++++++++++++++++++++++----------
>  2 files changed, 30 insertions(+), 10 deletions(-)
> 
> diff --git a/src/ChangeLog b/src/ChangeLog
> index 8680c5e..2fc3479 100644
> --- a/src/ChangeLog
> +++ b/src/ChangeLog
> @@ -1,3 +1,10 @@
> +2015-01-08  Paul Eggert  <eggert <at> cs.ucla.edu>
> +
> +	Port GFileMonitor * hack to Qnil==0 platforms
> +	Reported by Glenn Morris in: http://bugs.gnu.org/15880#112
> +	* gfilenotify.c (monitor_to_lisp, lisp_to_monitor): New functions.
> +	(dir_monitor_callback, Fgfile_add_watch, Fgfile_rm_watch): Use them.

Could we instead just keep the previous semantics of XIL and XLI,
please?  They are used in a few places outside lisp.h, so now all of
those places need to be audited and most probably changed.  Why isn't
it better to change the implementation of just 2 macros instead?

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

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: rgm <at> gnu.org, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Fri, 09 Jan 2015 08:33:53 -0800

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

Eli Zaretskii wrote:
> Could we instead just keep the previous semantics of XIL and XLI,
> please?  They are used in a few places outside lisp.h, so now all of
> those places need to be audited and most probably changed.  Why isn't
> it better to change the implementation of just 2 macros instead?

XIL and XLI haven't changed, and have the same semantics as before: they convert 
between Lisp_Object and EMACS_INT without altering the bits (i.e., they are 
no-ops at the machine level).  I expect it's better to keep them no-ops, for 
efficiency in the kernel of the Emacs Lisp interpreter.

I audited all the places XIL and XLI are used, and the uses in non-w32 code are 
all fine.  I don't know the w32 code, but most likely some or all of its uses 
need to be changed.  I moved the new conversion operations to lisp.h (installed 
on master) and wrote the attached untested patch for the w32 code.

[0001-Fix-pointer-to-integer-conversion-in-w32-code.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Paul Eggert <eggert <at> cs.ucla.edu>
Cc: rgm <at> gnu.org, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Fri, 09 Jan 2015 22:06:07 +0200

> Date: Fri, 09 Jan 2015 08:33:53 -0800
> From: Paul Eggert <eggert <at> cs.ucla.edu>
> CC: rgm <at> gnu.org, 15880 <at> debbugs.gnu.org
> 
> Eli Zaretskii wrote:
> > Could we instead just keep the previous semantics of XIL and XLI,
> > please?  They are used in a few places outside lisp.h, so now all of
> > those places need to be audited and most probably changed.  Why isn't
> > it better to change the implementation of just 2 macros instead?
> 
> XIL and XLI haven't changed, and have the same semantics as before: they convert 
> between Lisp_Object and EMACS_INT without altering the bits (i.e., they are 
> no-ops at the machine level).

That's not what their previous semantics was.  They converted between
a Lisp integer and EMACS_INT.  Now the object that comes out of them
is a Lisp symbol which is invalid: it has no Lisp_Symbol structure
allocated for it, so e.g. displaying it via the prin* functions will
likely segfault.

> I expect it's better to keep them no-ops, for efficiency in the
> kernel of the Emacs Lisp interpreter.

If we need efficient macros for the interpreter, we can have new
ones for that.  I'm saying let's leave XIL and XLI do what they did
previously: convert from a Lisp integer to an EMACS_INT and back.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Paul Eggert <eggert <at> cs.ucla.edu>, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Fri, 09 Jan 2015 21:08:56 +0100

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

>> Date: Fri, 09 Jan 2015 08:33:53 -0800
>> From: Paul Eggert <eggert <at> cs.ucla.edu>
>> CC: rgm <at> gnu.org, 15880 <at> debbugs.gnu.org
>> 
>> Eli Zaretskii wrote:
>> > Could we instead just keep the previous semantics of XIL and XLI,
>> > please?  They are used in a few places outside lisp.h, so now all of
>> > those places need to be audited and most probably changed.  Why isn't
>> > it better to change the implementation of just 2 macros instead?
>> 
>> XIL and XLI haven't changed, and have the same semantics as before: they convert 
>> between Lisp_Object and EMACS_INT without altering the bits (i.e., they are 
>> no-ops at the machine level).
>
> That's not what their previous semantics was.  They converted between
> a Lisp integer and EMACS_INT.

No, that's called XINT.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Andreas Schwab <schwab <at> linux-m68k.org>
Cc: eggert <at> cs.ucla.edu, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Fri, 09 Jan 2015 22:50:13 +0200

> From: Andreas Schwab <schwab <at> linux-m68k.org>
> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  15880 <at> debbugs.gnu.org
> Date: Fri, 09 Jan 2015 21:08:56 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Date: Fri, 09 Jan 2015 08:33:53 -0800
> >> From: Paul Eggert <eggert <at> cs.ucla.edu>
> >> CC: rgm <at> gnu.org, 15880 <at> debbugs.gnu.org
> >> 
> >> Eli Zaretskii wrote:
> >> > Could we instead just keep the previous semantics of XIL and XLI,
> >> > please?  They are used in a few places outside lisp.h, so now all of
> >> > those places need to be audited and most probably changed.  Why isn't
> >> > it better to change the implementation of just 2 macros instead?
> >> 
> >> XIL and XLI haven't changed, and have the same semantics as before: they convert 
> >> between Lisp_Object and EMACS_INT without altering the bits (i.e., they are 
> >> no-ops at the machine level).
> >
> > That's not what their previous semantics was.  They converted between
> > a Lisp integer and EMACS_INT.
> 
> No, that's called XINT.

OK, a C integer, not EMACS_INT.  But you already knew that, of course.

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

From: Andreas Schwab <schwab <at> linux-m68k.org>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Fri, 09 Jan 2015 22:10:42 +0100

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

>> From: Andreas Schwab <schwab <at> linux-m68k.org>
>> Cc: Paul Eggert <eggert <at> cs.ucla.edu>,  15880 <at> debbugs.gnu.org
>> Date: Fri, 09 Jan 2015 21:08:56 +0100
>> 
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>> 
>> >> Date: Fri, 09 Jan 2015 08:33:53 -0800
>> >> From: Paul Eggert <eggert <at> cs.ucla.edu>
>> >> CC: rgm <at> gnu.org, 15880 <at> debbugs.gnu.org
>> >> 
>> >> Eli Zaretskii wrote:
>> >> > Could we instead just keep the previous semantics of XIL and XLI,
>> >> > please?  They are used in a few places outside lisp.h, so now all of
>> >> > those places need to be audited and most probably changed.  Why isn't
>> >> > it better to change the implementation of just 2 macros instead?
>> >> 
>> >> XIL and XLI haven't changed, and have the same semantics as before: they convert 
>> >> between Lisp_Object and EMACS_INT without altering the bits (i.e., they are 
>> >> no-ops at the machine level).
>> >
>> > That's not what their previous semantics was.  They converted between
>> > a Lisp integer and EMACS_INT.
>> 
>> No, that's called XINT.
>
> OK, a C integer, not EMACS_INT.  But you already knew that, of course.

I don't understand what you are trying to say.

Andreas.

-- 
Andreas Schwab, schwab <at> linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

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

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: eggert <at> cs.ucla.edu, Andreas Schwab <schwab <at> linux-m68k.org>,
 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Fri, 09 Jan 2015 16:48:53 -0500

>> > That's not what their previous semantics was.

I agree with Paul, that the previous (and current) semantics is:

   convert  between Lisp_Object and EMACS_INT without altering the bits
   (i.e., they are  no-ops at the machine level)

>> > They converted between a Lisp integer and EMACS_INT.

I don't know what that means.


        Stefan

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: eggert <at> cs.ucla.edu, schwab <at> linux-m68k.org, 15880 <at> debbugs.gnu.org
Subject: Re: bug#15880: Compute C declarations for DEFSYMs automatically.
Date: Sat, 10 Jan 2015 13:30:46 +0200

> From: Stefan Monnier <monnier <at> iro.umontreal.ca>
> Cc: Andreas Schwab <schwab <at> linux-m68k.org>,  eggert <at> cs.ucla.edu,  15880 <at> debbugs.gnu.org
> Date: Fri, 09 Jan 2015 16:48:53 -0500
> 
> >> > That's not what their previous semantics was.
> 
> I agree with Paul, that the previous (and current) semantics is:
> 
>    convert  between Lisp_Object and EMACS_INT without altering the bits
>    (i.e., they are  no-ops at the machine level)

But you never liked the "other" uses of those macros to begin with, so
I'm not surprised you are happier now.

Previous Next

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