@dscho, thanks for your PR! By analyzing the history of the files in this pull request, we identified @yangtse, @bagder and @rousskov to be potential reviewers.

This issue came up while working on #1601.

Coverage increased (+0.01%) to 73.823% when pulling 8a561d1 on dscho:fix-gnutls-build into 922f800 on curl:master.

unfortunately we don't have intptr_t in c89. we could use ptrdiff_t which is not technically correct since it's only meant to hold the difference between two members of the same array. it seems like casting between (gnutls_transport_ptr) would make more sense but it looks like those macros were added to fix the warning that comes from doing that.

/cc @gknauf

unfortunately we don't have intptr_t in c89.

Good point.

we could use ptrdiff_t which is not technically correct since it's only meant to hold the difference between two members of the same array.

I took this idea a little further: if we pretend that we have a hypothetical character array starting at NULL, we can convert an integer i to a pointer by taking the address of the ith element. Converting back is simply a matter of casting the pointer difference with NULL back to an int.

The patch was updated accordingly.

I verified that this fixes the compiler warning on Windows.

Coverage increased (+0.008%) to 73.819% when pulling d98824e on dscho:fix-gnutls-build into 922f800 on curl:master.

@jay @gknauf any chance you can have a look at this rather tiny PR? 😄

@jay any objection?

@jay any objection?

No. It seems like it's UB either way. To touch on what you said about 32 bits I think it could be improved if we rename them socket macros and cast to curl_socket_t since that's the type. Barring input from @gknauf how about these modifications to @dscho's work https://github.com/curl/curl/compare/master...jay:pr_1617_amended?expand=1 . I'm not sure if it would resurrect the warnings though

could be improved if we rename them socket macros and cast to curl_socket_t since that's the type

I like that. Also, the underlying socket type on win64 (SOCKET) is larger than int/long, so I think that makes a lot of sense. What do you think @dscho ?

@jay sadly, this does not work:

vtls/gtls.c: In function 'gtls_connect_step1':
vtls/gtls.c:69:27: error: invalid operands to binary + (have 'char *' and 'char *')
   ((void *) ((char *)NULL + (char *)(s)))
                           ^ ~~~~~~~~~~~
vtls/gtls.c:852:21: note: in expansion of macro 'GNUTLS_SOCKET_TO_POINTER_CAST'
     transport_ptr = GNUTLS_SOCKET_TO_POINTER_CAST(conn->sock[sockindex]);
                     ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~

I fixed that build error and amended jay@537b26c accordingly, force-pushing to the branch (and hence updating this PR).

Good to go?

👍 let's just first see that the CI doesn't find something unexpected

let's just fist see that the CI doesn't find something unexpected

Of course! ;-)

Coverage increased (+0.008%) to 74.011% when pulling 8c88e88 on dscho:fix-gnutls-build into 3a48a13 on curl:master.

Thanks!

Everything seems to pass ;-)

Oh, I missed that you closed this already. Sorry!