On 2019-08-12 at 16:49:20, Junio C Hamano wrote: > "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > > > On 2019-08-12 at 00:32:26, Junio C Hamano wrote: > >> "brian m. carlson" <sandals@xxxxxxxxxxxxxxxxxxxx> writes: > >> > +static ssize_t stripped_path_suffix_offset(const char *path, const char *suffix) > >> > >> Perhaps > >> > >> static ssize_t last_path_component_offset(const char *path, const char *name) > >> > >> I am tempted to also call the second parameter to this function > >> "basename", as we know from the proposed log message that you wish > >> "basename" were usable for this purpose, but basename itself has > >> another confusing factor (i.e. "are we stripping ".exe" extension?", > >> to which the answer is no in the context of these functions). > >> > >> If we agree with the "last path component" phrasing, has_path_suffix() > >> would become something like: > >> > >> int last_path_component_equals(const char *path, const char *name); > > > > Except this is not necessarily the last path component. It could match > > one or more path components with the way the function is written. > > That's fair. Is the feature that allows the function called > ends_with_component*S* like Szeder suggests designed one, i.e. with > an explicit purpose of supporting callers that pass "foo/bar" as the > "suffix" to it, or is it merely that the implementation happens to > work that way, even though the expected use that is supported is to > pass only one level component but the implementation did not even > bother asserting that the "suffix" does not have a slash in it? Well, I split it out from a function that handles multiple path components, mostly so that I could leverage existing work (and not have to worry about getting it wrong). It wasn't explicitly intended that it support multiple components, since I don't require that for my implementation, but I could see future users taking advantage of that. I think "ends_with_path_components" might be the way forward, unless you think something else would be better. -- brian m. carlson: Houston, Texas, US OpenPGP: https://keybase.io/bk2204
Attachment:
signature.asc
Description: PGP signature
