HDTenEightyP/NetNews huggingface dataset:
From: rollins@bart.ee.queensu.ca (Mark Rollins)
Subject: delete [size] pointer; Problem
Organization: Queen's University, Kingston
Distribution: gnu
Date: Thu, 3 Sep 1992 18:01:03 GMT


PROBLEM DELETING A VECTOR OF CLASS OBJECTS
------------------------------------------

Using the syntax of Stroustrup's 1st edition, pg. 162
and g++ version 2.2.2, libg++ version 2.1, and SunOS 4.2.2 I get
correct results but a compiler warning:

   g++ -o bin/junk badmem.cc -lg++ -lm
   badmem.cc: In method `Vector::~Vector ()':
   badmem.cc:9: warning: use of array size with vector delete is anachronistic

If I omit the array size, the Vector does not get de-allocated
properly using the destructor, and all virtual memory gets eaten up
rather quickly. (It's probably just deleting the 1st one in the array).

What is the proper syntax for deleting a vector of class objects ?
Or is there any way to turn off this annoying warning flag ?

-----------------------------------------------------------------
Working version that produces a warning:
-----------------------------------------------------------------
#include <Complex.h>

class Vector {
  int		size;
  Complex	*v;
 public:
  Vector(int s=1) { size = s; v = new Complex[size];};
  ~Vector() { delete [size] v;}
};

void foo(int s)
{
  Vector junk(s);
}

main()
{
  Vector* test;
  for (int i=0;i<100000;i++) 
	foo(1000);
}
-----------------------------------------------------------------
Buggy version that quickly uses up all virtual memory:
  (difference is in the ~Vector() destructor)
-----------------------------------------------------------------

#include <Complex.h>

class Vector {
  int		size;
  Complex	*v;
 public:
  Vector(int s=1) { size = s; v = new Complex[size];};
  ~Vector() { delete v;}
};

void foo(int s)
{
  Vector junk(s);
}

main()
{
  Vector* test;
  for (int i=0;i<100000;i++) 
	foo(1000);
}


-- 

******************************************************************
*  Mark Rollins                |email:                           *
*  Dept. Elec. Eng.            |  rollins@eleceng.ee.queensu.ca  *
*  Queen's University          |                                 *
*  Kingston, Ontario, CANADA   |                                 *	
*  K7L-3N6                     |                                 * 
******************************************************************

Newsgroups: gnu.g++.bug
From: brennan@hal.com (Dave Brennan)
Subject: compilers bomb on functions returning reference to array
Organization: HaL Computer Systems, Austin, TX
Distribution: gnu
Date: Wed, 2 Sep 1992 19:17:02 GMT

ARM 8.2.5 states that "Functions cannot return arrays or functions,
although they can return pointers and references to such things."

Both g++ and Lucid compilers will generate errors and refuse to compile
programs that try to define or use functions returning references to
arrays.  Here's an example so you can test your favorite compiler:

typedef int jmp_buf [9];

class foo
{
public:
  jmp_buf my_buf;

  jmp_buf &get_my_buf ()    // Lucid CC doesn't like this
    { return (my_buf); }
};

void
use_my_buf (jmp_buf)
{
  // do_something ();
}

int
main ()
{
  foo bar;

  use_my_buf (bar.get_my_buf ());  // g++ and cfront (sort of) don't like this
  use_my_buf (bar.my_buf);         // therefore we're forced to use this
}


Here's what the different compilers produce:

GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.

ccbug.cc: In function `int  main ()':
ccbug.cc:23: incompatible types in argument passing


Lucid SPARC C/C++ Compiler, Version 2.1.3Beta [24-Dec-91]
_________________________________________________
E, ccbug.cc(9,52) Cannot convert type "int*" to return type "int[9]&"
                                                           v
9       inline __typedef41 foo::get_my_buf( ){return(my_buf) ; }
          ccbug.cc ... 1 Error.


Sun CC++ SC1.0 C++ 2.1 1Mar1991

"ccbug.cc", line 21: warning:  bar used but not set
"ccbug.cc", line 23: warning: & before array or function: ignored

cfront actually compiles this, but only by luck.  It still generates
code which assumes that it can pass an array by reference just by
returning a pointer to it.

It looks like all these compilers blissfully assume that a reference can
just be considered a hidden pointer.  They are sadly mistaken!

--
Dave Brennan                                      HaL Computer Systems
brennan@hal.com                                         (512) 794-2855

Visit the Emacs Lisp Archive: archive.cis.ohio-state.edu:pub/gnu/emacs

Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC 2.2.2: miscellanous cleanups in cp-parse.y, cp-class.c
Organization: Department of Computer Science, Purdue University
Distribution: gnu
Date: Thu, 3 Sep 1992 16:27:50 GMT

Mismatches in the number of arguments:

cp-parse.y, line 1611:  Calling function build_x_arrow() with 2 arguments,
			expecting 1.
cp-parse.y, line 2398:  Calling function grokfield() with 6 arguments,
			expecting 5.
cp-class.c, line  422:  Calling function build_indirect_ref() with 1 argument,
			expecting 2.

Type mismatch in function call:

cp-parse.y, line  999:  Serious type mismatch during call to function
			build_x_unary_op().
			Passing argument #1 of type (union tree_node *),
			expecting type (enum tree_code).

--Gerald

Newsgroups: gnu.g++.bug
From: maverick@cork.cs.berkeley.edu (Vance Maverick)
Subject: g++-2.2.2 fatal signal -- followup
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 23:43:50 GMT

I wrote:
> Under SunOS 4.1.2 on a SPARCstation 2, g++-2.2.2 suffers a fatal
> signal processing the following file.

For what it's worth, there was a logical error in the program (an
incorrect argument to the << operator in the streams package), and when
this was corrected, the compilation succeeded.

	% diff RelDivisor.ii RelDivisor2.ii
	1053c1053
	<     cout << "RelDivisor::time(): start = " << start <<
	---
	>     cout << "RelDivisor::time(): stime = " << stime <<
	% g++-2.2.2 -g  -c RelDivisor2.ii -o RelDivisor2.o
	%

Hope this helps,
	Vance

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  gcc 2.2.2 generates undefined symbols when using variable args and -g
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 12:28:27 GMT

You might try gcc 2.2.1, as I think it does not have this problem.

> From: Schaefer - IP MGR <ip_mgr@asc.slb.com>
> Date: Fri, 7 Aug 92 21:10:02 CDT
> Message-Id: <9208080210.AA25815.ip_mgr@cesium.asc.slb.com>
> To: bug-gcc@prep.ai.mit.edu
> Cc: duttweiler@asc.slb.com, cwilliams@asc.slb.com

> Is the following a bug or do I need some compiler directive to use 
> "varargs" from c++ code ? 

> The version of stdarg.h is from the gcc distribution kit.

> The following code when compiled with gcc 2.2.2 (This is a .cc file) 
> generates undefined for branch labels


> 	#include <stdarg.h>

> 	extern "C" {

> 	void test(int stat, ...)
> 	{
> 	    va_list ap;
> 	    int key;

> 	    va_start(ap, stat); 
> 	    while (key = va_arg(ap, int)) {
> 	      printf("Key is %d \n", key);
> 	    }
> 	    va_end(ap);
> 	}
>      
> 	}


> cesium% !gcc
> gcc -v -g -c -DGCC -DSUN -DSUN4 -DUNIX -o foo.o foo.cc
> Reading specs from /usr/local/gcc-2.2/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
> gcc version 2.2.2
>  /usr/local/gcc-2.2/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cpp -lang-c++ -v -DGCC -DSUN -DSUN4 -DUNIX -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -g foo.cc /tmp/cca25800.i
> GNU CPP version 2.2.2 (sparc)
>  /usr/local/gcc-2.2/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /tmp/cca25800.i -fno-builtin -quiet -dumpbase foo.cc -g -version -o /tmp/cca25800.s
> GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
> foo.cc: In function `void  test (int, ...)':
> foo.cc:12: warning: implicit declaration of function `printf'
>  as -o foo.o /tmp/cca25800.s
> cesium% !nm
> nm foo.o
>          U LBB5
>          U LBE5
>          U ___builtin_saveregs
>          U _printf
> 0000000c T _test
> 00000000 t gcc2_compiled.

Newsgroups: gnu.g++.bug
From: warsaw@nlm.NIh.GOV (Barry A. Warsaw)
Subject: More info on cc1plus crash
Reply-To: warsaw@nlm.nih.gov (Barry A. Warsaw)
Organization: Century Computing, Inc.
Distribution: gnu
Date: Mon, 31 Aug 1992 20:59:20 GMT

I have more information on my previously reported cc1plus bug.  Seems
that typedefs nested inside a class cause the problem.  Compile the
following simplified example with -DNESTEDTYPEDEF to recreate the bug.
Compile w/o the switch to generate a working program.  Sun C++ 2.1
correctly compiles with or w/o the switch.

In the case of -DNESTEDTYPEDEF, the symbol DoIt should be scoped to
class Bar.  I.e. its name should be Bar::DoIt.

FTR, I'm using gcc 2.2.2, Sun SS2, SunOS 4.1.1.

-Barry

-------------------- snip snip --------------------
#include <iostream.h>

class Foo
{
public:
	Foo() 
	{};

	int do_1( void )
	{
		cout << "do_1" << endl;
		return( 1 );
	};

	int do_2( void )
	{
		cout << "do_2" << endl;
		return( 2 );
	};
};


#ifndef NESTEDTYPEDEF
typedef int (Foo::*DoIt)( void );
#endif


class Bar
{
public:
#ifdef NESTEDTYPEDEF
	typedef int (Foo::*DoIt)( void );
#endif

	Bar( Foo* fooptr, DoIt doitfunc )
		: xfooptr(fooptr), xdoit(doitfunc)
	{};

	int doit( void )
	{
		return( (xfooptr->*xdoit)() );
	};

private:
	Foo* xfooptr;
	DoIt xdoit;
};


int main( int, char** )
{
	Foo f1;
	Bar b1( &f1, &Foo::do_1 );
	return( b1.doit() );
};

Newsgroups: gnu.g++.bug
From: jplevyak@cs.uiuc.edu (John B. Plevyak)
Subject: Pointers to Template Functions
Keywords: templates function pointers
Organization: University of Illinois, Dept of Computer Science
Distribution: gnu
Date: Tue, 1 Sep 1992 23:26:02 GMT

The following code reports a failed assertion:

#include <iostream.h>

template<class K>
void error(K i) {
  cerr << i << "\n";
}

main() {
  void (*pf)(int);
  pf = &error;

  (*pf)(5);
}

REPORTS:

cp-class.c:3977: failed assertion `TREE_CODE (TREE_VALUE (rhs)) == FUNCTION_DECL'
/b/gnu/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6

According to our understanding of Stroustrup's 2nd Ed this would seem
to be legal code.
Is it?  If so is a fix expected in the next version (2.3)?

Thanx

--- 
Vijay Karamcheti    vijayk@red-herring.cs.uiuc.edu
John Plevyak        plevyak@uiuc.edu      (217) 333-5219
Concurrent Systems Architecture Group 
University of Illinois at Urbana-Champaign
1304 West Springfield
Urbana, IL	61801

Newsgroups: gnu.g++.bug
From: kambiz@indetech.COM (Kambiz Aghaiepour)
Subject: Bug with dependency generation g++2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 00:29:00 GMT

System: sun4 (IPC) running sunOS 4.1.x with GNU gcc/g++ version 2.2.2

Has anyone else experienced this problem?

------- Start of forwarded message -------
From: tilman (Tilman Sporkert)
To: kambiz (Kambiz Aghaiepour)
Subject: Dependency generation broken with new compiler?
Date: Tue, 4 Aug 92 13:13:41 PDT

It appears that dependency generation with the new compiler is broken. The
output of "g++ -MM" looks like:

   allowance_tables.cxx.o : allowance_tables.cxx ../../tilman/util/ItiString.hxx \
  ../../tilman/util/ItiObject.hxx ../../tilman/util/ItiObjMacros.hxx ../../tilman/main/r2drug_svc.hxx \


Please note that it says "allowance_tables.cxx.o", not "allowance_tables.o"!
------- End of forwarded message -------

Newsgroups: gnu.g++.bug
From: rtm@das.harvard.edu
Subject: default arguments vs templates
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 20:14:46 GMT

I'm running g++ 2.2.2 on a SPARCstation ELC with SunOS 4.1.2.  I want
to have a default argument to a method of a templated class.  I think
the following code should work, but it produces an error message.
Repeating the default in the definition (as well as the declaration)
fixes the error message, but section 8.2.6 in the Annotated Reference
Manual says such repetition is illegal.

template<class T> class b{
private:
    T x;
public:
    void Print(int x = 10);
};

template<class T> void
b<T>::Print(int x) // x = 10 fixes the error message.
{
}

main()
{
    b<int> zz;

    zz.Print(99);
}

Here's the output from g++ -v:

Reading specs from /home/glan/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /home/glan/lib/gcc-lib/sun4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG
__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__spa
rc -D__sun -D__unix zoid.cc /usr/tmp/cca02675.i
GNU CPP version 2.2.2 (sparc)
 /home/glan/lib/gcc-lib/sun4/2.2.2/cc1plus /usr/tmp/cca02675.i -quiet -dumpbase
zoid.cc -version -o /usr/tmp/cca02675.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
zoid.cc: In function `int  main ()':
zoid.cc:7: template for method `Print' doesn't match any in class `b<int>'

Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC 2.2.2: no error messages for uninitialized const's
Organization: Department of Computer Science, Purdue University
Distribution: gnu
Date: Thu, 3 Sep 1992 21:36:28 GMT

Given the class declaration

	class c { public: int foo (void); };

the declaration

	const c o;

produces the error message

	stdin:2: uninitialized const `o'

I would expect similar behavior for the declarations

	const int i;
	c * const p;

but both pass without an error message.

--Gerald

Newsgroups: gnu.g++.bug
From: gej@okcforum.osrhe.uoknor.edu (Eric Jergensen)
Subject: cc1plus gets fatal signal
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 3 Sep 1992 03:16:37 GMT

Here is some code that causes cc1plus to receive a fatal signal:
=====
class BOOL
	{
	int b;
public:
	BOOL() { b = 0; }
	BOOL operator!() const { BOOL rc; rc.b = !b; return rc; }
	};

void fcn()
	{
	BOOL test = !BOOL();
	}

BOOL test2 = !BOOL(); // this line causes the compiler to core dump
=====
I'm running an unmodified gcc version 2.2.2, configured for a sun4.
My OS is SunOS 4.1.2.
I used 'gcc -o testbool testbool.cxx' to compile.
gcc2.2.2 on a 3b2 exhibits similar symptoms.

Eric
gej@okcforum.uoknor.edu

Newsgroups: gnu.g++.bug
From: sullivan@mathcom.com (S. Sullivan)
Subject: Template Trouble
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 26 Aug 1992 23:05:51 GMT

I'm running gcc 2.2.2 on Sunos 4.1.1 on a sparc 2.

Compiling the following file with g++ gives:

> g++ -c -o testd.o testd.cc
testd.cc: In function `int  main ()':
testd.cc:9: template for method `print' doesn't match any in class `QI<int>'
Exit 1


Why?

Many thanks for your help ...

Steve Sullivan
sullivan@mathcom.com


------------------ cut here -------------------------
template <class T>
class QI {
public:
  QI();
  void print() const;
private:
  T item;
  QI *next;
  };



template <class T>
QI<T>::QI() {}


template <class T>
void QI<T>::print() const {};


main () {
   QI<int> alpha();
   }
------------------ cut here -------------------------



Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  templates????
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 15:10:24 GMT

Without a test case it cannot be fixed.  (In all likelyhood.)

With one, it may get fixed.

Why not send in a complete test case?

> Message-Id: <9207312139.AA20069@media-lab.mit.edu>
> To: bug-gcc@prep.ai.mit.edu
> Cc: cwren@media-lab.media.mit.edu
> Date: Fri, 31 Jul 92 17:39:14 -0400
> From: cwren@media-lab.media.mit.edu

> array.h:160: sorry, not implemented: non-function templates not yet supported

> trying to implement a clu-esque array as a excercise like so:

> array.h:
> template <class T> class array {
>   // rep
>  public:
>   // signals
>   // procs
> } //line 160;

> Am I hazing the compiler is some unique way - or are templates really
> unsupported?

> if they're unsupported, is there a release date for a version that does
> support them?

Newsgroups: gnu.g++.bug
From: pfc@curtech.UUCP (Peter Cass)
Subject: no subject (file transmission)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 20:55:50 GMT

class nut {
	public:
		enum NUTTYPES {walnut, peanut} _type;
		int is_walnut(){return _type == walnut; }
		NUTTYPES type() { return _type; }
		nut() { _type = peanut; }
};


main()
{
	nut *peanut;
	char *str;

	peanut = new nut;

	// Saber-C++ compiles without complaint ...
	// gcc fails with message: 
	// 	foo.C: In function `int  main ()':
	//	foo.C:22: assignment between incompatible pointer types
	str = (peanut->type()==nut::walnut ? "yes" :
		(peanut->is_walnut() ? "maybe" : "no"));

	// OK
	str = peanut->type()==nut::walnut ? "yes" : "no";

	// OK
	if (peanut->type()==nut::walnut)
		str = "yes";
	else if (peanut->is_walnut())
		str = "maybe";
	else
		str = "no";
			
}

// Compiled on Sun4 running SunOS 4.1.2
From: lewis@sophists.COM (Lewis G. Pringle)
Newsgroups: gnu.g++.bug
Subject: new with placement operator broken in gcc 2.2.1
Date: 3 Sep 92 20:38:00 GMT
Reply-To: lewis@sophists.com
Distribution: gnu
Organization: GNUs Not Usenet

// Compiling this file with gcc 2.2.1:
// as follows: g++ -c h.cc
// produces the messages:
//	h.cc: In function `int  f (class ArrayNode)':
//	h.cc:21: parse error before `)'
//
// This simple use of the placement operator new fails. I have found
// no case where it actually works...
typedef unsigned size_t;
static inline void *operator new(size_t, void *place) { return place; }   // from libg++/new.h
class ArrayNode {
	public:
		ArrayNode (int item): fItem (item){}
		~ArrayNode (){}
		int	fItem;
};

int f (ArrayNode n)
{
    ArrayNode* p = (ArrayNode*)new char [sizeof (ArrayNode)];
    new (p) ArrayNode (n);		// Line 21 - WHY DOES THIS FAIL???
}
Newsgroups: gnu.g++.bug
From: brendan@cygnus.com (Brendan Kehoe)
Subject: bug in g++ 2.2.2
Reply-To: brendan@cygnus.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 03:12:05 GMT

> The following program reports a syntax error.  The exmaple from which this
> was distilled used <sys/stat.h> which declares both a structure and a
> function named "stat".
> 	struct	s { int a; };
> 	extern int       s () ;
> 	int f() {
> 		::s();
> 		return 0;
> 	}

This is fixed in the next release of the compiler.

> By the way, is any body reading these bug reports?

I'm going through them now.

I apologize for the lack of response, things have been really, really
busy.  I've recently joined Cygnus, and having another person on the
G++ team will make it easier to have timely replies to bug-g++ and
other things.

Brendan Kehoe
Cygnus Suppport

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Static member doesn't link
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 14:27:28 GMT

You fail to provide a test case.

I suspect you have not read a recent book on C++.

You must have a definition for the static member someplace

int Class::Member = 5;

outside the { } of the class.

> From: ken@tifsim.pac.sc.ti.com (Ken Costilow)
> Message-Id: <1992Jul23.164014.13951@ticipa.pac.sc.ti.com>
> Reply-To: kenneth@lobby.ti.com (Ken Costilow)
> Organization: Texas Instruments Process Automation Center
> Date: Thu, 23 Jul 1992 16:40:14 GMT

> I can`t compile classes with static data members. I was hoping this
> was simply one of gcc's many switches, but if so I have been unable
> to find it. 

> I'm using: Vax3800/Ultrix4.2, gcc 2.1, gas 1.38, binutils 1.9
> I have tried the standard ld, gnu ld, as, gas, using l

Newsgroups: gnu.g++.bug
From: brendan@cygnus.com (Brendan Kehoe)
Subject: Bug in overloading delete (gcc 2.2.2 core dumps)
Reply-To: brendan@cygnus.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 07:21:46 GMT

> gcc core dumps trying to compile the following code:
> 
> ------begin included file bug1.cc--------
>     #include <sys/stdtypes.h>
> 
>     class mem
>     {
>     public:
> 	mem() {};
>     //     virtual ~mem() {};
> 
> 	void operator delete(void *v, size_t s) 	{};
>     };
> 
>     class derived : public mem {
>     public:
>        derived()	{} 
>     //    virtual ~derived()	{} 
> 
>        function(derived *d)	{ delete d; }
>     };
> 
>     main()
>     {
>     }
> ------end included file bug1.cc--------
>     gcc bug1.cc
>     bug1.cc: In method `int  derived::function (class derived*)':
>     bug1.cc:18: too few arguments for method `operator delete'
>     cp-method.c:2217: failed assertion `rval != error_mark_node'
>     gcc: Internal compiler error: program cc1plus got fatal signal 6

This is fixed in the next release (don't ask for a date).

> If you remove the comments in front of the destructor definitions in the
> code above, you get the following error messages when compiling:
> 
>     what> gcc bug1.cc
>     bug1.cc: In method `mem::~mem ()':
>     bug1.cc:7: too few arguments for method `operator delete'
>     bug1.cc: In method `derived::~derived ()':
>     bug1.cc:16: too few arguments for method `operator delete'
>     bug1.cc: In method `int  derived::function (class derived*)':
>     bug1.cc:18: warning: control reaches end of non-void function

This is fixed, also.

Brendan

--
Brendan Kehoe                                               brendan@cygnus.com
Cygnus Support, Palo Alto, CA                                  +1 415 322 3811

Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Using g++2.1 with standard C library on SunOS 4.1.1 Rev B.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 20:01:32 GMT

A perhaps better solution would be to change the definition of:

#define SIZE_TYPE "int"

In gcc/config/sparc.h to read:

#define SIZE_TYPE "unsigned int"

As it seems that sun has decided to bite the bullet and fix there
include files.

> Date: Mon, 31 Aug 92 10:23:16 EDT
> From: samborn@lynchpin.mtkgc.COM (Kevin Samborn)
> Message-Id: <9208311423.AA22348@lynchpin.mtkgc.com>
> To: mrs@cygnus.com (Mike Stump)
> Cc: bug-gcc@prep.ai.mit.edu
> References: <9208291332.AA28849@cygnus.com>

> > Whenever I include standard include files, (in this case coming from
> > /usr/lang/SC1.0/CC/include), I get the errors similar to the
> > following:

> > In file included from /usr/lang/SC1.0/include/CC/malloc.h:9,
> >                  from /usr/lang/SC1.0/include/CC/stdlib.h:21,
> >                  from Main.C:1:
> > /usr/lang/SC1.0/include/CC/alloca.h:10:
> >         declaration of `char * __builtin_alloca (int)'
> > <built-in>:0: conflicts with built-in
> > declaration `void * __builtin_alloca (int)'
> > In file included from /usr/openwin3/include/X11/Xos.h:69,
> >                  from /usr/openwin3/include/X11/Intrinsic.h:37,
> >                  from Main.C:2:
> > /usr/lang/SC1.0/include/CC/strings.h:22:
> >         declaration of `unsigned int  strlen (const char *)'
> > <built-in>:0: conflicts with built-in
> >         declaration `int  strlen (const char *)'

Newsgroups: gnu.g++.bug