[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
snmpconf language recommendations
>>I would like to make some recommendations for the
>>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 */
>>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
>>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.