Daniel Stenberg <[email protected]> writes: > On Tue, 28 Jul 2009, Simon Josefsson wrote: > >> In both places the function code is very long and takes time to >> read, so it isn't immediately obvious that the use is safe (it >> probably is). But setting the variable to NULL at initialization >> silence the warning and appears safer to me. Objections to pushing >> this? > > I'm in favour.
I've pushed the patch. > Fixing warnings is a worthy task! I think there is a limit to it, though. Sometimes the warnings are stupid and fixing them results in slower and/or worse code. Sometime the warnings are caused by broken system headers. Where to draw the line is largely a personal preference, I suspect. My preference is to attempt to silence all warnings or file bugs on the compiler/system about problems, but sometimes this can be painful. FWIW, there are some other warnings I didn't care to investigate. They only happens with i586-mingw32msvc-gcc (v4.2.1). kex.c:1024: warning: dereferencing type-punned pointer will break strict-aliasing rules kex.c:1070: warning: dereferencing type-punned pointer will break strict-aliasing rules kex.c:1809: warning: dereferencing type-punned pointer will break strict-aliasing rules userauth.c:558: warning: dereferencing type-punned pointer will break strict-aliasing rules userauth.c:734: warning: pointer targets in assignment differ in signedness userauth.c:736: warning: pointer targets in assignment differ in signedness userauth.c:738: warning: pointer targets in assignment differ in signedness userauth.c:1081: warning: pointer targets in assignment differ in signedness userauth.c:1083: warning: pointer targets in assignment differ in signedness userauth.c:1085: warning: pointer targets in assignment differ in signedness /Simon _______________________________________________ libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
