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

snmpconf language recommendations




>>I would like to make some recommendations for the
>>policy language.
>>
>>1.  Nested comments should be allowed.

>C doesn't allow them, nor does C++. This doesn't seem like a particularly 
>worthwhile place to diverge from the base language.

C and C++ *DO* allow them. It depends on the compiler are to whether they are
implemented or not.  It makes it much easier to comment out
a block of code without worrying about an internal comment being included e.g.
        /*
        /* my original comment header */    
        code
        */

>>2.  Our implementation of sprintf(), unlike the C
>>     version, should make sure that the number of
>>     format specifiers in the format string matches
>>     the number of corresponding arguments.  Our version
>>     of sprintf(), unlike the C version (which is call
>>     by value), should be call by reference (to match the rest of
>>     the policy language).

>Why do you need call by reference in sprintf?  The & notation in the 
>description of functions means that the argument may be modified. sprintf() 
>doesn't modify any arguments.

Actually sprintf() does modify an argument, the destination string, but
I think you are referring to arguments to the format string.  The question,
then is whether arguments to the format string should have any
side effects.  I think they should e.g. if A++ is an argument to the
format string then A should be passed as an argument but then A should
be incremented.

>>
>>3.  The order of evaluation of arguments to function calls
>>     should be right-to-left.  This is unspecified in C.
>>     Right-to-left matches the gcc and Turbo C implementations.
>>     The following test program demonstrates how different
>>     compilers evaluate arguments.

>Again, I don't see this as a particularly worthwhile place to deviate from 
>C or C++.
>The example uses arguments with excessively interdependent side-effects. I 
>don't see that we need to tie the hands of the implementor in order to make 
>such things work consistently.

This is NOT a question of deviating from C/C++.  There is nothing in
C/C++ to deviate from.  This is another case where results depend on
the implementor.  This is not a case of tying the hands of the
implementor.  It's a case of clearly defining the standard.  Scripts 
should produce the same result under any compiler.

Ray Byler