[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf 11. Setcli accessor function - Item to be resolved o n email list
At 11:03 AM 1/25/01 -0500, Jon Saperia wrote:
>> 2) We favor an explicit definition in the document as to how vendor
>> extensions, if any, can be added in a way that does not interfere with
>> how this mechanism is meant to operate.
>Mike, as you know I am attempting to see what type of consensus there is
>on the Setcli issue. As I think about it, the sentence you wrote above
>is not quite clear to me. Can you add a bit more explanation?
I favor an explicitly clear definition as to the boundry between standard things
and vendor added things.
As an example, the C Language Spec: ISO IEC C 9899:1999
Section 7.1.3 provides for ways for vendors to introduce extensions:
- All identifiers that begin with an underscore and either an upppercase letter
or another underscrore are always reserved for any use.
- If the program declares or defines an identifier in a context in which it
it is reserved (other than allowed by section 7.1.4), or defines a reserved
identifier as a macro name, the behavior is undefined.
The Microsoft C++ compiler was thus able to introduce various extensions
such as their support for 64 bit integers prior to the current C standard
by using the data type: _int64
The characteristic I most like is that its easy to determine
what is non-standard.
I think we should avoid vendor extensions if possible by having a
fully functional model but I don't want to rule them out if someone wants
to try something out.