[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 */
>         code
>         */

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
>be incremented.

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 
sprintf function.

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.
>Ray Byler

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
Pablo Halpern                      http://www.halpernwightsoftware.com