[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#922384: jessie-pu: package gsoap/2.8.17-1+deb8u2

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

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.


Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply to: