Subject: subidwrite/substr draft-ietf-snmpconf-pm-05.txt questions

From: Steve Moulton <[email-masked]>
Date: Mon, 14 May 2001 17:14:28 -0400

A couple of questions have come up in implementing the policy language.

. Page 48, 49, draft-ietf-snmpconf-pm-05.txt, para 9.4.7:

  subidwrite returns -1 on error.  What does subidwrite 
  return if there is no error?

. Page 52, draft-ietf-snmpconf-pm-05.txt, para 9.4.16:

    string substr(string &str, integer offset,
                  integer len [, string replacement])

   The substr prototype only shows the replacement argument as
   optional, but the description says that len may be omitted (to
   get the rest of the string after offset regardless of length).
   The len argument is not bracketed in the prototype.

   It makes sense to be able to specify the replacement string
   without the length (replace everything starting at offset), but
   one must intuit the argument types to figure out to which 
   argument the third string must be assigned.

   I see two choices here:

   .  Remove the replacement functionality from this function. 
      String replacement is orthogonal to extracting a substring.
      At the risk of cluttering up the language, I think this is
      the correct solution.

   .  Make the len argument nonoptional when doing string replacement.
      This means that one is always going to have to think about
      len (i.e., there is no way to specify "replace everything after
      offset 5 with this string, expanding or contracting the 
      string as necessary).  I guess just supplying a huge value
      would be adequate.

	- Steve

---
Steve Moulton        SNMP Research, Inc            voice: +1 865 573 1434
Sr Software Engineer 3001 Kimberlin Heights Rd.    fax: +1 865 573 9197
[email-masked]     Knoxville, TN 37920-9716 USA  http://www.snmp.com

---

From: Pablo Halpern <[email-masked]>
Date: Tue, 15 May 2001 10:50:28 -0400

>       At the risk of cluttering up the language, I think this is

I think a separate replace() function would be cleaner, but it has the same 
issue wrt the length argument unless you move the length argument AFTER the 
replacement string, which is pretty non-intuitive if you ask me.

>       string as necessary).  I guess just supplying a huge value

I think this is what we will need to do, whether we separate the replace 
functionality into a separate function or not.  If we keep replacement 
functionality in the substring function then the only change would be 
editorial: put the length in brackets along with the replacement string, i.e.:

     string substr(string &str, integer offset
                   [, integer len [, string replacement] ] )

- Pablo
----------------------------------------------------------------------
Pablo Halpern                      http://www.halpernwightsoftware.com
[email-masked]