[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:
>Mike 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.

Mike  MacFaden