[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 (齐尧)