Re: draft minutes from the sming interim:

["David T. Perkins" <dperkins@dsperkins.com>]

HI,

In my experiences with computer languages it is really useful to
have simple "preprocessor-like" directives as part of the language
definition. Having to rely on a third party preprocessor app
presents problems.

Also, having a standard way for specifying compiler directives,
with some being specified as part of the language definition
and others that are compiler specific (and ignored by other
compilers) is in the middle between a very desirable item or
required item.

Likewise, a well defined and standard annotation mechanism as
part of the language is really very useful. There are several
examples of the annotation that exist in commercial products
such as the MIB compiler from Epilogue (WindRiver) to assist
in generation of code for SNMP agents, and from Novell and HP
to provide additional information about notifications.

Addition comments inline...

At 10:22 AM 6/28/2002 +0200, Juergen Schoenwaelder wrote:
>>>>>> David T Perkins writes:
>
>David> On the question of comments, I believe the ASN.1 style is
>David> horrible and should be changed.
>
>Dave, it would be helpful if you make concrete proposals to what
>it should change.
The three problems with ASN.1 comments are 
1) use of "--" to delimit comments
2) using the same chars to both start and terminate comments
3) comments cannot be continued over more than one line

So, having both C-style comments of:
   1) "/*" <comment_text> "*/" and
   2) "//" <comment_text> <EOL>
would be a welcome change.

>David> Also needed are directives to compilers, such as that performed
>David> by #if/#ifdef to comment out sections of code.
>
>#if/#ifdef are preprocessor symbols. You can already run your MIBs
>through cpp if you like. The rationaly of not using # as a comment
>character in SMIv3 was to not conflict with common preprocessor
>notations. In other words, I doubt there is much to do here.
It really impacts portability of code to require use of a third
party C preprocessor. You have configuration issues, temp file
issues, different ways to cause a program to be run on different
systems, etc. 

>David> Likewise, directives to help tell the compilers about checking.
>
>With smilint, I never really felt a need for it. The only reason I can
>see would be to flag certain situations where you know the compiler
>will complain but which you can't fix for e.g. backward compatibility.
>But even these cases are IMHO rare and there are other simpler ways to
>handle this (e.g. put a comment that into the document which explains
>the situation).
With SMICng there are many compiler directives to control checking.
Because there is no standard way to specify directives, and there
are no standard directives, users of SMICng must specify the checking
directives on the command line (or environment variable) to SMICng,
or create wrapper files containing directives which then include
the MIB file. I don't want to modify a MIB file so that it cannot
be used by another compiler. This means that the directives are
at the module level. It would be much better to specify the
directive around the particular construct in a MIB module. This
helps the reader of a MIB module by "pointing out" usage
that is questionable (maybe for backwards compatibility),
or providing a hint for unusual usage.

Regards,
/david t. perkins