🚀 go-pugleaf

In article <8908211701.AA23169@Neon.Stanford.EDU>, robert@NEON (James R. Kennedy) writes:
>The following illustrates two bugs in g++ version 1.36.0- (version as
>of 2:33 AM PDT, Monday 21 Aug). Sun4, SunOS 4.0.
>
>Bug 1: Variable-length array parameters broken (see p. 46 of manual).
>Bug 2: Segmentation violation rears its ugly head again.
>
>------------------ begin winge.cc -----------------------
>#include <stream.h>
>
>void gripe(char c[a], int a)
>
>{
>cout << c[0];
>}
>
>
>main()
>
>{
>gripe("T", 2);
>}
>------------------- end winge.cc -------------------------

Several points:

1.  Even if variable-length array parameters *did* work in G++, you've
    incorrectly used them in function `gripe'.  Variable length array
    parameters are actually a GCC extension, and your example would
    need to be re-written as:

    void gripe(int a, char c[a]) { /* ... */ }

    to work there.  Note that you must declare the `a' BEFORE trying
    to use it as the size-specifier in GCC.  If you think about how
    this is parsed (i.e., left-to-right) the semantics make sense.

2.  This extension does not yet work with G++.  Upon reflection,
    you'll probably see the dilemma facing C++ (that does *not* face
    GCC).  The problem is default parameters.  For example, consider
    the following cases:
    
    const int a = 10;

    /* Should print 10, regardless of what the value of the
       actual parameter for the first argument is, since default
       parameters ignore other names in the parameter list. */
    void gripe1 (int a, int j = a) { printf ("%d\n", j); }

    /* b[a] is a 10 character array of char, independent of what
       int a is! */
    void gripe2 (int a, char b[a]);

    So the problem with supporting that GCC extension in G++ is that
    can't necessarily throw parameters names into the symbol table
    while parsing the formal parameter list, since you might end
    up hiding global names that should be used according to the
    C++ default parameter semantics.
    
    If anyone sees a clean way around this that supports both
    the C++ semantics and the GCC extension semantics I'd like to
    hear it!
    
3.  The g++ manual is incorrect, I'll make that change.

  Doug
--
Master Swordsman speak of humility;             | schmidt@ics.uci.edu (ARPA)
Philosophers speak of truth;                    | office: (714) 856-4034
Saints and wisemen speak of the Tao of no doubt;
The moon, sun, and sea speaks for itself. -- Hiroshi Hamada