> Le 9 sept. 2025 à 21:32, Junio C Hamano <gitster@xxxxxxxxx> a écrit : > > Ben Knoble <ben.knoble@xxxxxxxxx> writes: > >>>> Le 8 sept. 2025 à 12:48, Junio C Hamano <gitster@xxxxxxxxx> a écrit : >>> >>> shejialuo <shejialuo@xxxxxxxxx> writes: >>> >>>> Callers of `get_entry_index()` are required to pass a non-NULL >>>> `exact_match` parameter to receive information about whether an exact >>>> match is found. However, in some cases, callers only need the index >>>> position. >>>> >>>> Let's allow callers to pass NULL for the `exact_match` parameter >>>> when they don't need this information, reducing unnecessary variable >>>> declarations in calling code. >>>> >>>> Signed-off-by: shejialuo <shejialuo@xxxxxxxxx> >>>> --- >>>> string-list.c | 6 ++++-- >>>> 1 file changed, 4 insertions(+), 2 deletions(-) >>> >>> I do not quite see the point of adding these conditional assignments >>> to clutter the control flow. What benefit do these callers gain by >>> not having to have a throw-away int variable on the stack and >>> passing its address to the call chain? >> >> Wouldn’t the point be that (at the cost of slightly more interesting library code) callers don’t need to introduce extra ceremony for results they don’t use? In other words, take the boilerplate and push it down rather than up? > > Yeah, but the point is in what situation does a caller *not* need to > be able to tell between "we found an existing one and this is its > index" vs "there is no such thing, but here is where it *would* fit > if it were placed in the array"? I do not think of any, so I > doubted if it makes much sense to complicate the interface to make > it optional. > Good question! Thanks for clarifying.
