Hi Andy, > Date: 2026-11-13 16:44:08+0200 > From: Andy Shevchenko > > On Fri, Nov 13, 2026 at 02:11:17PM +0100, Alejandro Colomar wrote: > > The compiler should be able to optimize out the unused pointer > > arithmetic done at the end, so performance-wise this shouldn't change > > anything. > > If strprefix() is not inline how would it be done? Or I missed the point? But strprefix() is inline. > > This change de-duplicates the almost-identical implementations, > > and better shows the relationship between the two functions. > > ... > > > static inline bool strstarts(const char *str, const char *prefix) > > { > > - return strncmp(str, prefix, strlen(prefix)) == 0; > > + return strprefix(str, prefix); > > } > > There is no sense to keep strstarts() at this point. I agree. Actually, it seems my guess that strprefix() would be optimized out was wrong, because the kernel builds with -fno-delete-null-pointer-checks and other flags that prevent this optimization. > Can it be simply redefinition? I was thinking that we could just do a simple search and replace s/strstarts/strends/, prepending !! in some cases if needed. By 'redefinition', do you mean making strstarts() return a pointer instead of a bool? A problem with strstarts() is again the function name: it doesn't seem to naturally fit with a function that returns a pointer to the position. It also doesn't clarify whether it searches for a string, or for a list of characters (like for example strspn(3)). I prefer replacing strstarts()/strends() with strprefix()/strsuffix(). But if you prefer changing strstarts() to return a pointer, I'm also okay-ish with it. It's not a perfect name, but I can live with it. > However, after looking at the uses in the kernel, I prefer > to see the strprefix() be not implemented at all, just optimization against > strstarts()/strends() if required can be performed. I don't understand this last sentence. Cheers, Alex > > -- > With Best Regards, > Andy Shevchenko > > --