It's mainly just for consistency. I don't feel particularly strongly about it in these cases, however in previous patch-sets I let similar things go, only for it later to become apparent that I shouldn't have.
Although these functions are not used in my upcoming patches, I suppose it's feasible that one day they could be used by callers that could make use of the result, so I'll look at amending that.
It certainly can't be left like this at the end of the patch-set. It might be ok (since this isn't exactly a core dll) to include the next patch so that the implementation doesn't regress as far as the tests are concerned.
OK, I can include the patch that will fix the TODO in the patchset, which I think would likely be the simplest way of resolving this.
Thanks,
Owen