Ref: https://curl.se/mail/lib-2022-02/0042.html

#define CONSTLEN(x) x,sizeof(x)-1

I'm not a fan of this style because it hides a parameter behind a macro. I'd rather we just leave the strlens but judging by that e-mail thread I seem to be in the minority.

I'm not a fan of this style because it hides a parameter behind a macro. I'd rather we just leave the strlens but judging by that e-mail thread I seem to be in the minority.

I'm generally against hiding code behind macros, but I find @HenrikHolst's argument about not having to repeat the string convincing. I can't think of a better way to do this change than what is being proposed here, so I'm a 👍 on it.

Not sure if this is the proper channel to continue this discussion in this manner but if/when this patch gets accepted then I have also identified a few other areas where the CONSTLEN macro will be useful.

One such case is many calls like this:
result = Curl_dyn_add(&stream->header_recvbuf, "\r\n");

That should either be changed to:
result = Curl_dyn_addn(&stream->header_recvbuf, "\r\n", 2);

Or my preferred way:
result = Curl_dyn_addn(&stream->header_recvbuf, STRCONST("\r\n"));

And I would prefer to do it that way (but I can do it the ,2 way if people tell me to) so that if the string is changed we are sure that the length is also changed.

And before the optimizing compiler comes up again, I have compiled curl with -O3 and still a trace gives:

            [226428] |                       Curl_http_bodysend() {
            [226428] |                         Curl_dyn_add() {
   0.180 us [226428] |                           strlen("^M\n") = 2;
            [226428] |                           dyn_nappend() {
   0.190 us [226428] |                             memcpy(0x557fb893f2cf, &__PRETTY_FUNCTION__.11279, 2);
   0.471 us [226428] |                           } /* dyn_nappend */
   1.143 us [226428] |                         } /* Curl_dyn_add */

So at least GCC does not magically switch to use the CUrl_dyn_addn function instead. We can also see the cost here, it's 0.180 µs on my Ryzen 1600X even for such a small string so even if we reduce the amount by say 10 such small strlen:s we are still only talking about saving ~2µs so the savings are not enormous, but they are there.

result = Curl_dyn_addn(&stream->header_recvbuf, STRCONST("\r\n"));

I could live with this approach. This would just become a standard internal macro we would learn to live with and use. I think STRCONST() might be a better name than CONSTLEN().

I agree that STRCONST is the better name so I've changed it in the pull request.

Thanks!