Jonathan Nieder <jrnieder@xxxxxxxxx> writes: > ... But a quick test with gcc 4.8.4 > -O2 finds that at least this compiler does not contain such an > optimization. The overhead Michael Haggerty mentioned is real. Still, I have a feeling that users of string_list wouldn't care the overhead of single pointer NULL-ness check. - apply.c collects conflicted paths and reports them with fprintf(). - builtin/clean.c uses the function to walk the list of paths to be removed, and either does a human interaction (for "-i" codepath) or goes to the filesystem to remove things. - builtin/config.c uses it in get_urlmatch() in preparation for doing network-y things. - builtin/describe.c walks the list of exclude and include patterns to run wildmatch on the candidate reference name to filter it out. ... In all of these examples, what happens for each item in the loop seems to me far heavier than the overhead this macro adds. So...
