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

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

Cleaning up some old email...

Steve Moulton wrote:
> 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?

Good call. I've modified this to say it returns zero if 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.

Substr is borrowed from perl where it has all these semantics (including
replace). I'd like to use it unchanged, if possible.

I like your second choice, or a third choice:

- the len argument must be present if the replacement argument is
present. This is the solution whenever there is more than one optional
argument to a function and there are many examples in this library.

I'd prefer #3.