lör 2019-02-16 klockan 22:05 +0000 skrev Ben Hutchings: > On Sat, 2019-02-16 at 06:43 +0100, Mattias Ellert wrote: > > lör 2019-02-16 klockan 00:12 +0100 skrev Chris Lamb: > > > Hi Mattias, > > > > > > > What exactly do you want to run past upstream? It is not clear to me > > > > what you are requesting here. > > > > > > Your change to the patch, no? :) > > > > > > > > > Regards, > > > > > > > OK. > > > > https://sourceforge.net/p/gsoap2/bugs/1236/ > > ...which has now been closed because "[t]his is not a public API > function but an internal one." But the function is declared in a > public header, and is exported, so I don't know whether this > distinction exists other than in the mind of the upstream developer... > > Ben. > Is the aim of this discussion still to determine which version of the proposed change to use? The original int version, or the updated ssize_t version? Or has the discussion derail into a general complaint about how strange upstream is behaving that will go on forever and thereby block fixing the issue? When upstream says that the function soap_encode_url is "private", this is true in as much as it is not called by code generated by the stdsoap2 program. Such code calls soap_encode_url_string not soap_encode_url. However, since the function is declared in the public header file it is not really private, and in theory it is accessible to be called by any code using the library. So using the ssize_t version that preserves the sizes of the arguments and return type of the function is the safer choice, regardless of upstream's claim that the function is private. Mattias
Attachment:
smime.p7s
Description: S/MIME cryptographic signature