Re: draft minutes from the sming interim:

[Andy Bierman <abierman@cisco.com>]

At 05:35 PM 6/29/2002, David T. Perkins wrote:
>HI Andy,
>
>We really need compiler directives in a standard format.

I'm still not convinced, but if we do, it's not something
that belongs in the SMI.


>There are several examples of RFCs that contain MIB modules that
>the ADs know are illegal. And they are published anyway! Why,
>because illegal stuff was put it, it wasn't checked, agents
>and managers used it, and to change it to make it legal would
>be a bigger impact than to fix it. Directives would be one way
>to flag such illegal usage.

I would rather spend the effort to fix the MIB errors, then
to flag the errors.


>I share your concern about readability, and don't want to negatively
>impact readability. But there really is a need for a standard
>way to specify compiler directives, and to have a few standard
>ones. If you do not feel that it is appropriate to have directives
>defined as part of the language (like that is with the definition
>with ANSI-C), then we can create a separate document that is
>for compiler writers that defines the directives. Also we
>can say that RFCs cannot contain modules with compiler directives.
>Then later on after some experience, we can decide if it makes
>sense to keep the documents separate or to combine them.
>
>Can you live with this approach?

I agree with Randy that directives for specific tools belong outside
the MIB file. If there were a small number of universally useful
directives, then I suppose putting them in comments would be
acceptable. (Note that even ANSI directives like /*ARGSUSED*/
are encoded in comments.) This doesn't mean I'm interested
in working on this list of directives, but I wouldn't object
if others wanted to work on it. I would object to CPP
functionality like #if and #define, because they are easily abused,
and would diminish readability.


>Regards,
>/david t. perkins

Andy