Mac Mania 2/MacMania 2.toast/Demo's/Tools&Utilities/Programming/Symantec C⁄C++ Defects Folder/Symantec C⁄C++ Defects

Text File | 1993-10-05 | 170.2 KB | 4,618 lines | [TEXT/KAHL]

      Symantec Development Tools Public Defect List

This information may be read, copied, distributed, etc., by
any means whatsoever, but it may not be modified in any way,
and it remains the property of Symantec Corporation.

The following is a list of confirmed defects in THINK C 6.0.1,
Symantec C++ for Macintosh 6.0.1 and Symantec C++ for
MPW 6.0.1.

Please note that "THINK C/C++" is used to refer to THINK C
6.0.1 and/or Symantec C++ for Macintosh 6.0.1.
Generated Tuesday, October 5, 1993 2:15:27 PM

Copyright ©1993, Symantec Corporation. All rights reserved.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: Browser
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5848, THINK C/C++
  Problem Area: Browser      Type: Incorrect Functionality
If inlined functions with the same name are declared in multiple classes the browser will find
the first inlined function in the file containing the class, not the one corresponding to the
actual class chosen.

Workaround:

Use "Search Again" until the correct class containing the inline function is reached.  Outlining
the functions in the source file during development also works.
----------------------------------------------------------------------------
••Defect Number: 5892, THINK C/C++
  Problem Area: Browser      Type: Incorrect Functionality
Unmangling is not properly done for pointers to pointers of undimensioned arrays.  This can be
seen if the following file is added to a project and struct Y is viewed in the Browser:

struct X { };
typedef X (*Xptr)[];
struct Y {
    void f(Xptr) { };
};
----------------------------------------------------------------------------
••Defect Number: 6159, THINK C/C++
  Problem Area: Browser      Type: Incorrect Functionality
The browser won't go to the correct function if a class contains both an operator+ and operator+=
overload, unless the operator+ implementation comes first in a source file. If operator+ is
selected in the browser, operator +=  will come up instead. Same thing for -=.
----------------------------------------------------------------------------
••Defect Number: 6178, THINK C/C++
  Problem Area: Browser      Type: Incorrect Functionality
The Browser has a maximum dimension which limits its ability to view a huge class tree in the
Browser window, and the window can not be scrolled to the right.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: Compatibility
----------------------------------------------------------------------------
    Product: THINK C
----------------------------------------------------------------------------
••Defect Number: 5579, THINK C
  Problem Area: Compatibility      Type: Crash
There is a problem with the THINK C Debugger interacting with the Japanese Input Method.
If you switch to the Japanese Input Method for the first time while running a project in the
Debugger, then the next time you switch to the Japanese Input Method in the running project you
will get a System Error #25.

Workaround:

Switch in and out of the Japanese Input Method BEFORE you run your program with the Think
Debugger.
----------------------------------------------------------------------------
••Defect Number: 5799, THINK C
  Problem Area: Compatibility      Type: Crash
The THINK Debugger does not work with the Macintosh emulator "Spectre 3.0", which runs on the
Atari ST computer series.
----------------------------------------------------------------------------
••Defect Number: 5035, THINK C
  Problem Area: Compatibility      Type: Crash
Address errors occur with UUPC versions 3.0 and 3.1b26 if slot 27 is already in use when the
.console driver is loaded. If the .console driver is loaded in slot 27 it's ok.
----------------------------------------------------------------------------
••Defect Number: 2642, THINK C
  Problem Area: Compatibility      Type: Incorrect Functionality
The DA Shell.c file contains a call to Launch, which is no longer supported in THINK C.   The
code could be rewritten to use _Launch.  As is, the project does not link. The DA shell project
is provided as an application and does not require rebuilding to work as directed.

Workaround:

The DA shell project is provided as an application and does not require rebuilding. The source
code is provided as a historical curiosity.
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6181, THINK C/C++
  Problem Area: Compatibility      Type: Crash
There's a incompatibility with the Think Debugger and the Stylewriter II  driver.  While running
the TCL 'Tiny Edit' demo program in the debugger, with a breakpoint set in the function:

         void CEditDoc::BuildWindow (Handle theData)
  on the line:

 ->        if (theData)
               theMainPane->SetTextHandle(theData);

When the debugger hits the breakpoint, an illegal instruction error occurs.

Workaround:

The problem goes away if  users "unchoose" the Stylewriter II driver.
----------------------------------------------------------------------------
••Defect Number: 4408, THINK C/C++
  Problem Area: Compatibility      Type: Incorrect Functionality
The extended syntax feature for #pragma parameter is currently not supported.  Example:
#pragma parameter foo(__D0)
pascal void foo(Size byteCount)
    = 0xA000;

only compiles under THINK C if the number of parameters (__D0) matches the number of actual
parameters reflected in the passed parameter list.  If the count doesn't match, THINK C flags it
as an error.
What MPW C does is pass whatever parameters are left after the register based ones have been
assigned, on the stack. For example:

#pragma parameter foo(__D0, __A0)
pascal void foo(Size byteCount, Ptr blahPtr, long fi)
    = 0xA000;

D0 = byteCount
A0 = blahPtr
push on to stack = fi
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6182, Symantec C/C++ for MPW
  Problem Area: Compatibility      Type: Incorrect Functionality
Not all libraries built with MPW C are supported by Symantec C/C++ for MPW. This is because MPW C
passes all function arguments as longs, while Symantec C/C++ for MPW only does this for
unprototyped functions.

Workaround:

Use Pascal calling conventions for all functions.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: C Compiler
----------------------------------------------------------------------------
    Product: THINK C
----------------------------------------------------------------------------
••Defect Number: 4866, THINK C
  Problem Area: C Compiler      Type: Crash
Code generation problem with the C compiler. This INIT code sets up a patch to GetNextEvent, and
solves the problem of keeping track of the global variables by poking in the address of the data
it will need when it gets invoked.

lea     globalstruct, a0        ; this is my data I need to access
move.l  a0, set_addr+2          ; set_addr points to an instruction:
                                ; set_addr: move.l #0x12345678, -(sp)
move.l  #_GetNextEvent, d0      ; put the trap number in d0
GetTrapAddress                  ; and get its address

"Disassemble" says:

000000FE        LEA       $0000(A4),A0
00000102        MOVE.L    A0,$0002(A4)
00000106        MOVE.L    #$0000A970,D0
0000010C        DC.W      $A146          ; OS 0046

This looks ok -- the reference to globalstruct assembles as an (as yet unknown) offset from a4
and the address to store into assembles as an (as yet unknown) offset+2 from a4.

However, the actual code output is this, which bombs:

+00FE  000BEA  LEA     $1A9C(A4),A0                         | 41EC 1A9C
+0102  000BEE  MOVE.L  set_addr+$0002,$203C(A4); 00000AD8   | 297A FEE8 203C
+0108  000BF4  ORI.B   #$A970,D0           ; 'p'            | 0000 A970
+010C  000BF8  _GetTrapAddress             ; A146           | A146

The linker has evidently patched in the correct address (set_addr+$0002) but has patched it in
over the source operand instead of the destination operand, resulting in the next instruction
getting overwritten.
----------------------------------------------------------------------------
••Defect Number: 2692, THINK C
  Problem Area: C Compiler      Type: Incorrect Functionality
THINK C may produce incorrect code when an array subscript contains an arithmetic expression with
large numbers.  For example:

          char globalArray;
          char array[30000];

          foo()
          {
               int i=25000;
               int j;
               char c;

          // This may fail depending on global data configuration:
               c=globalArray[i-24000];
          }

Workaround:

Assigning the expression to a temporary variable and using the temporary variable as the
subscript will always work. For the example above:
j=i-24000;
c=globalArray[j];
----------------------------------------------------------------------------
••Defect Number: 5310, THINK C
  Problem Area: C Compiler      Type: Incorrect Functionality
Code motion optimization bug in Think C can cause crashes, as seen with this example:

void main(void)
{
   int i;
   Boolean **aa;

   aa = (Boolean **)0x00000000;
   for (i = 5; i--; ) {
   if (aa && (**aa)) break;
   }
}

The double dereference of the handle (**aa) occurs outside the loop even though the dereference
normally should be prevented from happening by the short circuit evaluation.

Workaround:

Turn off code motion optimization.
----------------------------------------------------------------------------
••Defect Number: 5767, THINK C
  Problem Area: C Compiler      Type: Incorrect Functionality
There is a codegen bug with ternary operator in THINK C involving integer constants.
f should push 2 bytes of zeros on the stack. It incorrectly pushes 4 bytes.  Other variants and
ternary arguments which are non-constant work correctly.

void f(short);
void main()
{
    f(0 ? 1L : 0);
}
/*
main:
00000006: 42A7               CLR.L     -(A7)
00000008: 4EAD 0000          JSR       f
0000000C: 5C8F               ADDQ.L    #$4,A7
0000000E: 4E75               RTS
00000010
*/

Workaround:

Use the L specifier as in:
f(0 ? 1L : 0L);
----------------------------------------------------------------------------
••Defect Number: 4431, THINK C
  Problem Area: C Compiler      Type: Incorrect Functionality
THINK C erroneously assembles the completely illegal (and nonsensical) instruction:

        MOVEM.L #0x12345678,A0
into
        4CFC 0100 1234

when it should instead identify it as illegal code.
----------------------------------------------------------------------------
••Defect Number: 4914, THINK C
  Problem Area: C Compiler      Type: Incorrect Functionality
Code gen bug in Think C :

#define XX 16
#define YY (1L << 16)

   if (XX * XX * 256 <= YY)
       Debugger();

Generates an illegal instruction. This is what the Think Disassemble command says:

00000000: 0CBC 0001 0000     CMPI.L    #$00010000,#$0000
                  0000
00000008: 0000 6E02               ORI.B     #$6E02,D0
0000000C: A9FF                        _Debugger
0000000E: 4E75                        RTS
00000010
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5923, THINK C/C++
  Problem Area: C Compiler      Type: Crash
Code motion in THINK C compiler will crash optimizing the following construct:

int f ();
int k1;

g( )
{
    do {} while (0);
    do {} while (0);
  do {} while (0); //must be three or more do..whiles, or for(;;).
    k1 = f() +1;     //expression involving a function call
}

Workaround:

Turn off code motion.
----------------------------------------------------------------------------
••Defect Number: 5933, THINK C/C++
  Problem Area: C Compiler      Type: Crash
The THINK C compiler will hang compiling function calls that require very large stack space as in
the following construct.  It should instead produce the error "code overflow".

struct m
{
    long [100][100];
} *pm;

main()
{
    s(*pm);//attempt to pass 40k on the stack
}
----------------------------------------------------------------------------
••Defect Number: 4702, THINK C/C++
  Problem Area: C Compiler      Type: Incorrect Functionality
In the THINK C translator, there are deficiencies with the treatment of character constants.  The
ANSI standard states that character constants are allowed to be of any length, and that their
value if larger or longer than a character in the execution environment is implementation
defined.
The translator should not produce a diagnostic, since according to the standard it does not
matter what value is produced.  The THINK C translator does not accept the following:

int i = '1234567';      /* "Only 1,2, and 4 byte characters allowed" diagnostic */
int j = '\x354';        /* "Escape sequence does not fit into a byte" diagnostic */
----------------------------------------------------------------------------
••Defect Number: 4703, THINK C/C++
  Problem Area: C Compiler      Type: Incorrect Functionality
The THINK translator does not allow the re-declaration of a static function inside the scope of
another function.
----------------------------------------------------------------------------
••Defect Number: 5681, THINK C/C++
  Problem Area: C Compiler      Type: Incorrect Functionality
The inline assembler cannot resolve more than one member reference at a time when specifying an
address offset. For example:

    struct X {
        struct Y {
            short i;
        } y;
    };

    typedef struct X X;

    void main()
    {
        asm {
            move.w X.y.i(a0), d0            // Error:   value has no members
        }
    }

Workaround:

Use the OFFSET() macro defined in asm.h, eg:
move.w OFFSET(X,y.i)(a0), d0
----------------------------------------------------------------------------
••Defect Number: 6023, THINK C/C++
  Problem Area: C Compiler      Type: Incorrect Functionality
The following macro and invocation are allowed by THINK C:

#define Macro(a)    void foo(a);

main() {
    Macro()
}

The ANSI standard (Section 3.8.3) disallows empty argument lists.

----------------------------------------------------------------------------
••Defect Number: 6045, THINK C/C++
  Problem Area: C Compiler      Type: Incorrect Functionality
Using the MAXFLOAT macro in values.h will produce the error message 'Second argument to function
"nextfloat" does not match prototype' with the factory settings for THINK C. nextfloat() expects
an extended type as its second argument, while MAXFLOAT passes 0.0, which cannot be converted
correctly.

Workaround:

Turning on native floating point format will solve the problem: extended == double when this
option is turned on, and as such the conversion can be made.
----------------------------------------------------------------------------
••Defect Number: 6049, THINK C/C++
  Problem Area: C Compiler      Type: Incorrect Functionality
The static function dtof() in the ANSI library source file scanf.c does not correctly save the
floating point environment, resulting in the 68881 floating-point control register being munged
during the call.

Workaround:

The bug can be repaired by modifying the function dtof() in scanf.c as follows:
1) introduce a new local short named expc1
2) assign expc1 to the value of expc after the call fp68k(&expc,FPROCENTRY)
3) Add the function call "fp68k(&expc1,FPROCEXIT)" after the label done.
----------------------------------------------------------------------------
••Defect Number: 5237, THINK C/C++
  Problem Area: C Compiler      Type: Incorrect Functionality
The register coloring global optimization generates incorrect code in the following snippet:

...
   else if (pattern[state] == *theText)
   Put (theQue, next1[state]); // **** Error: state has to be set == *theText
   else if (pattern[state] < 0)
...
----------------------------------------------------------------------------
••Defect Number: 6189, THINK C/C++
  Problem Area: C Compiler      Type: Incorrect Functionality
Compiling the following with Think C with code motion and CSE elimination on produces an internal
error:
 Message:
    internal compiler error 208:184

code is:

static void optimize_bug( short i )
{
   while( TRUE )
   {
   if( ( i & 3 ) != 0 )
   {
   switch( i & 3 )  // halts here
   {
   case 1:
   break;
   }
   }
   }
}


Workaround:

switch( 3 & i ) works. Assigning the sub-expression to a local variable also works.
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 4864, Symantec C/C++ for MPW
  Problem Area: C Compiler      Type: Incorrect Functionality
The ANSI C Standard states:
"The string literal of a #line (if present) shall not be a 'wide-char'string", (ANSI C Standard,
section 3.8.4)
The SC compiler does not flag this error in the following source code, even when using the -A
switch to enforce ANSI compatibility.

int main ()
{
    #line 9999 L"c38.c"  /* should be an error */
    return 0;
}
----------------------------------------------------------------------------
••Defect Number: 4908, Symantec C/C++ for MPW
  Problem Area: C Compiler      Type: Incorrect Functionality
The ANSI C Standard states "If an identifier declared with internal linkage is used in an
expression (other than as a part of the operand of a sizeof() operator), there shall be exactly
one external definition for the identifier in the translation unit." (ANSI C Standard 3.7).
The SC compiler does not flag this error in the following source code, even when the -A switch is
used to enforce ANSI compatibility.

static int f1();
F2() { f1();}   /* should be an error */

----------------------------------------------------------------------------
••Defect Number: 4929, Symantec C/C++ for MPW
  Problem Area: C Compiler      Type: Incorrect Functionality
The ANSI C Standard states "A translation-unit must contain at least one external definition."
(ANSI C Standard 3.7). The SC compiler does not flag this error in the following source code,
even when the -A switch is used to enforce ANSI compatibility.

/*This file contains nothing but comments*/
/*it should produce an error when compiled */
----------------------------------------------------------------------------
••Defect Number: 4946, Symantec C/C++ for MPW
  Problem Area: C Compiler      Type: Incorrect Functionality
The ANSI C Standard states "An assignment operator shall have a modifiable lvalue as its left
operand."  (ANSI C Standard 3.3.16).
The SC compiler compiles the following source code without producing an error,  even using the -A
switch to enforce ANSI compatibility.

int main ()
{
    struct x{
        int i;
        };
    struct x fx();
    fx().i = 0;  /* should be an error: lvalue required */
    return 0;
}
----------------------------------------------------------------------------
••Defect Number: 4948, Symantec C/C++ for MPW
  Problem Area: C Compiler      Type: Incorrect Functionality
With regard to array subscripting, the ANSI C Standard states "One of the expressions shall have
type 'pointer to object type', the other shall have integral type... " (ANSI C Standard 3.3.2.1).
 A non-lvalue array does not convert to a pointer.
The SC compiler compiles the following source without producing an error, even using the -A
switch to enforce ANSI compatibiliy.

int main ()
{
    struct x {char a[4];} f();
    int i;
    i = f().a[10];  /* should be an error */
    return 0;
}
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: SymC++ Compiler
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5646, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Crash
Runtime crash occurs with a program setting up a multiple inheritance hierarchy such as the
following:

class A {
public:
        A() { }
        virtual ~A() {
        }
};

class Aa : public virtual A {
public:
        Aa() { }
        ~Aa() {
        }
};

class B : public virtual A {
public:
        B() { }
        ~B() {
        }
};

class Bb : public virtual Aa, public B {
public:
        Bb() { }
        ~Bb() {
        }
};

void main( void )
{
        A  *ap;

        ap = new Bb;
        delete ap;
}
----------------------------------------------------------------------------
••Defect Number: 5653, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Crash
Compiling the following function with any precompiled header that contains memory.h :

   void Zone()
   {
   }

gives Error:   internal error: file ph.c line 252

Workaround:

Change the name of the function to something other than "Zone"
----------------------------------------------------------------------------
••Defect Number: 5658, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Crash
The following code generates an internal error in out.c line 460.c.

// Almost any variation corrects the anomaly.

class first { public: virtual void vf(); };
class second : public virtual first { public: void vf(); };
class third : public second { public: ~third();};
class fourth : public third { public: void method(); };
void fun() { fourth * s = new fourth(); }

Workaround:

The easiest is to make first a non-virtual base of second.
----------------------------------------------------------------------------
••Defect Number: 5843, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Crash
An internal error "CGCntrl, line 58" is generated if a method needs to convert an unsigned int to
a floating point return type and is followed by something else that generates code.

unsigned b;
struct softball { double f(void);};

double softball::f(void)
{ return  b;};

void vf(void){};

Workaround:

double softball::f(void)
{ double d=b; return  d;};
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 5854, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Crash
The following code produces a correct error message, followed by an internal error in init.c line
235.

const int x = 1;
const int x = 1;    // Error:   'x' is already defined

----------------------------------------------------------------------------
••Defect Number: 5910, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Crash
The compiler generates an internal error when trying to expand an inline function that contains
an initialization to a stack-based local array:

inline void f()
{
    char s[] = "anything";
}
void main()
{
    f();        // internal error: file cpp.c line 845
}

Workaround:

Rewriting the code to use a pointer instead of an array works fine.
----------------------------------------------------------------------------
••Defect Number: 5912, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Crash
This test case causes the compiler to crash with a bus error, and if each occurrence of "class"
is replaced by "struct", the same behavior results:

class A { enum {FALSE, TRUE}; };
class B { enum {FALSE = 1, TRUE}; };
class C : A, B { };
int main()
    {
    int c = C::FALSE;
    return &c != 0;
    }
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6041, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Crash
Compiling this file with C++ will produce a bus error when the "Strings in code segment" option
is turned on:

void f(unsigned char * , unsigned long );
void g( void )
{
    f("\pThis is a string", "\pThis is a string"[0]+1);
}

Workaround:

Turn off "put strings in code" option
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6174, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Crash
The C++ compiler will generate an incorrect opcode when it compiles the following snippet:

void main(void)
{
    char *p1,*p2;
    long l;

    l = (long) p1 | (long) p2;
}


Workaround:

Casting the pointer values to a temporary before the logical-OR will result in correct code
generation, i.e.:
void main(void)
{
    char *p1,*p2;
    long t1,t2,l;
    t1 = (long) p1; t2 = (long) p2;
    l = t1 | t2;
}
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5934, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Crash
Compiling the following code sample crashes with a divide by zero error.

#include <stdlib.h>
#include <fstream.h>
class UI
{
   protected:
     ofstream&    resultfile;
   public:
     UI( char* s );
     ~UI( void );
};
UI::UI( char* s)
: resultfile(ofstream( s, ios::out ))
{}
UI::~UI( void ) { resultfile.close();}
UI userIF( "results");
void main ()
{
}
----------------------------------------------------------------------------
••Defect Number: 6197, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Crash
Calling a function pointer to a virtual member function of a handle based class results in a
crash at the point of the function call. This is demonstrated with the following code:

class __machdl foo  {
public:
   virtual void bar(int a,int b) { baz = a+b; }
private:
   short baz;
};

typedef void (foo::*PMFI)(int,int);

int main()
{
   PMFI pf = &foo::bar;
   foo* p;

   p = new foo;
   (p->*pf)(30,12);
   return 0;
}
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 4973, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Crash
With the optimizer on, compiling this code fragment produces Error:  internal error: file gloop.c
line 2595:

extern char charBar[10], charFoo[10];
void foo ()
{
    int  j=0, k=0;
    char c;
    do
    {
      c =  charBar [ j ] ;
        if ( ++k <= 10)
            charFoo [ k ] = 3;
    }
     while ( j++ < 0 );
}

Workaround:

use a "for" loop instead of a "do-while"  or turn off optimizer
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 3940, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Common sub expression elimination optimization doesn't make optimal use of temporaries.
    if (condition)
        a = expression;
    else
        d = expression

    becomes:
    T = expression;
    if (condition)
        a = T;
    else
        d = expression
----------------------------------------------------------------------------
••Defect Number: 4683, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
// The following declaration is erroneous but is improperly diagnosed.
// The compiler must ensure that at least one argument to a static operator
// member must be a class or reference to a class (or enum). The compiler
// reports "should be 1 parameter(s) for operator". How about "at least one
// argument must be a class or class&"

struct X {
    static int operator>>(int);     // error here
    int operator<<(int);            // OK
    static int operator++(int, int);    // error here (correct)
};
----------------------------------------------------------------------------
••Defect Number: 4855, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Compiling the code shown below causes the compiler to report an invalid error involving type
conversions with pointer to member variables and complex type hierarchies.

void foo()
{
// 48p14h: ptr to member converted to ptr to member of derived class
    // if inverse conversion of derived class ptr to base class ptr is
    // accessible and conversion is unambiguous.

        class B { public: int bi; };
        class C : virtual public B { int ci; };
        class Y : virtual public B { int ci; };
        class D : public C, public Y { public: int di; };
        D d;
        B *bp = &d;
        int B::*bpm = &B::bi;// should be legal
        int D::*dpm = bpm;//should be legal and reports an error

}//foo

Error reported is:
File “MAC_LANG:DEFECTS:Attachments:4855.CP”; Line 16
Error:   illegal cast
from: int B::*
to  : int D::*

----------------------------------------------------------------------------
••Defect Number: 4885, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The ARM p.296 states that the assignment operator for a virtual base class should be called only
once. In cases where the operator = is muptiply inherited to the same virtual base class, the
compiler erroneously calls it twice.

                    Top
              Left<--|-->Right
                |->Bottom<-|

If Left and Right declare Top as virtual and the operator = is called for Bottom, then the
operator = for Top will be called twice erroneously.
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 4892, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Certain template functions that might be expected to be inlined are not generated as inline.

Workaround:

If the template functions are declared in the class template declaration, then they will be
inlined when possible.

    template<class T> class X {
      inline X();    // body elsewhere, won't be inlined
    };
    template<class T> class Y {
      inline X() { }    // body present, will be inlined, if possible
    };
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 4896, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Default function arguments involving explicit calls to constructors are erroneously disallowed.

    struct X {
        X(int);
    };
    void f(X x = X(1));      // error: can't handle constructor in this context

Workaround:

Specify the default parameter at each function invocation for default arguments involving
explicit calls to constructors.  Or use the implicit constructor syntax:

    void f(X x = 1);
----------------------------------------------------------------------------••Defect Number:
4897, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Pointers to member functions do not allow type conversions involving inheritance. The code below
will not correctly compile unless the A class is the first base class of the object involved with
the cast.

struct A {
    void f();
};

struct B { };

struct C : public B, public A { };

typedef void (A::*pmfa)();

void main()
{
    C *c;

    pmfa ma1 = &A::f;
    (c->*ma1)();     // illegal cast
}

Workaround:

Declare the class first that causes the casting problem, if possible.
----------------------------------------------------------------------------
••Defect Number: 5000, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
When using ANSI compatibility mode, comments should not be allowed to start in a header file and
then finish in the main file. The compiler currently allows this.

f1.c:
#include "f1.h"
this closes the comment but is invalid */

f1.h:
/* This is a comment
but it is not allowed to span files
----------------------------------------------------------------------------
••Defect Number: 5110, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The code shown below should produce an ambiguous reference error. The class structure looks like
this

    ZooAnimal  ZooAnimal
        |         |
       Bear     Racoon
           \   /
          Panda

Class ZooAnimal and class Bear each declare a f() member function. Yet when f() is called using
an object of type Panda, no ambiguous reference error is flagged. At runtime Bear::f() is called.
This would be the correct behavior if ZooAnimal were a virtual base class, but it is not. (See
C++ Primer, 2nd ed., p 477 (section 9.2)).

    struct ZooAnimal {
        virtual void f();
    };

    struct Bear : ZooAnimal {
        void f();
    };

    struct Racoon : ZooAnimal {
         //void f() ;
    };

    struct Panda : Bear, Racoon { };

    void main ()
    {
        Panda p;
        p.f();  // should produce an ambiguous reference error
                // actually calls Bear::f().
    }

Workaround:

Uncommenting out the
     void f();
line in class Racoon causes the correct error to be generated. Or commenting out the f() function
declared in Bear also causes the correct error to be generated.
----------------------------------------------------------------------------
••Defect Number: 5199, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler does not correctly handle typedefs for nested classes where the typedef name is the
same name as the nested class. It produces an incorrect error message.

struct A {
    struct B {
        static int x;
    };
};
typedef A::B B;
typedef A::B TDB;

int TDB::x = 1;            // typedef of another name OK
int B::x = 1;            // typedef with the same name causes erroneous error:
                        // 'B' must be a class name preceding '::'

Workaround:

Insure that any typedefs of nested class names are distinct from the class name itself.
----------------------------------------------------------------------------
••Defect Number: 5223, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The values for the predefined symbols __nan, __nans, and _inf are incorrect and not recognized as
NAN's by the SANE package.

Workaround:

The SANE versions of these are correct and can be used in place of the C++ compiler's predefined
symbols.
----------------------------------------------------------------------------
••Defect Number: 5226, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
There are some problems with pascal object classes. When declaring instances of these object
types errors are not always reported as in:

class __pasobj X { } ;

void f(X);      // should produce an error and does not

X g();          // Correctly produces an error message

void h(X x)     // should produce an error and does not
{
    X x2;       // Produces an error message as expected
}

Workaround:

Double check declarations involving Pascal object class types.
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 5282, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The code shown below produces a "code segment too large" error when compiled with all
optimizations and the "Place string literals in code" option checked. The problem is caused by
the index into the string literal.

void f(void)
{
   int i;
   char c;

   for (i = 0; i < 6; ++i)
     c = "abcdef"[i];
}

Workaround:

Assign a pointer to the string literal and index using the pointer, compile without
optimizations, or don't use "Place string literals in code".
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5402, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Legitimate errors with templates sometimes list the prefix and a line number instead of the
appropriate place in the template definition.

Workaround:

When templates are involved and errors are reported in the prefix, the line number given is
usually for the file containing the template definitions.
----------------------------------------------------------------------------
••Defect Number: 5427, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The attached file demonstrates that when a prototype for a function uses ...,  the compiler
erroneously promotes a constant to a 10 byte double when using 8 byte doubles.

void f(int a, ...)
{
}

void main(void)
{
    f(1, 1.0);
}

Workaround:

Before passing a double constant to a function taking ... as a prototype, assign it to a
variable.  Variables are not erroneously promoted in size.
----------------------------------------------------------------------------
••Defect Number: 5437, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The declaration of f below should be flagged as an illegal declaration.  It should not be
possible to declare a pointer to a reference.

void f( int &*p );
----------------------------------------------------------------------------
••Defect Number: 5471, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Assignments to anonymous union members produce an incorrect error message when ANSI conformance
is on.  As in the following code fragment:

void
test( unsigned long v )
{
    union { unsigned long lv; unsigned char cv[4]; };

     lv = v;    // Error produced here incorrectly

}

Workaround:

Turn ANSI conformance off for these cases.
----------------------------------------------------------------------------
••Defect Number: 5493, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Destructors defined for classes based on pascal object are not being generated correctly and end
up producing references to undefined virtual dispatch tables.  As in the code shown below:

struct __pasobj X {
    virtual void f();
    ~X();
};

X::~X() { }

void X::f() { }

An undefined symbol for X::__vtbl is erroneously produced.

Workaround:

Do not use destructors for pascal object classes.
----------------------------------------------------------------------------
••Defect Number: 5500, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
When using pascal object, the compiler does not always parse the scope resolution operator
correctly if the class name begins in a leading _.  As in:

struct __pasobj _X {
    virtual void f();
};

struct X : _X {
    virtual void f();
};

void X::f() {
    _X::f();    // Error:   ';' expected
}

Workaround:

Do not use a leading _ when declaring pascal object classes that will be subclassed.
----------------------------------------------------------------------------
••Defect Number: 5505, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler produces an error when the address of a register variable is taken. The C++ draft
explicitly allows this to be done. ARM, section 7.1.1 p. 97.

Workaround:

Remove the "register" declaration. The compiler will automatically assign variables to registers
when possible.
----------------------------------------------------------------------------
••Defect Number: 5506, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler will report an error when trying to make a non-template class have a friend template
class.

    template <class T> class Bar;
    class Foo {
        template<class T> friend class Bar;   // error:  ';' expected
    };

Workaround:

Declare the friend with a specific type:
    template <class T> class Bar;
    class Foo {
        friend class Bar<int>;
    };
----------------------------------------------------------------------------
••Defect Number: 5507, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Class names are not declared until after the base class list has been parsed. This violates the
C++ rule that each name is declared immediately after it is seen (ARM p.168). This causes
problems with template expansions called for on the class declaration line as in:

     template<class T> class B { };
     class C : public B<C> { };  // error: template-argument 'T' must be a type-argument

Workaround:

Forward declare class C prior to its declaration.
----------------------------------------------------------------------------
••Defect Number: 5512, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
In strict ANSI mode, the compiler still recognizes the "inherited" keyword, so that errors are
produced when inherited is used as a variable name.

    void f(int *inherited );    // error:  ')' expected

Workaround:

Change the name of the variable to not use this keyword.
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 5514, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler does not generate the 68020 MULU.L instruction for long multiplies when the 68020
option is turned on.

    long f(long a, long b)
    {
        return a*b;
    }

f(long,long):
00000000: 4E56 0000          LINK      A6,#$0000
00000004: 202E 000C          MOVE.L    $000C(A6),D0
00000008: 222E 0008          MOVE.L    $0008(A6),D1
0000000C: 4EBA 0000          JSR       ULMULT          ; instead of MULU.L
00000010: 4E5E               UNLK      A6
00000012: 4E74 0008          RTD       #$0008
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5521, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Floating point constants are of type long double. This causes problems with overload resolution
and produces an error in the following case:

    void f(short);
    void f(double);

    void main()
    {
        f(1.0);             // error: ambiguous reference to function
        f(double(1.0)); // OK
    }


Workaround:

Declare the parameter's type as long double, or cast the constant to type double when calling the
function.
----------------------------------------------------------------------------
••Defect Number: 5533, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Casting a pointer to function to a particular type does not handle overloading as expected, even
when the cast type exactly matches the expected type.  As in:
#include <iostream.h>

char * f1( int i )
{
    return("char *f1(int i)" );
}
char * f1( short s)
{
    return("char *f1(short s)" );
}
typedef char *(*PFN_INT)(int);
typedef char *(*PFN_SHORT)(short);

void main(void)
{
    PFN_INT pfn_int= f1;
    PFN_SHORT pfn_short = f1;
    PFN_SHORT pfn_cast_int_to_short = (PFN_SHORT) ((PFN_INT) f1);
    PFN_INT pfn_cast_short_to_int = (PFN_INT) ((PFN_SHORT) f1 );

    cout << pfn_int(1) << endl;                                    // This is correct
    cout << pfn_short(2) << endl;                                // OK
    cout << pfn_cast_int_to_short(3) << endl;             // May or may not be what is
expected
    cout << pfn_cast_short_to_int(4) << endl;             // May or may not be what is
expected
}

Workaround:

Instead of a cast, declare a variable of the cast type and assign the function to it.   In the
above example this would mean initializing the cast pointers to functions with the values from
the uncast versions which always will work correctly.
----------------------------------------------------------------------------
••Defect Number: 5539, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
When declaring variables of template class with functions that are declared in the body of the
template, a name conflict can occur if the name of the template variable is the same name as a
name used within the body of any inline template function.

    template<class T> class X {
        int x;
        void f() { x++; }   // error: undefined use of struct or union
                                //  (X::x is hidden by main's x)
    };

    void main()
    {
        X<int> x;
        X<char> y;
    }

Workaround:

Do not instantiate a template instance with the same name as any local variables used in inline
functions on the template. In the above example note that x is used in the body of the member
function f().  This will cause a spurious error. If the variable name is changed to another name
not used in the inline function definition of the template, it will work as expected.
----------------------------------------------------------------------------
••Defect Number: 5540, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
You cannot declare a variable inside a struct or class body with the same name as the struct tag.

    struct foo {
        int foo;    // error: illegal constructor or destructor declaration
    };

Workaround:

Change the name of the member or the struct tag so that there is no conflict.
----------------------------------------------------------------------------
••Defect Number: 5542, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Typedefs for class names declared within the body of classes cannot then be used in member
functions with the scope resolution operator.  As in:

class cFooParent {
public:
    void xxx(void);
};

class cFoo : public cFooParent
{
    typedef cFooParent super;
public:
    void xxx(void);
};

void cFoo:: xxx()
{
    super::xxx();          // Error is produced here
    cFooParent::xxx(); /* OK */
}

Error is:
File “5542.cpp”; Line 16
Error:   no instance of class 'cFooParent' for member 'cFooParent::xxx'



Workaround:

Declare the typedef outside of the body of the subclass or use the name of the desired parent
class directly.
----------------------------------------------------------------------------
••Defect Number: 5547, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
When there are multiple parameters to an overloaded function and there is not an exact match for
the overloaded function, the compiler does not use a best fit approach to determine the correct
function to call.   It will instead report an ambiguity.  As in:

class A {
public:
   A (short, char*, int&);
   A (long, char*, int&);
};
void
Test (void)
{
   int i;

   short shortVal;
   long longVal;

   A test1(shortVal,0, i);            // Ambiguity reported here
   A test2(longVal,  0, i);            // Ambiguity reported here
}

Errors are:
File “5547.cpp”; Line 14
Error:   ambiguous reference to function
Had: A::A(short ,char *,int ref)
and: A::A(long ,char *,int ref)

File “5547.cpp”; Line 15
Error:   ambiguous reference to function
Had: A::A(short ,char *,int ref)
and: A::A(long ,char *,int ref)


Workaround:

Use casts to get all of the parameters to match an existing function.  In the above example
casting the 0 to a (char *) causes the compiler to exactly match the short and long versions of
the constructor without a problem.
----------------------------------------------------------------------------
••Defect Number: 5557, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler does not complain about _machdl class members inside a C++ class as it should.  As
in:

class __machdl foo { public: double go (void); };
class bar : public foo { };

class baz
{
        public :
                foo quux1;      // Should produce an error
                foo *quux2;     // OK
}

Workaround:

Avoid declaring these constructs as the behavior will not be correct at run-time.
----------------------------------------------------------------------------
••Defect Number: 5620, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler does not allow derived classes to be directly created from nested base classes.  As
in:

class S
{
public:
    class T
    {
        int a;
    };
    int b;
};

class V : S::T {
    int c;
};

Error:
File “5620.cpp”; Line 11
Error:   '{' expected

File “5620.cpp”; Line 13
Error:   identifier or '( declarator )' expected


Workaround:

Create a typedef for the nested base class first and then use the typedef to declare the derived
class, as in:
typedef S::T Z;
class W : public Z
{
    int c;
};

which works as expected.
----------------------------------------------------------------------------
••Defect Number: 5628, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Static member functions that should be accessible to derived classes are not accessible.  As in:
class moe
{
public:
    static void f1();
protected:
    static void f2();
    void f3();
};

class curly : public moe
{
private:
    static void g()
    {
        f1();           // OK
        f2();           // OK
        moe::f1();      // OK
        moe::f2();      // Error produced here
    };

    void h()
    {
        f3();           // OK
        moe::f3();      // OK
    };
};

Error is:
File “5628.cp”; Line 18
Error:   member 'moe::f2' of class 'moe' is not accessible


Workaround:

Declare static member functions as public, or declare the functions that need to call them as
friend functions.
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 5629, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
When ANSI conformance is turned on, a call to new that takes a typedef for an array type gives an
error about an empty declaration.  As in:

typedef char C_NAME[33];
void joe()
{
char*   name1 = new char[33];
char*   name2 = new C_NAME;         // Error is here
}

Error is:
File “5629.cpp”; Line 5
Error:   empty declaration


Workaround:

Turn ANSI flag off, or add empty parens after typedef name ().
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5631, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Constructors that are declared as static member functions are not flagged as an error by the
compiler.  This is incorrect according to the ARM Sec 12.1 p.262.  As in:

class X {
    static X();   // static constructor not flagged
};

X::X()
{
}



Workaround:

Exercise care to insure that constructors are not declared static
----------------------------------------------------------------------------
••Defect Number: 5632, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
In a scope where a class with a constructor is declared, other functions which have the same name
as the class produce invalid error messages as in:

class X {
    X();
};

int X()
{               // Error is produced here
    return 0;
}

Error is:
File “5632.cpp”; Line 6
Error:   no constructor allowed for class 'X'


Workaround:

Do not declare functions with the same name as the class unless they are the constructor for the
class.
----------------------------------------------------------------------------
••Defect Number: 5635, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Calls to PascalObject constructors and destructors are not propagated up the inheritance chain.
Base class constructors or destructors, if they exist, will never get called.

Workaround:

Either explicitly call base class constructors, or use a parallel construction scheme, like the
TCL's Cxxx::ICxxx().
----------------------------------------------------------------------------
••Defect Number: 5636, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
In some cases, the compiler will let you access members of a PascalObject class that are not
accessible. For example:

    class X : PascalObject {
    private:
        void f();
    };
    void main()
    {
         X *x = new X;
         x->f();               // should be flagged as an error, but isn't
         delete x;
    }
----------------------------------------------------------------------------
••Defect Number: 5638, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler doesn't recognize class friends when determining access for constructors or
destructors of class members. If a class member has a constructor or destructor that would be
inaccessible without the friend declaration, then the compiler will not allow the class
declaration. The error isn't flagged for member functions of the declared class that try to
access the private constructors or destructors.

    struct Y;
    struct X {
        friend Y;
    private:
        X();
    };
    struct Y {
        void f() { X x; }     // OK
        X x;                      // Error:   member 'X::X' of class 'X' is not accessible
    };

Workaround:

For now, make the constructors and/or destructors public.
----------------------------------------------------------------------------
••Defect Number: 5640, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Nested typedef names that appear inside templates are not recognized correctly by the compiler.
For example:

    template <class T> struct X {
        typedef T* TP;
    };

    void main()
    {
        X<int>::TP p = 0;                 // Error:   'X<int>::TP' is not a variable
        typedef X<int>::TP MyTP;    // create typedef for nested type
        MyTP p2 = 0;                      // Works OK
    }

Workaround:

Introduce another (local) typedef for the nested typedef.
----------------------------------------------------------------------------
••Defect Number: 5647, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
There is a bug in the C++ compiler that causes certain macro expansions to produce incorrect
results. The compiler fails to re-scan the arguments to the token pasting preprocessor directive
in some cases. Eg:

    #define X(s) Y(s)
    #define Y(s) foo##s
    #define T bar

    int X(T);    // produces a variable called "fooT", not "foobar"
----------------------------------------------------------------------------
••Defect Number: 5649, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Template-based overloaded operator functions may not be automatically expanded by the compiler in
some cases. For example:

    template <class T> struct X { };

    template <class T> X<T>& operator+ (X<T>&, X<T>&)
    {
        return *new X<T>;
    }

    //X<int>& operator+ (X<int>&, X<int>&);       // add this line to work around the bug

    void main()
    {
        X<int> i, j, k;
        i = j + k;          // Error:   illegal operand types
    }

Workaround:

The compiler must be forced to expand the template function by providing a prototype for the
function with the correct argument types provided.
----------------------------------------------------------------------------
••Defect Number: 5656, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
In some cases, the compiler will allow the modification of a const class object. For example:

    struct X {
        int y;
    };

    void main()
    {
        X x1;
        const X x2;

        x2 = x1;          // should report an error, but doesn't
    }
----------------------------------------------------------------------------
••Defect Number: 5657, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler fails to signal an error when it sees a void function that has a return statement
with an expression, if that expression's type is void (eg, when the expression is a function
whose return type is void).
----------------------------------------------------------------------------
••Defect Number: 5671, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Due to the way that the compiler chooses "key" functions for a class, inline functions that are
not declared as inline in a class declaration can cause problems when creating a precompiled
header. Eg:

    struct X {
        void f();
        virtual void g();
    };

    inline void X::f() { }  // Error: vtable key function 'f' cannot be redeclared inline in
precompiled header

Workaround:

Declare the function as "inline" in the class declaration as well as the function declaration.
----------------------------------------------------------------------------
••Defect Number: 5701, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
C++ classes with virtual functions cannot be used in code resources. If you try define a C++
class with a virtual function in a code resource, you will get the error: "initialization to an
address is illegal for a non-application".

Workaround:

Use PascalObject classes in code resources instead of regular C++ classes. PascalObject classes
can contain virtual functions in code resources.
----------------------------------------------------------------------------
••Defect Number: 5738, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler doesn't allow forward declarations of specific template expansions. If a template is
forward declared, and then is used with a specific expansion, any use of the template later on
will not work. For example:

    template <class T> struct X;

    void dummy(X<char>);        // this declaration "confuses" the compiler
    template <class T> struct X {
        void f();
    };

    void main()
    {
        X<char> *x;
        x->f();                       // Error: 'f' not a member of struct 'X<char>'
    }
----------------------------------------------------------------------------
••Defect Number: 5743, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler fails to call conversion operator functions whose conversion type is an enumeration.
For example:

    enum E { whatever };

    struct X {
        operator E();
    };

    void main()
    {
        X x;
        E e;

        if (e == x) ;     // Error: ambiguous type conversion
        if (e == (E)x) ;  // works OK
   }

Workaround:

Provide an explicit cast to force the compiler to use the correct conversion operator.
----------------------------------------------------------------------------
••Defect Number: 5759, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
If an #endif is encountered without any matching #if, and if no other #if statements have yet
been seen by the compiler, then the compiler will write to 0 (NIL) before reporting the error. No
other corruption of low memory will occur.
----------------------------------------------------------------------------
••Defect Number: 5760, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The result of applying the modulo operator to an unsigned short or unsigned char will appear to
produce an incorrect result when its result is examined in a conditional expression. For example:

    #include <stdio.h>

    void main()
    {
        unsigned short n = 2;

        if (n % 2)
            printf("wrong\n");
        else
            printf("right\n");
    }

The result of the modulo operator is correct in all other contexts, eg in an arithmetic
expression.

Workaround:

Compare the result of the modulo to zero, eg:

if ((n % 2) != 0)
----------------------------------------------------------------------------
••Defect Number: 5761, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler is unable to choose the correct conversion operator when possible conversions differ
only by the const-ness of the class that's being converted. For example:

    struct X { };

    struct Y {
        operator X();
        operator X() const;
    };

    void f()
    {
        const Y y;
        X x = y;      // Error: cannot implicitly convert
    }

Workaround:

Using an explicit call to the conversion operator will work, eg:

X x = y.operator X();      // OK; chooses operator X() const
----------------------------------------------------------------------------
••Defect Number: 5763, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
A nested scope enum will clash with a global scope enum instead of hiding it. For example:

    enum foo { one, two, three };
    class X {
        enum foo {true, false };        // Error: foo is already defined
    };

Workaround:

Move the global scope enum after the class declaration with the nested enum.
----------------------------------------------------------------------------
••Defect Number: 5783, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler cannot select the correct function pointer when an overloaded function name is used
as an argument to a constructor. For example:

    struct X {
        X(void (*)(int));
    };
    void g(char);
    void g(int);

    X x = X(g);

Other uses of overloaded function names, such as in non-constructor function calls and assignment
work correctly.

Workaround:

If possible, rearrange the declarations for the overloaded function name so that the desired
function occurs first. This will let the compiler find the correct function.
----------------------------------------------------------------------------
••Defect Number:
5847, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The debugger will not be able to single-step through an expanded template function if it itself
forced an expansion of another template function. In the debugger, no breakpoint diamond will
appear within the template function body. For example:

    template <class T> void g(T) { }
    template <class T> void f(T t)
    {
        g(t);
    }
    void main()
    {
        f(0);
    }

Workaround:

Force the expansion of the second template before it is automatically expanded by providing a
prototype. Eg, put the prototype

void g(int);

before the declaration of the template function f() above.
----------------------------------------------------------------------------
••Defect Number: 5855, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Attempting to delete an object that is allocated in a volatile pointer results in an incorrect
error.
struct foo { };
void f()
{
    volatile foo *foop;
    foop = new foo;
    delete foop;            // no destructor found matching delete (volatile foo*)
}
----------------------------------------------------------------------------
••Defect Number: 5883, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
If you have a C++ source file with two different function scope static variables that have the
same name, the debugger will only be able to display the value of the first static variable.
----------------------------------------------------------------------------
••Defect Number: 5895, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The C++ compiler does not support aggregates whose size is greater than 32K. If you try to use an
aggregate larger than 32K, the compiler will generate incorrect code to reference fields beyond
the 32K boundary.
----------------------------------------------------------------------------
••Defect Number: 5909, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler promotes expressions of type "double" to type "long double" in certain cases, which
can result in unexpected "ambiguous function" errors.

    struct X {
        X(double);
        X(int);
    };
    double d();
    void main()
    {
        X x(d());        // Error: ambiguous reference to function X::X()
    }

Workaround:

Either explicitly cast the expression to double, or declare the function to take a parameter of
type long double.
----------------------------------------------------------------------------
••Defect Number: 5918, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Due to the way that Symantec C++ generates function calls, the toolbox routine PlotCIconHandle()
may not always return a valid error code. This is because the compiler reserves stack space
without clearing it, and the toolbox does not always set the return value to zero.

Workaround:

Instead of using the regular glue for PlotCIconHandle, use this glue instead. It clears the OSErr
result before calling the trap.

pascal OSErr MyPlotCIconHandle( Rect*, short, short, CIconHandle)
   = { 0x7000, 0x3F40, 0x000C, 0x303C, 0x61F, 0xABC9};
----------------------------------------------------------------------------
••Defect Number: 5921, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
In some c
ases, a local (function scope) variable name will hide the name of a class declared at
file scope. For example:

    class X { };
    void main()
    {
        int X;
        class X x;   // Error: size of type is not known
    }
----------------------------------------------------------------------------
••Defect Number: 5936, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler does not allow a linkage declaration that contains only a typedef. Eg:

    extern "C" typedef void (*PFV)();

Workaround:

Rewrite to use a multiline linkage declaration.
----------------------------------------------------------------------------
••Defect Number: 5950, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Compiling the following code example produces the confusing error message "Error: member 'M::m'
of class 'Mfriend' is not  accessible":

class M {
 friend class Mfriend;
 static int m;
};

class Mfriend {
 int i[M::m];
};

The error should be: "integer constant expression expected".
----------------------------------------------------------------------------
••Defect Number: 5951, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler will produce a spurious error message if it encounteres an access declaration that
specifies a conversion operator using an intrinsic (builtin) type. Eg:

    struct X {
        operator int();
    };

    class Y : X {
    public:
        X::operator int;  // Error: empty declaration
    };

Workaround:

Turn off the "ANSI conformance" switch.
----------------------------------------------------------------------------
••Defect Number: 5979, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
If a function template has arguments with const or volatile modifiers, and if it's called more
than once with arguments that are not const or volatile, an error is produced. Eg:

    template<class T> void f(const T&) { }

    void main(void)
    {
        f(1);
        f(2);   // Error: f already defined
    }

Workaround:

Before using the function template, declare the function with the arguments that will be needed.
Eg:

void f(const int &);
----------------------------------------------------------------------------
••Defect Number: 6018, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
If you declare a data member of a class whose constructor takes arguments, and if you try to pass
the arguments to the constructor in the declaration, the compiler will produce an error at the
line of the member's constructor source code.

    struct X {
        X(int);   // Error:   ';' expected
    };
    struct Y {
        X x(0);  // incorrect declaration here
    };
----------------------------------------------------------------------------
••Defect Number: 6037, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Overloading resolution does not work correctly over an inheritance hierarchy for reference
conversions (cf. ARM Section 13.2 [3] p. 324) as shown by the following example:

class A {};
class B : public A {};
class C : public B {};

void g(A&);
void g(B&);

C aC;

void f()
{
    g(aC);
}
----------------------------------------------------------------------------
••Defect Number: 6051, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The C++ compiler won't accept array initialization when the elements are addresses of a local
variable. Globals work, as does the initialization of a single (non array) object:

int g1, g2;

void main(void)
{
    int n1, n2;

    const int   *i1 = &n1;                  // ok
    const int   *array[] = { &n1, &n2 };    // error
    const int   *array2[] = { &g1, &g2 };   // ok
}
----------------------------------------------------------------------------
••Defect Number: 6054, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The following example will not compile:

struct X {
    X();            // having a destructor yields same error
    void foo();
};

void main()
{
    int rows = 3;
    const int cols = 2;

    typedef X PTR[cols];    // error goes away if constructor for X is commented out
    PTR     *ptr = new PTR[rows];
    delete [] ptr;
}
// File "test.cpp"; Line 15
// Error:   cannot implicitly convert
// from:<*>X
// to  :<*><array[2]>X
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6070, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Compiling the following code sample produces internal error: file n2.c line 1355.

template<class T> struct Tlink
{
};
template<class T> class s;
template<class T> class s_iter {
 public:
  T* first()
    {
      return &((Tlink<T>*) 0;
    }
};
template<class T> class s
{
friend class s_iter<T>;
};
void main (int argc, char* argv[])
{
 s<int> test;
}
----------------------------------------------------------------------------
••Defect Number: 6090, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler will report an internal error in n2.c when a template class forward declaration is
syntactically incorrect. Consider the following:

template <class tType> class TArchiver<tType>;

class CFont
{
public:
    CFont();
    friend TArchiver<CFont>;
};
----------------------------------------------------------------------------
••Defect Number: 6094, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The following code fragment causes an "expression expected" on the marked line:

void main()
{
    typedef int x;
     {
      x(((x)));          // error reported here
      x = 3;
     }
}
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6097, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The C++ preprocessor can put an incorrect amount of space in the preprocessed output which
prevents the compiler from compiling it. It does not affect what is passed to the compiler itself
(i.e. the code compiles and runs without a problem). For example,

typedef short X;
#define X(y) short y

void main(void)
{
 X(*) a;
 X    b = 3;
 a = &b;
}

preprocesses to:

typedef short X;
#define X(y) short y

void main(void)
{
 short  *  a;
 Xb = 3;
 a = &b;
}
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6106, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler will (incorrectly) allow a class to be specified as a direct base class of a derived
class more than once:

struct A1 {
    A1();
    virtual ~A1();
};

struct B1 :  A1 {
    B1();
    virtual ~B1();
};

struct C1 : B1 {
    C1();
    virtual ~C1();
};

struct D1 : B1, virtual A1 {
    D1();
    ~D1();
};
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6112, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Compiling a file containing simply "#endif " sometimes writes to nil.
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6127, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Static references to const don't construct the referenced object. Temporary references to const
work correctly:

#include <stdio.h>
struct S{
int ii;
    S(int i):ii(i){};
};

const S &rS(4);  //fails

void main()
{
//const S &rS(4);  // works
printf("%d\n", rS.ii);
}
----------------------------------------------------------------------------
••Defect Number: 6128, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The common subexpression elimination portion of the global optimizer generates an internal error
(CGcod.c line 320) on the following line extracted from a complex switch statement.

        if ( C >= B - 3 && C <= B && C >= D - 3  && C <= D )
                return  P6;

where B, C, and D are of type char and P6 is an enumerated value.

Workaround:

Turning off CSE elimination removes the internal error.
----------------------------------------------------------------------------
••Defect Number: 6131, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Unable to use global scope resolution in declarator for a pointer to member, i.e.

struct C
{
    int i;
};

void f()
{
   struct C{};
   int ::C::*pmi;    // Error:   '=', ';' or ',' expected
}

----------------------------------------------------------------------------
••Defect Number: 6132, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compile does not accept a pointer to member with the scope resolution operator, i.e.

struct C
{
    int i;
};

void f()
{
   int C::*pmi=&::C::i;   // Error:   no instance of class 'C' for member 'C::i'
}

----------------------------------------------------------------------------
••Defect Number: 6133, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler shows incomplete closure of nested class scope of a static member. Consider the
following example:

#include <stdio.h>
int i = 7;

class Outer{
public:
  class C{
    public: int f3() { printf("%d\n",i); return i;}; //returns value of global instead of static int i
  } c;

  static int i;                // declared here
  Outer(int j) { i=j+3;}

  class C2{
    public: int f3(){ printf("%d\n",i); return i;};  //correctly returns value of static int
  } c2;

};

Outer::i;

void main()
{
    Outer o(0);
    int temp=o.c.f3();
    temp=o.c2.f3();
}

Workaround:

Declare Outer::i before the declaration/definition of class C and it will find the correct value.
----------------------------------------------------------------------------
••Defect Number: 6134, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
If the second and third operands of ?: are references, then reference conversions should bring
them to a common type. This is a problem with references to derived classes. Consider the
following example:

class omni {
public:
    int i;
    operator int() { return i; }; //necessary use references in ?:
};

void ieq(int, int);
ivalue(int i);

class D : public omni { int j; };

void f()
{
    int li;
      omni a, c;
      omni &ar = a, &cr = c;

      D b;
      D &br = b;

      li=( ivalue(1) ? ar : cr ).i;
      li=( ivalue(1) ? ar : br ).i;     // br reference to D, derived from omni
}
----------------------------------------------------------------------------
••Defect Number: 6135, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler does not allow you to initialize references to functions. The following code will
not compile successfully:

   void fv(void){};
   void (&rfv)(void)=fv;
----------------------------------------------------------------------------
••Defect Number: 6136, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler will not allow a pointer to a function to be used in a call to new.

void f()
{
    char *(**p1)(int) = new (char *(*)(int));
}

Workaround:

Use a typedef, i.e.
void f()
{
  typedef char *(*t)(int);
  t *p2 = new t(*p2);
}
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6145, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler allows a call to a pure virtual function that is never defined, resulting in a link
error. Consider the following:

struct X {
    virtual void f() = 0;
};

struct Y : X {
    void f() { inherited::f(); }    // illegal
};

X *x;

void main()
{
    x = new Y;
    x->f();
    delete x;
}
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6147, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
After a valid diagnostic regarding access, the compiler will produce an internal error.  The
following example:

class b
    {
public:
    b(int ii) : i(ii) { }
protected:
    int i;
    };
    class c : virtual private b
    {
protected:
    b::i;
public:
    c(int ii) : b(ii) { }
    };

class c2 : virtual private b
    {
public:
    c2(int ii) : b(ii) { }
    };

class d : public c, public c2
    {
public:

    d(int ii) :
        b(ii)  // internal error here
        { }
    };

Produces:
File “6147.cpp”; Line 29
Error:   member 'b::b' of class 'd' is not accessible

File “6147.cpp”; Line 29
Error:   internal error: file cpp.c line 3380

Workaround:

Ignore the spurious internal error and correct the source code.
----------------------------------------------------------------------------
••Defect Number: 6149, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler generates spurious errors when initializing members of an anonymous union in a
class:

class foo {
    union {     // anonymous unions add their members to the enclosing scope
        const int i;
        const double x;
    };
    foo(int anInt) : i(anInt) { }
    foo(double aDouble) : x(aDouble) { }
};

NB: the draft standard is sufficiently vague about this issue that there may not be a right
answer.
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6154, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler generates an excess stack frame when optimizing for space and not using function
calls for inlines. Disassembly of the following example will show this.

struct Simple
{
 long value;
 Simple(long value) : value(value) {};
 long AddOne();
 };

long Simple::AddOne()
{
 return value+1;
}

long main()
{
 Simple s(1);
 s = s.AddOne();
 return s.value;
}
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6163, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The following code generates an internal error after generating a valid diagnostic regarding an
access control violation:

class B
{
public:
    B(int ii) : i(ii) { }
    B() : i(0) { }
protected:
    int i;
};

class C : virtual private B
{
public:
    C(int ii) : B(ii) { }
    //C(){};
};

class D : public C
{
public:
    D(){ }        //Error:   internal error: file cpp.c line 3365
};

Yields :
File “6163.cpp”; Line 21
Error:   member 'B::B' of class 'D' is not accessible

File “6163.cpp”; Line 21
Error:   internal error: file cpp.c line 3380

Workaround:

Ignore the internal error and correct the source code using the valid diagnostic.
----------------------------------------------------------------------------
••Defect Number: 6164, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
/* Generated error:   member 'b::nest' of class 'b' is not accessible
 * Protected member of private base class can be made accessible as
 * protected member of derived class with access declaration.  */

  class b{ protected: class nest {}m; };
  class c : private b{ protected:b::nest;};
----------------------------------------------------------------------------
••Defect Number: 6165, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Nested type names aren't correctly adjusted by access declarations when referenced in function
scope. Eg:

    struct C {
        struct C_nest { };
    };

    struct D : private C {
    public:
        C::C_nest;
    };

    void f()
    {
        D::C_nest n;    // Error: member C::C_nest of type D is not accessible
    }
----------------------------------------------------------------------------
••Defect Number: 6166, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
/*  A friend or a member function of a derived class can access a
  *  protected static member of a base class. */

  class A{ protected: static int i; };
  class B : public A { public: friend class C; };
  class C { public: void f2(void); };

  void C::f2(void) { A::i++;  }   // Error:   member 'A::i' of class 'A' is not accessible
----------------------------------------------------------------------------
••Defect Number: 6167, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
/*    Static function members should be able to access public inherited protected members */

   class B { protected: static int i2; };
   class D : public B { public: static void f4(void); };
     void D::f4(void){ B::i2=0; }        //Error:   member 'B::i2' of class 'B' is not accessible
----------------------------------------------------------------------------
••Defect Number: 6168, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
/*  Nested class names are not defined in their own, or subsequent inner, scopes. */
   struct s {
     class c{ public:int c::*pm;};    //Error:   'c' must be a class name preceding '::'
   };
----------------------------------------------------------------------------
••Defect Number: 6169, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
/*  A reference to a volatile can be initialized with either volatile or a plain.
      The following code should only give a warning.  */
    int i = 2;
      volatile int &rvi2 = i;       //Error:   non-const reference initialized to temporary

----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6172, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler can't find the correct overloaded function when an overloaded function is used as an
argument to another overloaded function. Eg:

    struct Z {
        void f(void (*)(int));
        void f(int);
    };

    void g(char);
    void g(int);

    void main()
    {
        Z z;
        z.f(g);     // Error: no match for function f()
    }

Workaround:

Reverse the order of overloaded function declarations so the desired overloaded function occurs
first. Above, reverse the order of the declarations of g().
----------------------------------------------------------------------------
••Defect Number: 5510, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler incorrectly allows a class declared with the __machdl keyword to be declared inside
another class declaration.

   class __machdl foo { }
   class bar : public foo { short x; }
   class baz { bar quux; }              // should only allow bar *quux
----------------------------------------------------------------------------
••Defect Number: 5555, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler is position sensitive with regards to some modifiers. Each of the declarations below
should be allowed.

        class Foo {
        public:
               virtual void f();        // OK
               void virtual g();        // Compile error
        };

Workaround:

Always specify the 'virtual' modifier first.
----------------------------------------------------------------------------
••Defect Number: 5859, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler incorrectly mangles functions with the same name in different subscopes (best shown
with an example):

int main()
{
    {
        struct A {
            int a;
            void f() {
                if(a<10) {
                    f();
                    ++a;
                }
           };
        };
        A x;
        x.f();
    }

    {
        struct A{
            int a;
            void f() {
                if(a<10) {
                    f();
                    ++a;
                }
            };
        };
        A x;
        x.f();
    }

    return 0;
}
----------------------------------------------------------------------------
••Defect Number: 6148, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Code resources that have static objects with constructors aren't handled properly. Code is
generated for the static construction function, but that function is never called.
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6165, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Nested type names aren't correctly adjusted by access declarations when referenced in function scope. Eg:

    struct C {
        struct C_nest { };
    };

    struct D : private C {
    public:
        C::C_nest;
    };

    void f()
    {
        D::C_nest n;    // Error: member C::C_nest of type D is not accessible
    }
----------------------------------------------------------------------------
••Defect Number: 6179, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Certain loop expressions can cause an internal error in CGcod.c, line 320. An example is:

    void f()
    {
        int j, k;
        int *p;

        while (j > !*p)
            k = !*p || *p;
    }

Workaround:

Turning on the global optimizer should fix the problem.
----------------------------------------------------------------------------
••Defect Number: 6184, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler doesn't produce the correct return type for new expressions that return pointer to
member types. Eg:
    void f()
    {
        struct X { int i; };
        int X::**px = new int X::*;  // Error: cannot implicitly convert from: int * to: int X::**
    }

Workaround:

Introduce a typedef for the desired type, and apply operator new() to that instead. Eg:
void f()
{
    struct X { int i;};
    typedef int X::*pmi;
    int X::**px = new(pmi);
}
----------------------------------------------------------------------------
••Defect Number: 6185, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Using operator new() for multidimensional arrays that have constructors produces an incorrect
type result. Eg:

    struct X {
        X();
    };

    void f()
    {
        X (*p1)[2] = new X[3][2];  // Error: cannot implicitly convert from: X* to: X(*)[2]
    }

Workaround:

Cast the result of operator new() to the desired type, or remove the object's constructor.
----------------------------------------------------------------------------
••Defect Number: 6186, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
When specifying too many storage class specifiers for member functions, the error message is not
always clear.  As in:

  class
     {
  public:
      int virtual inline g(int i){};// should give same error as below
      int inline virtual f(int i){};//storage class illegal in this context: ok
     };

Which produces different error messages depending on the order of the declaration.  Errors are:
File “6186.cpp”; Line 4
Error:   ';' expected

File “6186.cpp”; Line 5
Error:    storage class is illegal in this context

Workaround:

When the ; expected error message is received, suspect that perhaps too many storage specifiers
have been used.
----------------------------------------------------------------------------
••Defect Number: 6187, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Virtual functions cannot be declared with the inline specifier as in:

  class
     {
  public:
      int inline virtual f(int i){};//storage class illegal in this context
     };

Which should be allowed.

Workaround:

Leave the inline specifier off the virtual function when declaring it inside the class body.  It
will still be treated as inline.
----------------------------------------------------------------------------
••Defect Number: 6190, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
There is a problem declaring const pointers to members.  As in:

 struct A {int j;};
 int A::* const cpm;  // Error:   identifier or '( declarator )' expected

Workaround:

Do not declare pointers to members as const.
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6195, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
In certain cases, not all of the lines in a C++ program are able to be used for single stepping
as they should be.  As in:

#include <iostream.h>
#include <fstream.h>
#include <stdlib.h>

void main()
{
    ofstream outFile("copy.out", ios::out);

    if (!outFile)
    {
        cerr << "Cannot open" << endl;
        exit(-1);
    }
}

which does not have a diamond on the if statement and does not stop on the cerr statement when
single stepping or setting a breakpoint.
----------------------------------------------------------------------------
••Defect Number: 6204, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The debugger does not display the values of virtual base classes when displaying a class object.
As in:

struct X {
    int i;
};
struct Y : virtual X {
    int j;
};

void main()
{
    Y y;
    y.i = 1;
    y.j = 2;        // j is visible in the debugger, but i isn't
}

Workaround:

1. Make sure that the options are set to allow dataview function calls in the THINK project
manager options dialog box
2. Cast the sub-class as in:
(X *) &y
This will allow the values of X to be displayed.

----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6205, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler does not produce a sensible error message for the following code fragment:

// test.cpp
void foo(Bar *p);

It produces an error about a missing ')' and should complain about Bar being undefined.
----------------------------------------------------------------------------
••Defect Number: 6217, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Certain complicated expressions cause the compiler to produce an internal error as in:

void f(int *p)
{
    int j = 0;

    while (j >  (!( *p ) || ( *p )) )
        j =  (!( *p ) || ( *p )) ;
}

Which produces:
File “6217.cpp”; Line 10
Error:   internal error: file ::CG:CGcod.c line 320

Workaround:

Simplify expressions in cases where this internal error is received.
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW, THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5261, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Crash
Optimiser crash with multiple inheritance.
The following compiles ok unless the optimiser is on. Then it crashes with an internal error in
CGcod.c line 318.
    class Mummy { virtual void mumProc(); };
    class Daddy { virtual void dadProc() = 0; };
    void wantDaddy( Daddy * );

    class Baby : public Mummy, public Daddy {
        Baby();
        virtual void dadProc();
    };

    Baby::Baby() {
        wantDaddy( this );
        wantDaddy( this );
    }

Workaround:

If the order is changed so that Baby inherits from Daddy first, Mummy second, it works.
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 5429, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Crash
Problem with  PascalObject.  This file compiles and links, but dies with a bus error when  you
run it.

scpp temp1.cp
link {sclibraries}SCMainCpp.a.o temp1.cp.o {Libraries}Runtime.o {Libraries}Interface.o
{Libraries}ObjLib.o -o Temp

/* temp1.cp */
#include <Types.h>

class X : PascalObject {
    int xi;
    virtual void A(int i);
    virtual int B(void);
};

void main (void)
{
    X* x;
    int i;
    double f;
    x->A(5);
    long j = (i = 9) * (f = 1.2);
    i = x->B();
}

void X::A(int i)
{
    xi = i;
}

int X::B(void)
{
    return xi;
}
----------------------------------------------------------------------------
••Defect Number: 6160, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Crash
There is a problem using Pascal Objects outside of MacApp with the scpp compiler.  The following
SIOW program demonstrates the problem.  It will crash on the call to the virtual function.

#include <stdio.h>
#include <types.h>

class __pasobj A
{
 void hello  (void);
 virtual void goodbye(void);
};
void A::hello()
{
 printf("hello world\n");
}
void A::goodbye()
{
 printf("goodbye world\n");
}
void main(void)
{
 A *a = new A;
 a->hello  ();
 Debugger();
 a->goodbye();
}
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW, THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 4520, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Compiler fails to emit an error message when a destructor is declared const.
----------------------------------------------------------------------------
••Defect Number: 4521, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Compiler fails to emit an error message when a destructor is declared volatile.
----------------------------------------------------------------------------
••Defect Number: 4743, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Debug information is only generated for the last line of the following source.   Debug
information should be generated for each line. This problem occurs with the optimizer off.  The
right hand side expression need not be a constant expression; function calls have the same
effect.

typedef unsigned char bitfield;

struct {
    unsigned    b0  : 1;
    unsigned    b1  : 1;
    unsigned    b2  : 1;
    unsigned    b3  : 1;
    unsigned    b4  : 1;
    unsigned    b5  : 1;
    unsigned    b6  : 1;
    unsigned    b7  : 1;
} bits;

void main()
{
    bits.b0 = 1;
    bits.b1 = 1;
    bits.b2 = 1;
    bits.b3 = 1;
    bits.b4 = 1;
    /* ... */
}                   // breakpoint here
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 4786, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Declaring data static affects the compiler's ability to catch segment overflows.  Static
declarations which would cause a segment overflow cause the linker to produce an error message of
the following form:

### While reading file "test.c.o"
### Link: Error: Bad repetition count for data module. (Error 42) x (2)
   <Bad object file or compiler error.>

If the data is not declared static,  error messages of the following form are generated.  This is
the correct error message to be generated in either case.

### While reading file "test.c.o"
### Link: Error: 16-bit reference offset out of range. (Error 114)  at $0005A in main

Workaround:

Remove static data declarations that will create more than 32K of data or use the -model far data
option.
----------------------------------------------------------------------------
••Defect Number: 4879, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
When compiled with optimizations, the following source code causes a erroneous warning message
from the SCPP and SC compilers: #Warning 12: variable 'x' used before set

void main( void )
{
   struct s{unsigned long i25:25; unsigned int i1:1;
      unsigned long i27:27,i26:26;} x;

   x.i25 = x.i27 = x.i26 = 110;
 }

Workaround:

Ignore the warning.
----------------------------------------------------------------------------
••Defect Number: 4995, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The SC and SCPP compilers will not accept segment names that begin with a numeric character in
#pragma segment directives.

----------------------------------------------------------------------------
••Defect Number: 5356, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Building a MacApp application with Symantec C++ for MPW produces many Lib warnings about
duplicate code.  These warnings are correct; there is in fact duplicate code generated when
MABuild is run.

Workaround:

We have added a -d switch to the MABuild script in the current version to suppress these
warnings.  This is only a temporary fix for this problem.
----------------------------------------------------------------------------
••Defect Number: 5385, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
"SpinCursor" needs to be called more often from the SCpp optimizer and from the code generator.
The cursor is frozen during a long code generation and the machine appears to be dead.
----------------------------------------------------------------------------
••Defect Number: 5645, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
A code generation error produced by the SCPP compiler is demonstrated in the MacApp source file
UMacAppUtilities.cp.  The function IsColorPort() always returns false, even if it is passed a
color port.  The code generated by the following line in isColorPort() is incorrect:

    return ((((CGrafPtr)port)->portVersion) & 0xC000) == 0x0000C000;

SCpp generates code that sign extends the left side of the == to 0xFFFFC000,  and then compares
that to 0x0000C000.

Workaround:

Replace the line:
    return ((((CGrafPtr)port)->portVersion) & 0xC000) == 0x0000C000;
with:
    return ((((CGrafPtr)port)->portVersion) & 0xFFFFC000) == 0xFFFFC000;
----------------------------------------------------------------------------
••Defect Number: 5907, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Symantec C++ for MPW does not merge duplicate strings that occur in the same file.
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW, THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6015, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The C++ compiler causes an erroneous link error to be produced in the following situation:  there
is a header file declaring a class which declares a static const member of the same class type
and a constructor:

class A
{
public:
    A();
    static const A foo;
};

There are two source files which which include this header.  One contains the definition for the
static member and the constructor.  The other contains a main routine which references the static
member.

file 1:

const A A::foo;
A::A(){}

file 2:

void main()
{
    const A& a = A::foo;
}

An erroneous link error is produced, indicating that A::foo, referenced from file 2, is not
defined.
----------------------------------------------------------------------------
••Defect Number: 6120, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The C++ compiler produces an internal error in file ::CG:CGcs.c line 153 compiling the following
code fragment.  This occurs only when the optimizer is off.

inline   void * SGXWADDR(unsigned short x) {
   return (void *)(((unsigned long)x<<1)+0x80000000); }
extern "C" {
   void panic(short);
}
#define sems_allocated (*(unsigned short *)(SGXWADDR(1)))
class semaphore
  {
  void   operator delete(void *);
  };
void   semaphore::operator delete(void * p) {
  if (sems_allocated-- == 0) panic(1);
}
----------------------------------------------------------------------------
••Defect Number: 6121, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The C++ compiler produces an internal error in file CGelem.c line 2116 compiling the following
code fragment.  This occurs only when the optimizer is on.

void * const NIL_ = ((void*)0x00000000);
class dlink {      // doubly linked list element
  public:
  dlink *next, *prev;
  void unlink(void) {}
  };
inline int isNoneOrDamaged(dlink *p) {
  return ((void*)((unsigned long)p & -2UL) == NIL_); }
class semaphore
  {
  dlink locker;
  void   clear_locker(void) {
     if (! isNoneOrDamaged(locker.next))
        locker.unlink();
     }
  public:
     ~semaphore(void);
  };
  semaphore::~semaphore(void) {
  clear_locker();
  }
----------------------------------------------------------------------------
••Defect Number: 6122, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
An erroneous error is flagged for a pointer to a member in a class template.   The following code
fragment gives the erroneous error "tomni must be a class name preceding ::".

template <class T>
class tomni
    {
    T tomni::*pm; //tomni must be a class name preceeding ::
    };

tomni<int>;
----------------------------------------------------------------------------
••Defect Number: 6151, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The C++ compiler fails to flag as an error a call to a non-const overload of the () operator if
the object is a declared const object. It works correctly for operator [] and operator +.

 class foo
  {
    int data;
  public:
    int operator[](int ignored)
    {
      return data;
    }
    int operator()(int ignored)
    {
      return data;
    }
    int operator+(int ignored)
    {
      return data;
    }
  };

  void main( void )
  {
    const foo c;

    c[1];   // correctly flags this
    c(1);   // should flag an error here too
    c+1;    // correctly flags this
  }
----------------------------------------------------------------------------
••Defect Number: 6152, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
In argument matching, references should resolve to the closest parent.  In the following code
fragment,

struct A{};
struct B:A{};
struct C:B{};

void f(A &a);
void f(B &b);

void main() {
C c;    f(c); }

the call to f(c) should be resolved to f(B &b).  Instead the following error is produced:

Error:ambiguous reference to function
Had: f(Aref)
and: f(Bref)

Workaround:

Perform an explicit cast to insure that the reference is resolved.  In the example above, change
f(c) to  f((B) c).
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6175, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
SCPP cannot find nested header files specified by pathnames in the following situation:
1. Create a test folder outside of the MPW folder, called test.
2. Put the following 3 files in test:

test.cc:
     #include "::test:what.h"

what.h:
     #include "::test.stuff.h"

stuff.h:
     #define BLAHBLAH

3. Set the current directory to the test folder.
4. SCpp test.cc -o test.obj

Produces:
Fatal error: unable to open input file '::test:stuff.h'

Workaround:

Removing "::test:" from the #include line in either test.cc OR what.h prevents the error from
occurring. Also, if the test folder is inside the MPW folder, the include files are both found.
----------------------------------------------------------------------------
••Defect Number: 4523, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
A static member of a local class has no linkage; it cannot be defined.  SCPP does not flag an
error on the line indicated in the code fragment below.

void ign(void*);
int main()
    {
    class x {
    public:
        static int f();
        int j;
        };
    x xa;
    int x::f() { return 0; }; // should be an error: attempt to define static member local

    ign(&xa);
    return xa.f();
    }
----------------------------------------------------------------------------
••Defect Number: 5263, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The SCPP compiler reports syntax errors and warnings for class templates in template
implementation files as being in the file from which the template file is included.  The line
number reported is correct but the file name is incorrect.

Workaround:

Preprocess the file in which the error is reported and then compile this preprocessed file.  The
error will be reported correctly for the preprocessed file.
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW, THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5322, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The C++ compiler allows a static data member for a class to be initialized at class scope without
flagging an error.  This is illegal according to the ARM.  An error will occur at link time if
the code includes a static data member initialized at class scope.
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 5324, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler issues two copies of the same warning when a non const reference is initialized to a
temporary.  In this example, the compiler converts a short to an int before passing an int & to
the member function.

void CalledFunction(int & myInt)
{
    myInt++;
};
void main()
{
    short myShort = 0;
    CalledFunction(myShort);
};
----------------------------------------------------------------------------
••Defect Number: 5970, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler currently produces incorrect output of SYM information for an incomplete class
definition.
----------------------------------------------------------------------------
••Defect Number: 5971, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
The compiler does not limit itself to outputting type info only for referenced types.  This may
result in increased size of .o  and SYM files.
----------------------------------------------------------------------------
••Defect Number: 6021, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
SCPP produces a code generation error when compiling the following code fragment with the
optimizer on. The code generated for the statement "s[i] = c;" is incorrect.  The  code calls
operator[], but does not store c in the result returned by operator[].  An optimizer might be
able to do this if it knew that operator[] has no side effects, but the optimizer shouldn't assume this.

class myString
{
public:
    int GetLength() const;
    char operator[](int position) const;
};

class myStringSubclass : public myString
{
public:
    virtual char& operator[](int position);
};

class myString255 : public myStringSubclass
{
public:
    myuString255(const char *items);
};

void main () {
    int i;
    myString255 s("myString255");
    for (i=0; i<s.GetLength(); i++)
        {
            char c = s[i];
            s[i] = c;   // code gen problem occurs here
        }
}
----------------------------------------------------------------------------
••Defect Number: 6218, Symantec C/C++ for MPW
  Problem Area: SymC++ Compiler      Type: Incorrect Functionality
Certain pascal functions may generate an internal error if temporaries need to be implicitly
created for expressions in the return.

class myClass {
 pascal CPoint GetDesktopCoordinate(const VPoint& nextPoint);
};

pascal CPoint myClass::GetDesktopCoordinate(const VPoint& nextPoint) {
  VPoint theMouse = nextPoint;
  return VPtToPt(theMouse);
}/* GetDesktopCoordinate */

Workaround:

Replace the return line with:

CPoint c = VPtToPt(theMouse);
return c;
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: Rez
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5573, THINK C/C++
  Problem Area: Rez      Type: Incorrect Functionality
Running Rez on a .r file containing many huge arrays of data took over 20 minutes, vs. 30 seconds
for MPW Rez.
----------------------------------------------------------------------------
••Defect Number: 5851, THINK C/C++
  Problem Area: Rez      Type: Incorrect Functionality
Rez incorrectly assumes an array of only 2 elements of 1 byte instead of 6 bytes for each element
in the following example:

type 'try ' {
   array[2] {
   unsigned hex byte;
   unsigned hex byte;
   unsigned hex byte;
   unsigned hex byte;
   unsigned hex byte;
   fill byte;
   };
};

resource 'try ' (128) {
   {
    0xC3,
    0x19,
    0xF4, /* reported error here */
    0xE4,
    0xD8,
    0xC3,
    0x19,
    0xF4,
    0xE4,
    0xD8
   }
};
----------------------------------------------------------------------------
••Defect Number: 5853, THINK C/C++
  Problem Area: Rez      Type: Incorrect Functionality
Rez is unable to compile resources with an array of cases, when the size of an array element is
computed using a begin and end label. The size is being set to zero instead of the size of that
array element.   Example:

Start:
 key byte = rezType;
 fill byte;
 integer = (End[$$ArrayIndex(aName)]-Start[$$ArrayIndex(aName)]) >> 3;
 /* other information */
End:
----------------------------------------------------------------------------
••Defect Number: 5893, THINK C/C++
  Problem Area: Rez      Type: Incorrect Functionality
 Rez generates an internal error if it encounters this in a .r file:

          INCLUDE "Test" 'ICN#' (0) AS 'ICN#' (1,purgeable);  // internal error,

Workaround:

Remove purgeable; do not put anything after (1).
----------------------------------------------------------------------------
••Defect Number: 5955, THINK C/C++
  Problem Area: Rez      Type: Incorrect Functionality
include "File" 'rsrc' (id) as 'rsrc' (id + 1); fails. This is a serious problem for AOCE
templates.

----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: Debugger
----------------------------------------------------------------------------
    Product: THINK C
----------------------------------------------------------------------------
••Defect Number: 2357, THINK C
  Problem Area: Debugger      Type: Incorrect Functionality
Stepping through a call to OpenPicture in the debugger will cause the Debugger to crash.

Workaround:

Set a breakpoint on the next statement after the call and run to the breakpoint.
----------------------------------------------------------------------------
••Defect Number: 2751, THINK C
  Problem Area: Debugger      Type: Incorrect Functionality
Running a project with the Debugger when the clipboard (deskscrap) contains data over 1 Megabyte,
can cause the Debugger to become unstable.

Workaround:

In order to test Copy and Paste with large amounts of data in your projects, you may need to turn
the Debugger off.
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 4760, THINK C/C++
  Problem Area: Debugger      Type: Crash
The following steps will cause the machine to hang:  Run a program which puts up an alert box,
with the debugger enabled.  When the alert box comes up, hit command-shift-period and then hit
the ok button in the alert.  The machine hangs.  It was reproduced  on a Quadra 700, using system
7.1 with the following program.

void ToolBoxInit (void);
void ToolBoxInit ()
{
    InitGraf (&thePort);
    InitFonts ();
    InitWindows ();
    InitMenus ();
    TEInit ();
    InitDialogs (nil);
    InitCursor ();
}
main ()
{
    ToolBoxInit();
    Alert(128, nil);
}
----------------------------------------------------------------------------
••Defect Number: 5780, THINK C/C++
  Problem Area: Debugger      Type: Crash
With  68881, 68020, no nfp, Virtual Memory on,  stepping through this with the Debugger will
cause a bus error, or the debugger just quits:

#include <math.h>
int main()
{
 sin(1.0);
 return;
}

----------------------------------------------------------------------------
••Defect Number: 5408, THINK C/C++
  Problem Area: Debugger      Type: Incorrect Functionality
The debugger is in an odd state when there are expressions saved in the data window. When the
project is run, the debugger highlights the Data window instead of the Source window, and the Go
button is highlit. Single stepping is disabled unless the user selects "Clear all expressions",
hits "go", and starts the run over.

// Debug-test.cp
void MyFunction(unsigned char c, unsigned char keyCode)
{
c = keyCode;
};

void main()
{
MyFunction('a',0xd1);
}

Workaround:

Select "Clear all expressions", then hit "go", and start over.
----------------------------------------------------------------------------
••Defect Number: 5594, THINK C/C++
  Problem Area: Debugger      Type: Incorrect Functionality
Breakpoints cannot be saved if they are in #include'd files regardless of whether "Always Save
Session" is on or "Save All" is selected in the file menu.
----------------------------------------------------------------------------
••Defect Number: 5998, THINK C/C++
  Problem Area: Debugger      Type: Incorrect Functionality
Bug when trying to display a class member value in the Data window with an example program linked
with oopsDebug/++.  Typing in the following expression:
     shape ? shape->GetClassID () : 'NULL'
generates error:  ◊◊ contains a function call ◊◊
The debugger hangs upon exiting to shell.

----------------------------------------------------------------------------
••Defect Number: 6003, THINK C/C++
  Problem Area: Debugger      Type: Incorrect Functionality
If the file below is compiled with C++ and run in the debugger, single stepping reveals that DDP
is assigned a constant and still shows as 0 in the Dataview window, while pv will get the correct
value of 0xFEEDFACE.

typedef pascal short (*OptionsDefProc)(short msg, DialogPtr dp, EventRecord *event, short *item,
void *param);
static Handle options[2];
static OptionsDefProc DDP;
void *pv;

void main(void )
{
    DDP = (OptionsDefProc) 0xFEEDFACE;
    pv = DDP;
}
----------------------------------------------------------------------------
••Defect Number: 6109, THINK C/C++
  Problem Area: Debugger      Type: Incorrect Functionality
If you try to debug a file whose translator is missing (i.e. it was compiled at some earlier
time, but now the translator is gone), the debugger source window just comes up with an empty
window.  An error message to the effect "No translator installed for this file" should appear in
the source window.
----------------------------------------------------------------------------
••Defect Number: 4951, THINK C/C++
  Problem Area: Debugger      Type: Incorrect Functionality
You can't permanently position the Debugger's source code window within MenuBarHeight of the top
of a second screen.
----------------------------------------------------------------------------
••Defect Number: 5045, THINK C/C++
  Problem Area: Debugger      Type: Incorrect Functionality
Changing the project type to a non source debuggable type does not remove the Debug checkmark
even though debugging is not possible.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: Editor
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5483, THINK C/C++
  Problem Area: Editor      Type: Data Loss or Corruption
Compiling a file with a syntax error with an external editor which locks the data fork of the
file may cause unexpected behavior in the external editor.  The project manager returns the
fileRefNum used in the other application instead of the refnum that OpenDF returned when the file
was opened to obtain the line the error occurred on. This results in the file being closed without
the knowledge of the other application.
----------------------------------------------------------------------------
••Defect Number: 5166, THINK C/C++
  Problem Area: Editor      Type: Incorrect Functionality
There is a consistent markers drift in source files that is not due to the files being edited
with any editor. They seem to move up in the file over time.
----------------------------------------------------------------------------
••Defect Number: 5618, THINK C/C++
  Problem Area: Editor      Type: Incorrect Functionality
The Think Project Manager has a problem handling files with > 32K lines. Such a file can be saved
to disk, but cannot be scrolled past the first windowfull of lines. Doing "select all" followed
by "copy" or "paste" does nothing, but the user is given no notification of this.
----------------------------------------------------------------------------
••Defect Number: 4257, THINK C/C++
  Problem Area: Editor      Type: Incorrect Functionality
The text editor in the Think Project occasionally has inverted text synchronization problems
during scrolling.  Similar problems have been noted with Programmer's Editor Package.
----------------------------------------------------------------------------
••Defect Number: 4258, THINK C/C++
  Problem Area: Editor      Type: Incorrect Functionality
 You may get an update glitch if you do cmd-V, cmd-B, cmd-z. (Paste, Balance, Undo).
----------------------------------------------------------------------------
••Defect Number: 5431, THINK C/C++
  Problem Area: Editor      Type: Incorrect Functionality
If a multi-file batch search is performed on a string foo, selecting the first line in the Search
Results window and hitting "Enter" will cause the file containing that string to open up with the
appropriate occurrence selected.  However, if the next occurrence happens to be on the same line
as the first,  "Go To Next Match" does not select  the next occurrence.  The last match stays
selected.
----------------------------------------------------------------------------
••Defect Number: 6219, THINK C/C++
  Problem Area: Editor      Type: Incorrect Functionality
Duplicate markers shouldn't be created.  When the user selects a procedure name, and chooses
Mark, and an marker with the same name already exists, the old marker should be replaced (upon
confirmation by the user).
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: Headers
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6108, THINK C/C++
  Problem Area: Headers      Type: Incorrect Functionality
SetupA4.h contains functions for SetUpA4 and RestoreA4 that are declared inline for the C++
compiler. Problem is, if "use function calls for inlines" is on, the SetUpA4 mechanisms no longer
work. If they are changed to macro definitions,ie.

#define SetUpA4 { asm(0x2F0C); ... // instead of inline void SetUpA4(void) { ...

everthing works regardless of the compiler settings.

Workaround:

Use macro for inline definition.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: Libraries
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number:
6002, THINK C/C++
  Problem Area: Libraries      Type: Crash
68000 crash:
New_by_name doesn't work on 68000 machines.  NewClassDemo++ demonstrates the problem; when
running on a Mac Classic, it produces an address error in CStdPopupPane in the popup menus demo
dialog.

Workaround:

The following untested fix was suggested by a user and is not necessarily endorsed by Symantec:
Replace the "verify we've found a class info record" section in cp_new_by_name.cp with the
following:
;
;verify we've found a class info record
;
;- at entry, p = start of found name plus 2
;- verify by looking back before name. First check for '.', then look
;for 'CLASINFO'
;
;;
movea.l p, a0
sub.l   #12, a0 ; here starts the fix
move.l  (a0)+,d0
move.l  (a0)+,d1
and.l   #0x00FFFFFF,d0
cmpi.w  #'O.',(a0)
bne.s   @1
cmpi.l  #'SINF',d1
bne.s   @1
cmpi.l  #'\0CLA',d0
bne.s   @1
subq.l  #8, a0  ; skip length byte
----------------------------------------------------------------------------
••Defect Number: 4354, THINK C/C++
  Problem Area: Libraries      Type: Incorrect Functionality
IOStream Library:
Failbit is not set when an input value overflows its variable, i.e:

#include <iostream.h>
void main () {
int d;
cin >> d;             // give it 887234786234. It won't fail.
if (cin.rdstate() & ios::failbit)
    cout << "Bad input\n";
}
----------------------------------------------------------------------------
••Defect Number: 6079, THINK C/C++
  Problem Area: Libraries      Type: Incorrect Functionality
The function CRMGetToolResource is prototyped in CommResources.h but is not in the CommToolbox
Library.
----------------------------------------------------------------------------
    Product: THINK C/C++, Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6150, THINK C/C++, Symantec C/C++ for MPW
  Problem Area: Libraries      Type: Incorrect Functionality
Run this program and enter a couple numbers separated by carriage returns, and hit control-D. The
output contains two copies of the last number entered, indicating that when it hits the EOF it
incorrectly returns true once before returning false.
#include <iostream.h>
#include <console.h>

void main() {
    int n = 0, i;
    int temp;
    int a[50];

    cshow(stdout);
    while (cin >> temp)     // bug: (cin >> foo) true when should be false?
        a[n++] = temp;

    for (i = 0; i < n; i++)
        cout << a[i] << endl;
}
----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW, THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 6153, Symantec C/C++ for MPW, THINK C/C++
  Problem Area: Libraries      Type: Incorrect Functionality
The va_arg macro in stdarg.h is not fully parenthesized.  The result is that va_arg() does not
allow its result to be a struct.  For example the following code

#include <stdarg.h>

 struct X {int f(int n); };

void f_132p51(int i, ...)
{
         void *ap;
        va_arg(ap, X).f(-1);  // error here
}

results in this error:
Error: not a struct or union type

Workaround:

Changing
#define va_arg(p, type)            *(* (type **) &p)++
to
#define va_arg(p, type)            (*(* (type **) &p)++)
in stdarg.h will fix this problem.

----------------------------------------------------------------------------
    Product: Symantec C/C++ for MPW
----------------------------------------------------------------------------
••Defect Number: 6202, Symantec C/C++ for MPW
  Problem Area: Libraries      Type: Incorrect Functionality
There is a problem printing pascal strings due to a bug in SCLibraries:SCSrcLibC:printf.c.

case 'P':   /* pascal string */
   s = va_arg(pargs,char *);
// pargs += sizeof(char *);

The line: 'pargs += sizeof(char *);' causes printf to skip 4 bytes of any arguments following a
%P argument.

Workaround:

Comment the line out in printf.c to fix the problem.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: Linker
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5785, THINK C/C++
  Problem Area: Linker      Type: Data Loss or Corruption
The code below is part of an attempt to create a code resource that would modify itself using a
pc-relative addressing mode. The linker is unable to complete the relocation and corrupts the
code in the final link. The linker should be modified to produce an error message under these
circumstances.

void func(void);
void foo(void);

void main(void)
{
    *(long *)&foo = 1;      // generates bad code
    Debugger();
    *(long *)&func = 1;     // as does this
}

void foo(void)
{
    asm {
extern func:
        dc.l    0
   }
}
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: TCL
----------------------------------------------------------------------------
    Product: THINK Class Library
----------------------------------------------------------------------------
••Defect Number: 5692, THINK Class Library
  Problem Area: TCL      Type: Crash
If an object or subclass of CDialogText is gopher at the time the window which is its enclosure
is closed, the inherited::Dispose call will call BecomeGopher(FALSE), which will call Validate(),
which will attempt to read the contents of the macTE (calling CDialogText::GetTextString). The
macTE has already been disposed of and is no longer there, so this fails, causing the program to
bomb with a bus error.

Workaround:

The following workaround was suggested by a user.  It has not been tested by Symantec and is not
necessarily the solution that will be used to fix the problem:
Change:
void CDialogText::GetTextString( StringPtr aString)
{
   short length = Min( (**macTE).teLength, 255);
   BlockMove( *(**macTE).hText, &aString[1], length);
   aString[0] = length;
}  /* CDialogText::GetTextString */

to:
void CDialogText::GetTextString( StringPtr aString)
{
   short length;
   if (macTE)  {
      length = Min((**macTE).teLength, 255);
      BlockMove( *(**macTE).hText, &aString[1], length);
      aString[0] = length;
   } else {
      aString[0] = 0;
}
}
----------------------------------------------------------------------------
••Defect Number: 5840, THINK Class Library
  Problem Area: TCL      Type: Crash
CSizeBox::Activate will fail if it is called and the window which encloses it is not yet the
current port.

Workaround:

The following workaround was suggested by a user.  It has not been tested by Symantec and is not
necessarily the solution that will be used to fix the problem:

In CSizeBox::Activate(), replace the call to InvalRect() with a call to Refresh().
----------------------------------------------------------------------------
••Defect Number: 2507, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
The EqualMem routine can only compare even length data (except for a single byte, which it
special-cases), and it cannot operate on more than 32K of data at a time.
----------------------------------------------------------------------------
••Defect Number: 2734, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
The menuID in the MenuInfo record can be different from its MENU resource ID. The code in the
CPopupMenu::PopupSelect method assumes that they are the same.  When they are different the wrong
menu pops up.

Workaround:

The following workaround was suggested by a user.  It has not been tested by Symantec and is not
necessarily the solution that will be used to fix the problem:
Adding the line indicated below will make CPopupMenu more robust:
void CPopupMenu::IPopupMenu( short aMenuID, CBureaucrat *aSupervisor,
    Boolean fAutoSelect, Boolean fMultiSelect)
{
...
   if (!macMenu)    /* no it hasn't */
   {
   /* add the menu, but don't install into the menu list */
   gBartender->AddMenu( menuID, FALSE, 0);
   macMenu = gBartender->FindMacMenu( menuID);
   /* it better have been found now */
   FailNILRes( macMenu);
   (*macMenu)->menuID = menuID;    /*** THIS IS THE NEW LINE ***/
   }
----------------------------------------------------------------------------
••Defect Number: 3060, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
In the NewClassDemo (C only), follow these steps:
1) Open a String Table Demo
2) Scroll to the bottom of the list.
3) Select the last one.
4) Click the "Delete" button
Repeat 3 and 4 until there are no more items in the list and an assertion failure will occur:

"Assertion Failed: position.v<=bounds.bottom
"File CPanorama.c
"Line 182

which is in CPanorama::SetBounds.  Apparently the drawing area has become too small when the last
item is deleted, and no check has been made on its size before calling SetBounds.
----------------------------------------------------------------------------
••Defect Number: 3091, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
The CPanorama::Pagination method will print an additional horizontal or vertical strip if the
pixel extent of the CPanorama object is equal to the page width. The extra strip should not be
added if the extent is an even multiple of the page size.
----------------------------------------------------------------------------
••Defect Number: 3092, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
The CDocument::Notify method sets the dirty flag even if a NULL is passed for the task.
----------------------------------------------------------------------------
••Defect Number: 3106, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
The parameters aHEncl, aVEncl in all of the TCL Pane subclasses are declared short, although the
instance variables hEncl, vEncl are long. This makes it impossible to initialize a pane to a long
coordinate position.
----------------------------------------------------------------------------
••Defect Number: 3114, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
CApplication::Process1Event() uses
aDAIsActive = IsSystemWindow((WindowPeek)FrontWindow());
to determine if a DA is active. This will not work for DA's that do not have windows (i.e. have
menus only).
----------------------------------------------------------------------------
••Defect Number: 4343, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
In CPrinter::OpenPrintMgr(),:if fCheckError is TRUE and an PrError returns an error, printMgrOpen
needs to be reset to false.
----------------------------------------------------------------------------
••Defect Number: 4344, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
CArrayPane::Dispose() does not cancel the dependency with its array.

Workaround:

The following workaround was suggested by a user.  It has not been tested by Symantec and is not
necessarily the solution that will be used to fix the problem.

Add the following lines after the opening brace of CArray::Dispose() to guarantee cancelling of
the dependency with the array:
if( itsArray )
    CancelDependency( itsArray );
----------------------------------------------------------------------------
••Defect Number: 4345, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
CDialogDirector::EndDialog() provides no way to avoid validation of a dialog when the user hits
cancel.

Workaround:

The following workaround was suggested by a user.  It has not been tested by Symantec and is not
necessarily the solution that will be used to fix the problem:

To avoid validation when the user hits cancel, hide the window.
Boolean CDialogDirector::EndDialog( long withCmd, Boolean fValidate)
{
   Boolean closeIt = TRUE;
   if (itsWindow)
   {
      if(withCmd==cmdCancel)    // To avoid validation of dialog
      {                           //text on a cancel, we hide the window.
         itsWindow->Hide();
         fValidate = FALSE;
      }
      if (fValidate)
         closeIt = Validate();
      if (closeIt)
        dismissCmd = withCmd;
      }
      return closeIt;
   }    /* CDialogDirector::EndDialog */
----------------------------------------------------------------------------
••Defect Number: 4349, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
Since CClipboard::DataSize() may generate an exception and some code (such as menu updating)
doesn't expect errors, it needs to have TRY/ENDTRY statements around its code and to just return
0 if an error occurs.

----------------------------------------------------------------------------
••Defect Number: 5665, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
In the TinyEdit demo, no blinking caret appears when a new document is opened.  The caret appears
when the user begins typing, but disappears again after a carriage return.
----------------------------------------------------------------------------
••Defect Number: 5688, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
The call to SendBehind () in CFWDesktop::SelectWind() will only work if aWindow is a desk
accessory.

Workaround:

The following workaround was suggested by a user.  It has not been tested by Symantec and is not
necessarily the solution that will be used to fix the problem:

Change aWindow->macPort to aModal->macPort, in the call to SendBehind.
From CFWDesktop::SelectWind():
if (theWindow->IsFloating()) {      /* Select a floating window         */
   if (theWindow != topFloat) {    /* If this isn't the top float ...  */
      // TCL 1.1.3 11/30/92 BF
      aModal = GetLastModal(&anyModalsVisible);
      if (aModal)                 /* If there is a modal window       */
         /*   Put floating window behind it  */
         SendBehind(theWindow->macPort, aModal->macPort);  // CHANGED LINE
      else
         /*   Make it the front window       */
         BringToFront(theWindow->macPort);
         /*   Update our window list         */
         itsFloats->BringFront(theWindow);
         theWindow->Show();          /*   Make it visible, if necessary  */
         topFloat = theWindow;       /*   Mark it as the top float       */
         /* Suppress deactivate - normal     */
         /*   window remains "in front"      */
         CurDeactive = NULL;         //   TCL 1.1.3 11/30/92 BF
      }
   } else if (theWindow != topWindow) {
----------------------------------------------------------------------------
••Defect Number: 5712, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
In the CPaneBorder class, borderFlags is defined as a long as an instance variable, and as an
argument to all methods that use it except for IPaneBorder, which defines it as a short.  It
should be a long everywhere.
----------------------------------------------------------------------------
••Defect Number: 5724, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
The error handling code in CObject::SubclassResponsibility() should be an ASSERT or other type of
alert, rather than a DebugStr();

----------------------------------------------------------------------------
••Defect Number: 5749, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
NewClassDemo reveals the following bug: Type something, then save, then without doing anything
else continue typing. The Save command is disabled, since no new task was posted.

Workaround:

The undo buffer needs to be reset (with a Notify(NULL)) after the save.
----------------------------------------------------------------------------
••Defect Number: 5793, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
There is a problem with CIconPane.cp with C++ only. The problem comes from the fact that the
toolbox call PlotCIconHandle() does not seem to modify the return code if no error occurs. This
is not a problem in Think C, since it pushes a 0 on the stack. C++, however, just decrements the
stack by two, then makes the call. This means that PlotCIconHandle() seems to return an error
code even if nothing bad happened, since it's just reading whatever garbage was left on the
stack.

Workaround:

The following workaround was suggested by a user.  It has not been tested by Symantec and is not
necessarily the solution that will be used to fix the problem:
This modification to the tcl_PlotCIconHandle() inline definition at the top of CIconPane.cp will
work with both C and C++:
/* Need to clear out the return value, because PlotCIconHandle doesn't seem to set it, so C++
call fails, because it just subtracts 2 from SP, rather than  pushing 0, as C does.
We add:
MOVEQ #$0, D0   ;0x7000
MOVE.W D0, $C(A7)   ;0x3f40, 0x000c
*/
pascal OSErr tcl_PlotCIconHandle( Rect*, short, short, CIconHandle) = { 0x7000, 0x3f40, 0x000c,
0x303C, 0x61F, tcl_IconDispatch};
----------------------------------------------------------------------------
••Defect Number: 5794, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
CSwitchboard:DoUpdate(), CSwitchboard::DoActivate() and CSwitchboard::DoDeactivate() have the
potential to call member with a NULL object, since EventToWindow() will return NULL for a non TCL
window.

w = EventToWindow(macEvent);      // this returns a NULL for nonTCL window!!
if (member(w, CWindow))           // causing member() to get a bus error
.....;


Workaround:

The following workaround was suggested by a user.  It has not been tested by Symantec and is not
necessarily the solution that will be used to fix the problem:
Change
w = EventToWindow(macEvent);      // this returns a NULL for nonTCL window!!
if (member(w, CWindow))           // causing member() to get a bus error
...;

to:
w = EventToWindow(macEvent);      // this returns a NULL for nonTCL window!!
if (w && member(w, CWindow))      // checks for non-NULL, preventing crash
...;
----------------------------------------------------------------------------
••Defect Number: 5926, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
CRunArray::FindSum() will crash with a divide by zero error on a CRunArray object whose first
members are zero, as when making a CTable's first row's height equal to zero.

Workaround:

The following workaround was suggested by a user.  It has not been tested by Symantec and is not
necessarily the solution that will be used to fix the problem:
In CArray::FindSum():
put
if (currRun->value!=0)
before the line
    currIndex -= (currSum - aSum -1) / currRun->value + 1;
----------------------------------------------------------------------------
••Defect Number: 5983, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
In CApplication::Idle()
The if statement

    if (rainyDay != NULL) {
        DisposHandle(rainyDay);
    }
should read

    if (rainyDay != NULL) {
        DisposHandle(rainyDay);
        rainyDay = NULL;
    }
This affects execution in very low memory situations.

Workaround:

Change CApplication::Idle() as indicated above.
----------------------------------------------------------------------------
••Defect Number: 5984, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
In CDLOGDialog::IDLOGDialog()
After the line
    FailNILRes( dlogTemplate);

should be the following lines:

    savedState = HGetState( (Handle) dlogTemplate); // currently further down in the code.
    HNoPurge((Handle) dlogTemplate)                 // new addition

These changes prevent the possiblility of dlogTemplate being purged before it is locked and used
towards the end of the method code. This affects execution in very low memory situations.

Workaround:

Change CDLOGDialog::IDLOGDialog() as indicated above.
----------------------------------------------------------------------------
••Defect Number: 6028, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
At the top of the CCluster.cp file, in the comments for TCL 1.1 changes it notes that "CCluster
is now a superclass of CArray".  In fact the opposite is true, CCluster is a subclass of CArray.
----------------------------------------------------------------------------
••Defect Number: 6080, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
In CPane.cp, the comment for 1.1.3 changes claims that GetEnabled() and SetEnabled() methods have
been added but no such methods exist.
----------------------------------------------------------------------------
••Defect Number: 6093, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
The MAXLONG and MAXINT definitions conflict in files Values.h (Mac #includes) and Global.h (TCL
Core Classes). Global.h hard codes MAXINT and MAXLONG to 32767 and 0x7FFFFFFF. Values.h ties them
to sizeof(int) and sizeof(long).
----------------------------------------------------------------------------
••Defect Number: 6140, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
In the CBartender::SetMenuBarState() method, the line:
            oldState |= ((**(entry->macMenu)).enableFlags & 1) << i;
should read:
            oldState |= ((**(entry->macMenu)).enableFlags & 1) << n;

since i is the index into the Bartender's menu array (which includes both menu bar and
hierarchical menus), while n is the index of menu bar menus. The effect of this bug is that the
menu bar state isn't properly restored
after closing a modal dialog.
----------------------------------------------------------------------------
••Defect Number: 6161, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
gInBackground is NEVER initialized.  It is only set in CApplication::Suspend and Resume.
----------------------------------------------------------------------------
••Defect Number: 6220, THINK Class Library
  Problem Area: TCL      Type: Incorrect Functionality
The GetSteps() method in CEditText doesn't preserve the QuickDraw environment. It calls
GetTEFontInfo() so that it can GetFontInfo() but doesn't set the font back to what it was before.

----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: UI & Environment
----------------------------------------------------------------------------
    Product: THINK C
----------------------------------------------------------------------------
••Defect Number: 2645, THINK C
  Problem Area: UI & Environment      Type: Incorrect Functionality
Some sort of warning should alert the user to the following unexpected behaviour : Given the
following project structure:

  MyProject ƒ:
    MyProject.π
    main.c
    TempFolder ƒ:
      dummy.c

If you open up main.c, and then use "Save As" to save it in the folder "TempFolder ƒ", the THINK
Project Manager *deletes* the old copy of main.c and writes a new one into the folder "TempFolder
ƒ". This is contrary to user expectations. If you use Save As to give a file a different name, it
doesn't remove the old file.
   This is partly understandable since the THINK Project Manager requires that there be no
duplicate filenames in two different trees.

----------------------------------------------------------------------------
••Defect Number: 5034, THINK C
  Problem Area: UI & Environment      Type: Incorrect Functionality
#include "filename.h" does not work exactly as documented.  Note the double quotes.
The THINK Project Manager looks first in the referencing folder, then in the project tree, and
finally in the THINK Tree.

This works as documented, EXCEPT when the referencing folder is in the THINK Tree.  In that case,
the THINK Project Manager looks first in the referencing folder, THEN in the THINK Tree, and
finally in the project tree.

Workaround:

Do not put project specific files in the THINK Project Manager tree.
----------------------------------------------------------------------------
••Defect Number: 4756, THINK C
  Problem Area: UI & Environment      Type: Incorrect Functionality
On a German keyboard running system 7.1, command-period (cancel) does not work at all under the
debugger.
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5236, THINK C/C++
  Problem Area: UI & Environment      Type: Crash
TPM crashes (address error) on a Centris 610 when launched from an AppleShare file server over
LocalTalk.  This is with all extensions except for AppleShare, Memory and Cache Switch (all
System Software things) disabled manually.

Workaround:

Turning 040 caches off corrects the problem.
----------------------------------------------------------------------------
••Defect Number: 6066, THINK C/C++
  Problem Area: UI & Environment      Type: Crash
Open a project containing enough files so that the project window scroll bars are active (a TCL
project works well).  Select the project, hit END, and option-click on one of the arrows to
compress the project window.  Then hit HOME, END, HOME, END.  TPM will hang.
----------------------------------------------------------------------------
••Defect Number: 5755, THINK C/C++
  Problem Area: UI & Environment      Type: Crash
Unimplemented trap sometimes occurs in Add Files dialog under system 6.
----------------------------------------------------------------------------
••Defect Number: 3018, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If "Confirm Saves" is off, closing the window of a file that's in a write-protected folder (i.e.
on a server) gives an "Unknown Error -5000" alert. (-5000 is an AppleShare privilege violation.)
The only way to close the window is to turn on "Confirm Saves", close the window, and click
"discard changes".
----------------------------------------------------------------------------
••Defect Number: 4045, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Files should open on the same monitor as the project window.
----------------------------------------------------------------------------
••Defect Number: 4146, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If a resource file named <projname>.rsrc is added to a project named <projname> so that it can be
double-clicked on in the project window, TPM says that resources are duplicated when the project
is brought up to date.   At the very least, TPM shouldn't allow the .rsrc file to be added in the
first place. At the very best, it should be able to handle this case when old-style projects are
being used.
----------------------------------------------------------------------------
••Defect Number: 4253, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
The Project Manager incorrectly allows you to add multi-segment projects to projects.
----------------------------------------------------------------------------
••Defect Number: 4584, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
When a project is run from within THINK Project Manager the resource flags (preload, locked,
etc.) of the segments of the application seem to be ignored. Therefore, a built application's
segments behave differently than the segments of a project run within the environment. This makes
it difficult to debug segmentation-related problems at the source level. (In fact, the default
segment flags CAUSE problems that modified flags could solve, like heap fragmentation, segments
getting loaded at the wrong time, etc.)
----------------------------------------------------------------------------
••Defect Number: 4699, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
There is an editor problem with scrolling selections into view. If a line is triple clicked, and
its left edge is not showing, it scrolls into view. If an item is double-clicked that extends
over the right edge, it too will scroll into view.  Instead, the current scroll selection should
be maintained.
----------------------------------------------------------------------------
••Defect Number: 4919, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
There is no dependency between a .o file and a .v file for the .o converter. If a .v file is
changed, its .o is not re-compiled when the project is updated.

Workaround:

re-compile the .o file as soon as you've edited the .v file
----------------------------------------------------------------------------
••Defect Number: 5102, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Choose New Project: the button to make it so is called Create when the dialog opens and as long
as one travels upwards in the folder hierarchy. But start traveling downwards and the button
changes to Save. It should change to Create again when a project name is entered.
----------------------------------------------------------------------------
••Defect Number: 5109, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If a project's rsrc file is open when an app is being built, TPM does everything except copy the
resources, yet doesn't notify the user that the resources weren't copied.

Workaround:

close .rsrc file before building apps
----------------------------------------------------------------------------
••Defect Number: 5146, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
When TinyEdit TCL program was built with low disk space (only 22K free when TPM attempted to load
MacTraps2)  the machine hung with the compilation progress window up. Got out with
cmd-option-escape.
TPM should check for low disk space, and put up an alert.
----------------------------------------------------------------------------
••Defect Number: 5170, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If an external editor is used, TPM closes the current project when user chooses Quit, but doesn't
always actually quit.
----------------------------------------------------------------------------
••Defect Number: 5249, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
When project windows are printed out, the resulting printout includes segment numbers but not
their names, as they appear in the actual window.
----------------------------------------------------------------------------
••Defect Number: 5468, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If a project includes another project that is locked, and the locked project is double-clicked in
the project window, a dialog box comes up in the Finder instead of in the TPM.
----------------------------------------------------------------------------
••Defect Number: 5528, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
There is a problem with header files in the project tree that have the same name as a file they
include in the THINK tree, for example a file called time.h in the project tree that includes
<time.h>. TPM says it can't open the file and then gets confused.
----------------------------------------------------------------------------
••Defect Number: 5575, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
With the "re-open files" option selected, the editor doesn't re-open the .h files that were left
open in the project.
----------------------------------------------------------------------------
••Defect Number: 5587, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If a source or include file cannot be found, the batch compilation stops with an alert. That
notice should go into the error list instead and the update should continue with the next source
file.
----------------------------------------------------------------------------
••Defect Number: 5616, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
When projects are moved from one machine to another,  files in the project sometimes can't be
found when the project is updated, even when they are still in the project tree.
----------------------------------------------------------------------------
••Defect Number: 5644, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
The string displayed in the first screen of the TPM about box should be "Symantec C++ for
Macintosh"  not just "Symantec C++".

----------------------------------------------------------------------------
••Defect Number: 5670, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If a Run is done after a Remove Objects on a project containing multiple items, and the compile
is aborted with command-period, the compile stops but the Run is still attempted. A Link Errors
window may appear, depending upon the state the project is in.
----------------------------------------------------------------------------
••Defect Number: 5676, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If the C++:Debugging option is changed from  "Report 1st few errors" to "Report all errors",
every source in the project is recompiled during an Update.
----------------------------------------------------------------------------
••Defect Number: 5777, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
When a batch search is resumed (command T), the progress window says "file n of 1" for each file
searched. Also, 1 or 2 lines at the top of the Search Results window get overwritten when an
interrupted batch search is resumed.
----------------------------------------------------------------------------
••Defect Number: 5897, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If a "batch" compile is in progress it's sometimes necessary to keep pressing Cmd-period over and
over again to cancel the batch.  It then doesn't save the results of the compilation up to the
stopping point.
----------------------------------------------------------------------------
••Defect Number: 5922, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If a file is mapped to the "None" translator, it can't be included in a multi-file search.
----------------------------------------------------------------------------
••Defect Number: 5963, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If an alias to an unmounted server is in the alias folder, the Finder will open the mount-server
dialog every time a project is opened or created.

Workaround:

Hitting cancel in the dialog allows the user to continue.
----------------------------------------------------------------------------
••Defect Number: 5967, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Applescript support bug:  The 'compiled_at' and 'modified_at' properties are returned
appropriately,  but AppleScript can't do anything with them, complaining that an arithmetic
operation is impossible because a value is too large.
----------------------------------------------------------------------------
••Defect Number: 5972, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Applescript bug: TPM doesn't deal with "every" at all, e.g.
    name of every segment of project document 1
gives a "some data was the wrong type" error. This disallows the very useful "repeat
with...in..." construct:
    repeat with seg in every segment of project document 1
        name of seg
    end repeat

Workaround:

use numeric-index loops, as shown in the examples supplied with TPM.
----------------------------------------------------------------------------
••Defect Number: 5974, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
AppleScript issue: GetData of most special classes fails. For instance, "source 1 of project
document 1" by itself gets a "descriptor type mismatch" error. It should just return an object
specifier representing the first source file.  I can't say:
    name of selection of project document 1

Workaround:

 use:   set x to selection of project document 1
           name of x
----------------------------------------------------------------------------
••Defect Number: 5980, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
On occasion, option-clicking in the title bar of a connected source file does not produce the
list of included header files.

Workaround:

deactivate the source window in question and re-activate it, then try again
----------------------------------------------------------------------------
••Defect Number: 6017, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If the TPM allows users to modify locked files, it should do two things:
- warn the user when opening locked files directly through the TPM, so the file can be unlocked
before editing.
- not allow the user to close a modified locked file without explicitly throwing away changes
made to the document.  If the user decides to save, the Save As dialog should be presented.
Alternatively, allow the user to open the file but not edit it, a la checked-out read only files.

----------------------------------------------------------------------------
••Defect Number: 6074, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
According to the Macintosh Human Interface Guidelines (p. 140), scroll bars in inactive windows
should not be drawn at all; instead, an empty box should be drawn where the scroll bar would
normally be drawn.
----------------------------------------------------------------------------
••Defect Number: 6102, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Double-clicking on .o or library files in the project window produces the incorrect error message
"<some file>.o" cannot be opened because its translator is missing".
----------------------------------------------------------------------------
••Defect Number: 6170, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Update glitch:  compile a file containing these 3 lines:
int i;
...
int j;

Select the three lines, select Compile errors window, hit Enter to select the error, deselect.
There are 2 leftover thin highlighted lines above and below the error.

----------------------------------------------------------------------------
••Defect Number: 4197, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Apple event interface problem: Apple events for getting file info cannot go across networks,
since FSSpecs are local. The FSSpec should be replaced by an alias.

----------------------------------------------------------------------------
••Defect Number: 4425, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Even when "Confirm Project Updates" is not checked,    "Link..." asks if you want to bring
the project up-to-date.
----------------------------------------------------------------------------
••Defect Number: 5378, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
There is an issue with Menu Sharing with Frontier, regarding having the target app in the
debugger receiving all 'KAHL' events. At the very least, the shared menus should be disabled
while debugging.
----------------------------------------------------------------------------
••Defect Number: 5452, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Even with the Always Check File Dates option turned on in the TPM Preferences, source code
outside the project folder is not always checked during an Update or Make.
----------------------------------------------------------------------------
••Defect Number: 5725, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
If Page Setup is chosen after installing new System software and launching a TPM project, nothing
happens.  An alert should come up telling the user to select a printer in the Chooser.
----------------------------------------------------------------------------
••Defect Number: 6115, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Although TPM appears to remember the location of ".c" files that were aliased through the Aliases
folder, it seems to do an exhaustive search each time a ".h" file is requested that is contained
in one of the aliased folders, thus slowing down compiles.
----------------------------------------------------------------------------
••Defect Number: 6214, THINK C/C++
  Problem Area: UI & Environment      Type: Incorrect Functionality
Many Standard Libraries files have a creation date later than the last modification date.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: SCCS
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 4928, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
When user tries to Checkout at the same time as someone else, a cryptic permissions error appears
instead of the friendly "Are you sure you want to keep waiting?" MPW Projector dialogs:
### NameRevisions - Unable to open project "ProjectorDBs∫" in directory "Source:ProjectorDBs:".
# OS error -54 (Error message file not available)
----------------------------------------------------------------------------
••Defect Number: 4935, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
When using Checkout To: another directory, the “Directory” button should select the directory
that you’re in, not the folder selected. Or, at least, there should be a way to select the
directory that you’re in, rather than have all
the buttons dim when you get to it.
----------------------------------------------------------------------------
••Defect Number: 4940, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
There is no way in the SourceServer interface to remove a file from a project DB once it's in
there.

Workaround:

use MPW's DeleteRevisions -y
----------------------------------------------------------------------------
••Defect Number: 5057, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
When a checked-out file is checked in, the task and comment fields are blank. They should default
to the text the user supplied when the file was checked out, rather than requiring re-entry of
the information.
----------------------------------------------------------------------------
••Defect Number: 5085, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
Pressing Return in the Check In/Out dialogs presses the default button instead of entering a
return character into the text, as it does in MPW.
----------------------------------------------------------------------------
••Defect Number: 5207, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
The check out window incorrectly allows you to request a non-leaf version of a file modifiable
non-branch.
It should default to read-only.  In any case, if modifiable is selected, branch should be
automatically checkmarked (and the user shouldn't be able to turn it off).
----------------------------------------------------------------------------
••Defect Number: 5313, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
When checking out source files from a ProjectorDB created with MPW 3.2, the source file is
recorded as checked out from a NULL user,  even though there was a user name in the Check Out
dialog.  Trying to check that file back using MPW is then impossible.
----------------------------------------------------------------------------
••Defect Number: 5682, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
Using the command line to set the checkout directory (checkoutdir <pathname>) to the same path as
the current directory (which appears as the second item in the "Check out to: <directory>" popup
in the CheckOut dialog), causes the pathname to appear twice in a row in this popup menu
thereafter.
----------------------------------------------------------------------------
••Defect Number: 5885, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
In the SourceServer CheckIn dialog, files which cannot be checked in (i.e. they are read only,
checked out by someone else or not found) should be dimmed.
----------------------------------------------------------------------------
••Defect Number: 5886, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
In the SourceServer CheckOut dialog, the icons in the revision view list are not updated when one
performs a checkout or an undo checkout.
----------------------------------------------------------------------------
••Defect Number: 5888, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
If a file is checked in that cannot be found, the failure is silent; the user gets no warning
message or other notification that the file was not checked in.
----------------------------------------------------------------------------
••Defect Number: 5889, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
If two projects are mounted and "set project" is done on the one that is not current,  the
project popup in the checkin dialog does not indicate the correct project.  If the popup is then
used to switch to the correct project, the icons in the list are not updated.
----------------------------------------------------------------------------
••Defect Number: 5890, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
The task and comment fields in the checkout dialog should be dimmed when checking out read-only.
----------------------------------------------------------------------------
••Defect Number: 5947, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
MPW Projector allows carriage returns in Checkout Info.  If such a Projector database is ported
to the TPM and opened in SourceServer, clicking on the INFO button in the CheckOut dialog where
the info contains a carriage return causes the popup menus to stop working, and displays only the
text in the window up to the CR.
----------------------------------------------------------------------------
••Defect Number: 5968, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
In the Source Server checkout dialog,  the "By Name" popup pops up but doesn't work in the
revision view.  It should move up a level to the file view and then select the appropriate files.
----------------------------------------------------------------------------
••Defect Number: 6095, THINK C/C++
  Problem Area: SCCS      Type: Incorrect Functionality
If a file is changed and not saved and then checked in using "Check in <filename>", the changed
version gets checked in just as it should.  The changed file is now Read-only. However, if the
file is checked in with "Check in ...", the behavior is different: the changed file gets checked
in, and a read-only icon appears in the lower left, BUT if the file is closed, a dialog comes up
asking whether to save changes. And if the user says no, the read-only file actually gets changed
back to what it was before it was edited.
----------------------------------------------------------------------------
----------------------------------------------------------------------------
Problem Area: Utilities & Demos
----------------------------------------------------------------------------
    Product: THINK C/C++
----------------------------------------------------------------------------
••Defect Number: 5744, THINK C/C++
  Problem Area: Utilities & Demos      Type: Incorrect Functionality
In the Vector demo, typing "vi.size()" or "nextLetter(c1)" into the Data window yields "illegal
instruction" or "bus error".
----------------------------------------------------------------------------
••Defect Number: 5745, THINK C/C++
  Problem Area: Utilities & Demos      Type: Incorrect Functionality
Problems with the profiler and C++ methods:
   1) overloaded calls get chopped off with no way to distinguish them.
   2) mangled names show up in certain cases.

----------------------------------------------------------------------------
End of Report.