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