[obv] Make 'disable_display' static.

[obv] Make 'disable_display' static.

[Yao Qi]

Hi,
disable_display is only called by disable_current_display in
printcmd.c, so we can make it static.  I'll apply it in two days.

gdb:

2013-01-11  Yao Qi  <yao@codesourcery.com>

	* breakpoint.h (disable_display): Remove declaration.
	* printcmd.c (disable_display): Make it static.
---
 gdb/breakpoint.h |    2 --
 gdb/printcmd.c   |    2 +-
 2 files changed, 1 insertions(+), 3 deletions(-)

diff --git a/gdb/breakpoint.h b/gdb/breakpoint.h
index 95dc980..0bef89b 100644
--- a/gdb/breakpoint.h
+++ b/gdb/breakpoint.h
@@ -1365,8 +1365,6 @@ extern void disable_current_display (void);
 
 extern void do_displays (void);
 
-extern void disable_display (int);
-
 extern void clear_displays (void);
 
 extern void disable_breakpoint (struct breakpoint *);
diff --git a/gdb/printcmd.c b/gdb/printcmd.c
index a576d88..d47adb6 100644
--- a/gdb/printcmd.c
+++ b/gdb/printcmd.c
@@ -1803,7 +1803,7 @@ do_displays (void)
 /* Delete the auto-display which we were in the process of displaying.
    This is done when there is an error or a signal.  */
 
-void
+static void
 disable_display (int num)
 {
   struct display *d;
-- 
1.7.7.6

Re: [obv] Make 'disable_display' static.

[Eli Zaretskii]

> From: Yao Qi <yao@codesourcery.com>
> Date: Fri, 11 Jan 2013 10:13:50 +0800
> 
> disable_display is only called by disable_current_display in
> printcmd.c, so we can make it static.  I'll apply it in two days.

Thanks.

I'm not necessarily against this patch, but I have 2 questions to the
forum:

  . why is it a good idea to go hunting for functions not used outside
    its source file and make them static?  I don't see this
    requirement in any coding standards document pertinent to GDB.

  . if this is NOT mandated by any coding standards we try to enforce,
    why is this an "obvious" patch?

The reason I'm asking is that, in general, whoever wrote that function
could have judged it to be generally useful and export-worthy.  IOW,
its non-static type might be a result of deliberate design, not a
historical accident (such as if it was initially static, then made
extern because some other code, which no longer exists, needed it).

Which one is the case in point, only an investigation into "cvs
annotate" or "git annotate" can tell.  If such an investigation _was_
in fact done, it would be a good idea to present it here.

If it turns out that this function was extern from day one, then we
should discuss whether it indeed is worthy of being exported, instead
of defaulting to the "obvious" route based on its current users.

P.S.  This could be judged as bike-shedding, but if the issue is
serious enough to make a patch, it is serious enough to discuss, IMO.

Re: [obv] Make 'disable_display' static.

[Yao Qi]

On 01/11/2013 04:08 PM, Eli Zaretskii wrote:
>    . why is it a good idea to go hunting for functions not used outside
>      its source file and make them static?  I don't see this
>      requirement in any coding standards document pertinent to GDB.

During reading the code for other work, I find these functions and 
variables are not used outside of the file, so I am inclined to make 
them static, because it reduces the scope of the functions and variable, 
and accordingly reduces the difficulty on understanding the code (they 
are like non-public functions and can be ignored when figuring out the 
interactions between different modules).

>
>    . if this is NOT mandated by any coding standards we try to enforce,
>      why is this an "obvious" patch?

Of course, there is no coding standard about this.  As you questioned 
this patch, it is not obvious any more.  The "obvious" is interpreted as 
"there is no possibility that anyone will disagree with the change."

>
> The reason I'm asking is that, in general, whoever wrote that function
> could have judged it to be generally useful and export-worthy.  IOW,
> its non-static type might be a result of deliberate design, not a
> historical accident (such as if it was initially static, then made
> extern because some other code, which no longer exists, needed it).
>
> Which one is the case in point, only an investigation into "cvs
> annotate" or "git annotate" can tell.  If such an investigation_was_
> in fact done, it would be a good idea to present it here.
>

disable_display was extern when it was imported into CVS in 1999, but 
not be used out of printcmd.c.  I can't see the reason that original 
author left disable_display extern 14 years ago.

> If it turns out that this function was extern from day one, then we
> should discuss whether it indeed is worthy of being exported, instead
> of defaulting to the "obvious" route based on its current users.

 From time to time, we see patches that remove 'static' of functions, in 
order to get them used else where.  If other files use this function, we 
have to get it exported.  My rationale here is that, it is difficult to 
predict how functions are used in the future, get them 'static' as many 
as we can.

>
> P.S.  This could be judged as bike-shedding, but if the issue is
> serious enough to make a patch, it is serious enough to discuss, IMO.

The issue is not serious.  It is a "side product" when I read and hack 
the source.

-- 
Yao (齐尧)

Re: [obv] Make 'disable_display' static.

[Eli Zaretskii]

> Date: Fri, 11 Jan 2013 16:50:49 +0800
> From: Yao Qi <yao@codesourcery.com>
> CC: <gdb-patches@sourceware.org>
> 
> >    . if this is NOT mandated by any coding standards we try to enforce,
> >      why is this an "obvious" patch?
> 
> Of course, there is no coding standard about this.  As you questioned 
> this patch, it is not obvious any more.

Unless others overwhelmingly disagree with me (which won't be the
first time, when similar subjects are involved) and agree with you.

Thanks.

Re: [obv] Make 'disable_display' static.

[Joel Brobecker]

>   . why is it a good idea to go hunting for functions not used outside
>     its source file and make them static?  I don't see this
>     requirement in any coding standards document pertinent to GDB.

I think it is a good idea, because it helps us (developers) a lot
when we see that a variable or function is static, and thus only
referenced within the unit.

It also helps the compiler, because it is now able to notify us
when a symbol is no longer referenced, and thus a candidate
for deletion. Without making them "static", we don't get the
compiler warning.

More generally, I think that everything should be static/const
by default, and anything that is not needs to explained (when
not obvious, or course).

>   . if this is NOT mandated by any coding standards we try to enforce,
>     why is this an "obvious" patch?

I do not necessarily consider these patches obvious, because
I've seen emails on this list suggesting that we seem to be flexible
with uncontributed code which might be needing the symbol to
be exported rather than static.  But I think that they generally
go in the right direction and should be encouraged.

-- 
Joel

Re: [obv] Make 'disable_display' static.

[Tom Tromey]

>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:

Eli>   . why is it a good idea to go hunting for functions not used outside
Eli>     its source file and make them static?  I don't see this
Eli>     requirement in any coding standards document pertinent to GDB.

I don't hunt for these but I sometimes trip across them by accident.

Eli>   . if this is NOT mandated by any coding standards we try to enforce,
Eli>     why is this an "obvious" patch?

In general the less scope an object has, the simpler it is to reason
about it.  The "static" indicates immediately that it is private to the
file.

Eli> The reason I'm asking is that, in general, whoever wrote that function
Eli> could have judged it to be generally useful and export-worthy.

It's trivial to re-export an object should the need arise.

In fact I think it is better to have the discussion around exporting
objects than around making them static.  The default ought to be static,
as much as possible, to reduce the size of a module's API.

Tom

Re: [obv] Make 'disable_display' static.

[Pedro Alves]

On 01/11/2013 02:39 PM, Tom Tromey wrote:
>>>>>> "Eli" == Eli Zaretskii <eliz@gnu.org> writes:
> 
> Eli>   . why is it a good idea to go hunting for functions not used outside
> Eli>     its source file and make them static?  I don't see this
> Eli>     requirement in any coding standards document pertinent to GDB.
> 
> I don't hunt for these but I sometimes trip across them by accident.
> 
> Eli>   . if this is NOT mandated by any coding standards we try to enforce,
> Eli>     why is this an "obvious" patch?
> 
> In general the less scope an object has, the simpler it is to reason
> about it.  The "static" indicates immediately that it is private to the
> file.
> 
> Eli> The reason I'm asking is that, in general, whoever wrote that function
> Eli> could have judged it to be generally useful and export-worthy.
> 
> It's trivial to re-export an object should the need arise.
> 
> In fact I think it is better to have the discussion around exporting
> objects than around making them static.  The default ought to be static,
> as much as possible, to reduce the size of a module's API.

I agree.

On 01/11/2013 11:32 AM, Joel Brobecker wrote:

> It also helps the compiler, because it is now able to notify us
> when a symbol is no longer referenced, and thus a candidate
> for deletion. Without making them "static", we don't get the
> compiler warning.

I agree.  That's why we use "-Wunused-function", and part of
the reason for -Wmissing-prototypes too.

-- 
Pedro Alves

Re: [obv] Make 'disable_display' static.

[Gary Benson]

Tom Tromey wrote:
> In fact I think it is better to have the discussion around exporting
> objects than around making them static.  The default ought to be
> static, as much as possible, to reduce the size of a module's API.

I agree.  Aside from what Tom said, making functions static marks them
as local.  If I touch some code using a static function I tend to look
into it a bit more--how many times is it used, can I refactor it, might
I change the parameters to save work, that kind of thing.  I tend not
to do this kind of investigation for external functions unless I have
a very compelling reason.

Cheers,
Gary

-- 
http://gbenson.net/