summaryrefslogtreecommitdiff
path: root/m4
diff options
context:
space:
mode:
authorVito Caputo <vcaputo@pengaru.com>2023-05-07 20:05:38 -0700
committerVito Caputo <vcaputo@pengaru.com>2023-05-11 15:18:02 -0700
commita409d9fd5d861d52dca0e4ed33416a49b00ae2d9 (patch)
tree64ca214e83102051c265c5cb1006de6b168308c4 /m4
parentf4e29c7923960d3cc6af73b3c66498cf9b2d6f38 (diff)
setup: constify settings passed to setup_func
setup_func isn't formally defined for libtil, but setup_interactively() defacto establishes it and til_module_t.setup() reflects the same signature and calling convention except with til_settings_t constified. This change makes them all consistent in this regard, but there should probably be a formal typedef added for the function. The reason for constifying this is I don't want setup functions directly manipulating the settings instance. In the case of rototiller::setup_interactively() we ensure the stdio-based interactive setup is always the side doing the manipulation of the settings. For a libtil-user like glimmer, it's slightly different beast with GTK+ in the loop, but by preventing the setup_funcs from messing directly with the settings (instead having to describe what they want done iteratively), the front-end always gets its opportunity to maintain its state while doing the described things. Of course, this is mostly a lie, and within libtil the constified til_settings_t gets cast away to modify it in places. But keeping that limited to within libtil is tolerable IMO. We just don't want to see such casts in module code.
Diffstat (limited to 'm4')
0 files changed, 0 insertions, 0 deletions
© All Rights Reserved