[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: snmpconf language recommendations
At 12:51 PM 4/2/01 -0400, you wrote:
> >>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 */
I understand this reasoning and I sympathize. However the ISO C and C++
standards explicitly forbid this. It is NOT up to the compiler. The fact
that some compilers allow it (usually with a command-line option) does not
make it standard. (Never use a compiler to determine what is standard; they
often do many non-standard things.)
> >>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
You're right, of course, sprintf modifies its first argument, therefore the
first argument should be pass-by-reference. I don't have the draft in front
of me, but if sprintf does not have a pass-by-reference first argument,
then it is an oversight. It certainly is intended to be modified by the
I agree that the format string should be compared for validity against the
argument list. C allows this but doesn't require it. We should require it,
since the alternative is undefined behavior (e.g. a crash).
I also agree about the meaning of A++, but this has nothing to do with
pass-by-reference. The side-effect takes effect independently of the
function call, whether the argument is pass-by-reference or pass-by-value.
In fact, A++ is not a valid argument for [non-const] pass-by-reference (it
is an r-value and so must be considered immutable). So I'm not really sure
what you're asking for.
> >>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.
If something is not specified in the ISO C/C++ standard, one can argue that
specifying it ourselves is a deviation from C/C++. I will not make that
argument, though, since, as you see in my previous point regarding sprintf
arguments, I believe there are sometimes good reasons to specify something
that is left unspecified in C/C++.
However, I do not think this is a particularly useful thing to specify.
Making obscure code with multiple side-effects on the same variable work
consistently is not high in my priority list. As a compiler/interpreter
implementor, I can tell you that restricting the order of evaluation of
function arguments does, indeed, tie my hands. Calling a function typically
involves evaluating each argument and pushing it on the stack before
transferring control to the called function. I may very well want to push
arguments on in reverse order (most C compilers do this) and, to make my
compiler simpler, I will evaluate each argument just prior to pushing it on
the stack. This will cause the evaluation order to be exactly the reverse
of what you propose. If we accept your proposal, I need to do a redesign.
This is what I mean by tying my hands.
Pablo Halpern http://www.halpernwightsoftware.com