Multiple fixes for issues found by Cppcheck

[Nekto89]

Cppcheck 1.83
Mostly reducing scope of variables.

[bagder]

Remember 'make checksrc':

./lib506.c:134:2: warning: Trailing whitespace (TRAILINGSPACE)
   
  ^
./lib512.c:39:2: warning: Trailing whitespace (TRAILINGSPACE)
   
  ^
./lib556.c:74:4: warning: Trailing whitespace (TRAILINGSPACE)
     
    ^
./lib586.c:102:2: warning: Trailing whitespace (TRAILINGSPACE)
   
  ^

[Nekto89]

I should have thought of something like this
git ls-files -z -- '.c' '.h' | xargs -0 sed -i 's/ +$//'
instead of manually fixing files from error logs

[bagder]

I disagree with this. We basically "always" use 'data' for the Curl_easy handle pointer so it would introduce confusion by making this function an exception!

[Nekto89]

so should I change .h file instead?

[bagder]

yes I think so, thanks!

[bagder]

why is this desired?

[Nekto89]

https://github.com/danmar/cppcheck/blob/7b106c067aa85e56116d24785e78da102bbb4114/lib/checkother.cpp#L2425

[bagder]

Thanks for the reference. So NULL can be an integer like 0 or 0L according to ANSI C, but POSIX says The macro shall expand to an integer constant expression with the value 0 cast to type void *.

But if we would take this to heart all calls to all curl_*_setopt() functions with a NULL need that NULL typecasted and I would find that awefully annoying and ugly. The mere fact that no user ever had a problem with this construct is also a pretty strong indication that there really isn't any modern >32 bit system that uses a NULL that isn't a pointer.

A modern compiler would also warn on our code all over if NULL wasn't a pointer and we've never seen such compiler warnings.

All this taken into account, I think we should leave our NULL pointers non-casted, even in the setopt functions.

[bagder]

I don't think this helps...

[Nekto89]

1 test failed. But before last 3 commits it wasn't failing. They shouldn't change behavior at all.

[bagder]

Correct, that test 1455 has showed up as a failure intermittently lately and is unrelated to your changes.

[bagder]

Thanks!