Daniel Stenberg wrote:
> On Mon, 25 Feb 2008, Michal Marek wrote:
> I'd like that very much. Have you found any obvious downsides with enabling
> this for everyone that has the suitable gcc version when they build their
> libcurl-based apps?

Another "downside" or rather "why it shouldn't go in as is": The
warnings work by declaring a function with __attribute__((warning ("some
warning"))). For the warning to be emitted, the function has to be
actually called - defining it inline allows gcc to optimize the call and
thus the warning away. I worked around this by defining another dummy
function and marking the warning functions with __attribute__((alias
("_curl_err_hack"))). But this solution has two problems:
 - it happens to work with gcc 4.3, but it can happen that a future
   gcc version will be smart enough to optimize even these calls away
 - the manual says that the alias attribute doesn't work on all targets
   (without specifying). So we would need to restrict the typechecker
   only to architectures where alias is supported.

One cleaner way to do it would be to add a dummy function to libcurl API
/ ABI and call this one from the warning functions:

/* in libcurl */
void curl_err_dummy(void) {}

/* in the header */
void curl_err_dummy(void);
static void _curl_easy_setopt_err_long(void) __attribute__((warning
  ("curl_easy_setopt expects a long argument for this option")))
  __attribute__((noinline)) { curl_err_dummy(); }

I would work with any existing libcurl function of course, but with an
unnecessary overhead.

...

_Another_ way (which I just found a few minutes ago in the gcc manual)
seems to be:

static void _curl_easy_setopt_err_long(void) __attribute__((warning
  ("curl_easy_setopt expects a long argument for this option")))
  __attribute__((noinline)) { __asm__(""); }

This seems to work with any optimization level and has so far the lowest
overhead (just a call - ret pair and this is generated only if the
warning is issued).

Michal
Received on 2008-02-26