Re: [Emacs-diffs] trunk r117286: Fix last commit.

Re: [Emacs-diffs] trunk r117286: Fix last commit.

[Stefan Monnier]

>    src/menu.h (tty_menu_show) [WINDOWSNT]: Declare extern only for WINDOWSNT.

I wish people could refrain from playing around with the
static/extern declarations.

If something is extern when it could be static, that's really not
a serious problem.


        Stefan

Re: [Emacs-diffs] trunk r117286: Fix last commit.

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Sat, 07 Jun 2014 20:50:39 -0400
> 
> >    src/menu.h (tty_menu_show) [WINDOWSNT]: Declare extern only for WINDOWSNT.
> 
> I wish people could refrain from playing around with the
> static/extern declarations.

I didn't.  I just fixed something that was already there.

Re: [Emacs-diffs] trunk r117286: Fix last commit.

[Paul Eggert]

Eli Zaretskii wrote:
>> I wish people could refrain from playing around with the
>> >static/extern declarations.
> I didn't.  I just fixed something that was already there.

I think Stefan was referring to the practice of marking symbols as 
static if they're not used in other modules.  Generally speaking this is 
good practice, as non-expert readers of the code needn't consider 
whether a static symbol might be used by another module.  It can help 
GCC in the same way.

However, I take Stefan's point that the practice gets messy when dealing 
with functions that can be static on typical GNU/Linux builds but must 
be extern on other ports.  So I installed trunk bzr 117290 to make these 
symbols extern.  This gets rid of the mess, and I hope Stefan considers 
it simplification and not "playing around".

Re: [Emacs-diffs] trunk r117286: Fix last commit.

[Eli Zaretskii]

> Date: Sun, 08 Jun 2014 11:30:46 -0700
> From: Paul Eggert <eggert@cs.ucla.edu>
> CC: emacs-devel@gnu.org
> 
> However, I take Stefan's point that the practice gets messy when dealing 
> with functions that can be static on typical GNU/Linux builds but must 
> be extern on other ports.  So I installed trunk bzr 117290 to make these 
> symbols extern.

Thanks.

Re: [Emacs-diffs] trunk r117286: Fix last commit.

[Stefan Monnier]

>>> I wish people could refrain from playing around with the
>>> >static/extern declarations.
>> I didn't.  I just fixed something that was already there.

This was not directed at you in particular, indeed.

> I think Stefan was referring to the practice of marking symbols as
> static if they're not used in other modules.

Right.

> Generally speaking this is good practice, as non-expert readers of the
> code needn't consider whether a static symbol might be used by another
> module.  It can help GCC in the same way.

Yes, but for things which are conceptually global (e.g. all the Qfoo
thingies, which by convention share namespace with Elisp's), the fact
they are currently only accessed from a single file doesn't mean it will
(or even should) stay that way, and adding "static" when that changes is
pointless (and just means we'll have to remove that "static" next time
it changes).

> However, I take Stefan's point that the practice gets messy when dealing
> with functions that can be static on typical GNU/Linux builds but must be
> extern on other ports.  So I installed trunk bzr 117290 to make these
> symbols extern.

Yes, that's better.


        Stefan

Re: [Emacs-diffs] trunk r117286: Fix last commit.

[Paul Eggert]

On 06/09/2014 09:19 AM, Stefan Monnier wrote:
> Yes, but for things which are conceptually global (e.g. all the Qfoo
> thingies, which by convention share namespace with Elisp's)

OK, I'll bump the priority of Bug#15880; this should resolve the issue 
of worrying about 'static' before Qfoo declarations.

I had been meaning to do this anyway, for another reason: I would like 
'NILP (x)' in C to compile into something as simple and efficient as 'x 
== 0', and we can do that if we apply the patch in Bug#15880 and one or 
two other transformations.  With luck, this should address the other 
objections to the proposed patch in Bug#15880.