Elia Pinto <gitter.spi...@gmail.com> writes:

> +static void curl_dump(const char *text, unsigned char *ptr, size_t size, int 
> nopriv)
> +{
> +     size_t i;
> +     struct strbuf out = STRBUF_INIT;
> +     unsigned int width = 80;
> +
> +     strbuf_addf(&out, "%s, %10.10ld bytes (0x%8.8lx)\n",
> +             text, (long)size, (long)size);
> +     trace_strbuf(&trace_curl, &out);
> +
> +     for (i = 0; i < size; i += width) {
> +             ...
> +             for (w = 0; (w < width) && (i + w < size); w++) {
> +                     if ((i + w + 1 < size) && ptr[i + w] == '\r'
> +                         && ptr[i + w + 1] == '\n') {
> +                             i += (w + 2 - width);
> +                             break;
> +                     }
> +                     strbuf_addch(&out, (ptr[i + w] >= 0x20)
> +                             && (ptr[i + w] < 0x80) ? ptr[i + w] : '.');
> +                     if ((i + w + 2 < size)
> +                         && ptr[i + w + 1] == '\r'
> +                         && ptr[i + w + 2] == '\n') {
> +                             i += (w + 3 - width);
> +                             break;
> +                     }
> +             }
> +             ...
> +     }
> +     strbuf_release(&out);
> +}

There is no change in this hard-to-read double-loop since the
previous round?

> +int curl_trace(CURL *handle, curl_infotype type, char *data, size_t size, 
> void *userp)
> +{
> +     const char *text;
> +     (void)handle;           /* prevent compiler unused parameter warning if 
> checked */
> +     (void)userp;            /* prevent compiler unused parameter warning if 
> checked */

I really do not want to see these casts.  Unused parameters are
perfectly normal in a codebase with callback functions, no?  I do
not think these are the first occurrences of unused parameters in
our codebase, and I do not think we have such cast to void to them.
Why add this ugliness only to here?
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to