On Tue, Sep 21 2021, Jeff King wrote: > On Tue, Sep 21, 2021 at 02:45:16PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> I think that generally git's codebase could use going beyond just >> "const char *" when a "const char * const" would suffice, for some >> reason we seem to mostly use it for the static usage variables. > > I didn't dig up the references in the list archive, but I feel like > we've had this discussion long ago. One of the reasons not to do so is > that it pollutes the function's interface with internal details.[...] Are there cases in my conversion where the caller has to do anything special that they didn't before? These are also all static functions, so it's all internal details exported to nobody. > The caller does not care whether the function is going to modify the > pointer itself, because it is passed by value. Sure, it's for increased clarity of reading te function in question, not its although in one case we pass a ** so you can see what exactly we modify both from the callers and function perspective. > You could apply the same logic that we should be passing "const int", > and so on. Sure, in general I think churn like that isn't worth it, and "const char *" is usually good enough, even if it could be "const char * const" or whatever. I think it makes senes in this specific case where you need to read one function after another with "bol" and "eol" variables, with some treating their copy as immutable, others not etc. Particularly if we'd convert it to some other style (e.g. str/len) we can see if an entire chain of functions can all be safely changed over.
