This is the mail archive of the gdb-patches@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [obv] Make 'disable_display' static.


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 (éå)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]