UpnpResolveURL allocates a buffer, copies it to my buffer, and then frees it. Why not give me the pointer directly?

Bug #648506 reported by Radu Cristescu
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
libupnp (Ubuntu)
Fix Released
Undecided
Unassigned

Bug Description

These lines are in libupnp-1.6.6/upnp/src/api/upnptools.c

    // There is some unnecessary allocation and
    // deallocation going on here because of the way
    // resolve_rel_url was originally written and used
    // in the future it would be nice to clean this up

I was looking here because I wanted to know how thread-safe this function is. Thread safe it is, but now that I've seen this, I have to request this to be added to the API:

int
UpnpResolveURL2( IN const char *BaseURL,
                IN const char *RelURL,
                OUT char **AbsURL )
{
    if( RelURL == NULL || AbsURL == NULL )
        return UPNP_E_INVALID_PARAM;

    *AbsURL = NULL;

    *AbsURL = resolve_rel_url((char*) BaseURL, (char*) RelURL );

    if( *AbsURL == NULL ) {
        return UPNP_E_INVALID_URL;
    }

    return UPNP_E_SUCCESS;

}

Can you please add this in a future version? I wonder why it wasn't done like this to begin with, since resolve_rel_url was already doing it this way.

Related branches

Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package libupnp - 1:1.6.17-1.1

---------------
libupnp (1:1.6.17-1.1) unstable; urgency=high

  * Non-maintainer upload.
  * libupnp6-doc Replaces libupnp3-dev (closes: #670894)

 -- Julien Cristau <email address hidden> Tue, 08 May 2012 16:59:14 +0200

Changed in libupnp (Ubuntu):
status: New → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.