On Thu, Aug 24, 2023 at 12:14:20PM -0700, Thangalin wrote:
> For our use case, we end up performing a lot of string comparisons to
> determine the state of the system via libchrony. Also, we must duplicate
> string constants. This is due to message.c containing values that are
> "hidden" from our application. Namely, the sources_state_enums:
>
> https://gitlab.com/chrony/libchrony/-/blob/main/message.c#L67
>
> Ideally, we'd be able to compare the integer values, rather than the
> strings. This would enable us to drop the duplicated string constants and
> no longer perform string comparisons.
Are you concerned about performance? I think you could hash the
strings into integers if you need faster lookups.
The idea for the API was that it wouldn't need to be changed when
existing reports are extended with new fields or new reports are
added, so applications like chronyc would not even need to be
recompiled.
> static const Constant sources_state_enums[] = { {
> CHRONY_SOURCE_SELECTED, "Selected" }, { CHRONY_SOURCE_NONSELECTABLE,
> "Nonselectable" }, { CHRONY_SOURCE_FALSE_TICKER, "Falseticker" }, {
> CHRONY_SOURCE_JITTERY, "Jittery" }, { CHRONY_SOURCE_UNSELECTED,
> "Unselected" }, { CHRONY_SOURCE_SELECTABLE, "Selectable" }, { 0 }};
>
> Or perhaps even eliminating the dependency on strings altogether in the API
> in favour of enumerated values? Offering a lookup for the values would
> still be useful, and even internationalizable.
We can do that if there is a major benefit for the applications, but
I'd prefer simplicity and less code to maintain.
--
Miroslav Lichvar
--
To unsubscribe email chrony-dev-requ...@chrony.tuxfamily.org with "unsubscribe"
in the subject.
For help email chrony-dev-requ...@chrony.tuxfamily.org with "help" in the
subject.
Trouble? Email listmas...@chrony.tuxfamily.org.
