ntpsec | Converted stat_count struct to a module level global. (!1026)

Ian Bruene ianbruene at gmail.com
Wed Aug 28 18:38:03 UTC 2019



On 8/28/19 1:26 PM, Hal Murray wrote:
> Merge Request !1026 was merged
>
> The Subject says "Converted stat_count struct to a module level global"
>
> The code looks like it is un-struct-ing things.
>
> Was that "a module level global" supposed to be "module level globals"?

!1026 moves the variables from a struct defined globally for the entire 
program to a struct defined globally within a single module 
(ntp_proto.c). Most usage of those fields is in that module, and almost 
all of the exceptions are reads in ntp_control. Now all access from 
outside of ntp_proto is done via functions.

> What's the policy on this area?  I thought the general idea was to put things
> into structs, but I never saw a good story on why that's a good idea.

The general idea is to remove as many globals as possible. The first 
pass of that process is to turn groups of associated global variables 
into structs that are defined at the same level as the original 
variables. Now I'm taking some of those structs and where possible 
reducing their footprint within the program, and insulating different 
modules in the possible.

> Is the problem one of name space structure/clutter?  If I'm reading the code,
> there isn't any difference between foo.counter and foo_counter.  The actual
> names used are critical.

It is reducing unnecessary globals because globals are a good thing to 
reduce. Also it is preparation for the Go port.


-- 
/"In the end; what separates a Man, from a Slave? Money? Power? No. A 
Man Chooses, a Slave Obeys."/ -- Andrew Ryan

/"Utopia cannot precede the Utopian. It will exist the moment we are fit 
to occupy it."/ -- Sophia Lamb

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ntpsec.org/pipermail/devel/attachments/20190828/e678c4dc/attachment.htm>


More information about the devel mailing list