Suggestion - new warning

[David Brown]

On 22/09/2025 08:29, 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 ?
> 
> Yair
> 

gcc (and most C libraries used with gcc) already has a solution for 
making code such as your original pattern efficient.  "strlen" is marked 
with the attribute "pure", which tells gcc that the function has no 
side-effects and it can therefore in many cases move the call to 
strlen() outside the loop :

<https://godbolt.org/z/1r6sj3dnf>

I can understand that you feel it is poor practice to have the strlen 
call inside the loop - not every compiler can optimise as well as gcc - 
but I don't think it is easy to specify a warning such as you describe. 
How should it distinguish between a tight loop that calls your 
"expensive" function, and one that calls another function that happens 
to contain the "expensive" function?

It would certainly make sense in a coding standard to say that the 
limits in a for-loop should be calculated before the loop, but I suspect 
it would be very difficult to have good automatic tests on that.