It’s a little bit of both (error and style). Gcc does warn about ‘set-and-not-used’, and similar, which are technically valid, but in many cases indication of wasted work. Same here - positioning the strlen inside the condition, can lead to lot of unnecessary work.
Given pattern is easy to detect (I think) - suggesting putting it into the compiler. Static analysis code can go deeper - identify parts of loop body (and condition) that can be extracted from the loop and executed once. Hi believe this is a case of common sub expression elimination - but it might be hard for the compiler to prove string is not being updated thru any other path, pointer, …, practically easier to flag it out. I will submit similar request to static tools that I’m using, hope they can identify the more general cases. Yair. Sent from my iPad > On Sep 22, 2025, at 16:02, Iain Sandoe <[email protected]> wrote: > > > >> On 22 Sep 2025, at 13:54, David Malcolm via Gcc <[email protected]> wrote: >> >>> On Mon, 2025-09-22 at 09:29 +0300, Yair Lenga via Gcc wrote: >>> Hi, >>> >>> I've inherited an old code base of "C" code, which was maintained by >>> relatively inexperience team. One of the common pattern that I've >>> seen was: >>> >>> for (int i=0 ; i < strlen(s) ; i++) { ... } >>> >>> Which has O(n^2) performance, given O(n) performance on s. Acceptable >>> on >>> strings up to 400-500 characters, but painful when large strings - >>> 4k. >>> >>> My question: Is there a path to add new performance-related >>> diagnostics for >>> those cases, in general, any function with expected O(n) in the >>> condition/step of a loop (for ; while ; do ... while) should trigger >>> this >>> warning. The most common pattern that I've seen - I believe other >>> pattern >>> also exists - with strchr, strstr, ... >>> >>> Ideally, this will come with an annotation that can be placed on >>> function >>> to say "I'm expensive, should not be called in a tight loop" >>> >>> [[GNU:expensive]] const int count_something(const char *x) ; >>> >>> which will result in a performance warning on >>> for (int i=0 ; i<count_something(s) ; i++) >>> >>> Looking for feedback, and suggestion on how to get something like >>> that >>> implement - is this something that will be useful ? >> >> Ignoring the attribute idea for now, I think it's relatively easy to >> implement detection of the special-case of >> >> for (int i=0 ; i < strlen(s) ; i++) { ... } >> >> as a gimple pass: we already have loop analysis code which can turn a >> function's CFG into a tree of nested loops, you then iterate through >> the relevant gimple stmts looking for a gimple_call to >> __builtin_strlen, and then issue a warning if you see one. >> >> That might in itself be useful to you (and maybe others?), and might >> serve as a prototype from which a more general warning could be built. >> >> As others have noted, the iterator variable should be size_t, not int, >> but that's a different issue (does it lead to an infinite loop with >> wrapround if you have a string longer than 2^32 chars?) > > Perhaps style-checking / linting type actions are better suited to static > analysis than to compiler warnings, per se. > > Sort of rule-of-thumb > - the compiler should be emitting warnings/errors if one does something > that is not correct standards-wise. > > - style-checking/linting/analysis can be much wider and help catch things > that are legal (sandards-wise) but not sensible (coding-wise)? > > 0.02GBP, only, > Iain >
