This is unlikely be an issue in practice, exceeding 32-bit int's 0x7fffffff on a string is weird.
Writing as of 3471bd3
There are several places in the source where the result of strlen (size_t) is cast to signed int.
Apart from losing out on some maximum length, this introduces undefined behavior compared to unsigned int if it overflows when incremented later.
git grep -n strlen | grep int
core/carp_pattern.h:453: int lstr = strlen(str);
.
.
.
I'd fix it by using size_t instead of int, like elsewhere in the code (example core/carp_char.h:34).
Another possibility is to just use unsigned int here, which reduces the issue to truncation in some cases.
I'd only pick this if it was faster, which would be against my expectations.