Subject: typo in RFC 2614?

From: james woodyatt <[email-masked]>
Date: Wed, 21 Jun 2000 18:16:36 -0700

comrades--

This has probably already been observed...

RFC 2614 seems to be internally inconsistent about the SLPParseSrvURL
function in the C binding.  It says, in its Description subsection,
that the caller should free the structure referenced by pcSrvURL using
the SLPFreeURL() function, which is otherwise not mentioned.  Other
references explicitly say that SLPFree() is the function to use for
this purpose.

(This came up while I was coding a Perl extension wrapper for the C
binding to Mini-SLP.)

Inspection of the code in the Mini-SLP reference implementation, which
actually doesn't implement SLPParseSrvURL() at all, does reinforce the
notion that this is a typographical error.  It offers no such
SLPFreeURL() function.

-- 
j h woodyatt <[email-masked]>  | "Never look at the trombones.
coder, foundation software        | You'll only encourage them."
enron broadband switching systems |     -Robert Strauss, on conducting

---

From: Erik Guttman <[email-masked]>
Date: Thu, 22 Jun 2000 10:20:59 +0200 (MET DST)

> notion that this is a typographical error.  It offers no such

Yes - we meant SLPFree() not SLPFreeURL().

Erik

---

From: Evan Hughes <[email-masked]>
Date: Thu, 22 Jun 2000 11:32:07 -0400 (EDT)

Speaking of typos, how are SLPGetProperty() and SLPSetProperty() to be
handled?

  On page 48 of RFC 2614, we are told that the return value of
SLPGetProperty() is owned by the API and cannot be freed. Doesn't this
result in a memory leak when a SLPSetProperty() is done and the previous
value is no longer necessary?

e

---

From: Matt Peterson <[email-masked]>
Date: Thu, 22 Jun 2000 10:18:43 -0600

> value is no longer necessary?

SLPGetProperty() returns a pointer to memory that was allocated by the
library when the default property values were set and configuration file
was read.  The pointer the is returned is a const char* which means that
you should not modify the data it points to.  There should be no
problems with memory leaks.

The bigger problem is that the pointer returned from SLPGetProperty()
even if used in read-only application, is still not safe.  Any given
call to SLPSetProperty() could invalidate the pointer (due to a
realloc).  Can you say dangling pointer?  Even doing a strdup() on the
returned pointer is not safe in multi-threaded environments. 

The OpenSLP workaround for the dangerous pointer problem is not to honor
SLPSetProperty().  This way we can be sure that the pointers returned by
SLPGetProperty() will not be changed out from underneath the callers of
SLPGetProperty().

A better API would be:

char* SLPGetProperty(const char* propertyName, 
                     char** propertyValue);

/* memory is allocated by the library but freed with SLPFree() by the
caller */

Matt