On Wed, 23 Apr 2025, Patrick Monnerat via curl-library wrote:
These typechecks warning outputs get pretty damaged by the deprecation
warnings, because they include checks for deprecated options.
The initial code did take care of it successfully. What has changed since
then?
I don't think the intial code worked. I think the typechecks have been broken
for several years without anyone particularly noticing. I suspect they stopped
working at some point in the past in a gcc upgrade or something - as we don't
have tests verifying this correctly.
When I fix the typechecks, and I don't change anything regarding the
deprecation stuff, this is an example of a (fixed) warning when we use a
non-long to a setopt argument that expects a long on a 64bit system:
$ gcc -c -I ~/src/curl/include test-bad.c
In file included from test-bad.c:2:
test-bad.c: In function ‘main’:
/home/dast/src/curl/include/curl/typecheck-gcc.h:50:15: warning: call to
‘_curl_easy_setopt_err_long’ declared with attribute warning: curl_easy_setopt
expects a long argument for this option [-Wattribute-warning]
50 | _curl_easy_setopt_err_long();
\
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/dast/src/curl/include/curl/curl.h:54:7: note: in definition of macro
‘CURL_IGNORE_DEPRECATION’
54 | statements \
| ^~~~~~~~~~
test-bad.c:13:19: note: in expansion of macro ‘curl_easy_setopt’
13 | CURLcode res3 = curl_easy_setopt(curl, CURLOPT_TIMEOUT, 3);
| ^~~~~~~~~~~~~~~~
This can be compared to the header file without the deprecation details in the
header file:
test-bad.c: In function ‘main’:
/home/dast/src/curl/include/curl/typecheck-gcc.h:54:15: warning: call to
‘_curl_easy_setopt_err_long’ declared with attribute warning: curl_easy_setopt
expects a long argument for this option [-Wattribute-warning]
54 | _curl_easy_setopt_err_long();
\
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~
test-bad.c:13:19: note: in expansion of macro ‘curl_easy_setopt’
13 | CURLcode res3 = curl_easy_setopt(curl, CURLOPT_TIMEOUT, 3);
| ^~~~~~~~~~~~~~~~
Can you figure out a way to make it not yap about the deprecation even though
the option used is not deprecated? My WIP PR with fixes is here:
https://github.com/curl/curl/pull/17143
This made me realize that I don't think our deprecation warnings do a lot
of good and that they mostly just annoy me when I run into them.
"Annoying" people using these options (not you particularly!) was one of the
goal: this forces them to see something is bad even if they don't read the
doc, as this is the case very often. Code conversion is expected.
Of course. And I was all in favor of it.
Now however, I think it is too eager to point those out, even for things
that while we recommend another option, we still guarantee that we will keep
supporting the old thing virtually forever. So the warning feels... overdone.
You won't miss ANY of them with a compile-time detection, providing the
option is a constant.
Except of course that transitioning away might take time and during that time
you don't want the warnings so you disable them and then you can still miss
them. We do exactly this for c-ares deprecation warnings in curl builds.
--
/ daniel.haxx.se || https://rock-solid.curl.dev
--
Unsubscribe: https://lists.haxx.se/mailman/listinfo/curl-library
Etiquette: https://curl.se/mail/etiquette.html
