HDTenEightyP/NetNews huggingface dataset:
From: dbc@cs.brown.edu (Brook Conner)
Subject: Re: long messages in minibuffers
Organization: Department of Computer Science, Brown University
	<9212190908.AA11399@wintermute.ncsa.uiuc.edu>
Distribution: gnu
Date: Sat, 19 Dec 1992 16:12:29 GMT

**> On Fri, 18 Dec 1992 17:08:37 GMT, marca@ncsa.uiuc.edu (Marc Andreessen) said:

  Marc> Frank Caico writes:
> Here is an example: I have about 6 or 7 directories in my load-path and I
> want to see what is in it.  I eval the load-path but the result in the
> minibuffer is to long to fully display!   

  Marc> Go to your *scratch* buffer (which should be in Lisp Interaction mode)
  Marc> and type:

  Marc> (insert (format "%s" load-path))

  Marc> Then hit M-C-x.


Even easier: describe-variable load-path
Usually, this is bound to C-h v 
So C-h v load-path RET will do it.

For example, here's mine (quite a few more than 6 or 7), copied from
the *Help* buffer describe-variable produces:

load-path's value is ("/cs/lib/epoch/local/lisp/tek-highlight" "/u/dbc/src/emacs/dired" "/pro/info/hypb/" "/cs/lib/emacs/local/lisp/latexinfo/" "/cs/lib/epoch/local/lisp" "/cs/lib/epoch/epoch-4.2/epoch-lisp" "/cs/lib/emacs/local/lisp" "/cs/lib/emacs/dist-18.58/lisp" "/cs/lib/emacs/local/rsw-lisp" "/cs/lib/emacs/local/lisp" "/cs/lib/emacs/local/lisp/vm" "/cs/lib/emacs/local/lisp/gnus" "/cs/lib/emacs/local/lisp/outline-minor" "/cs/lib/emacs/local/lisp/latexinfo" "/cs/lib/emacs/dist/lisp" "/u/dbc/src/emacs" "

/u/dbc/src/epoch" "/pro/uga/lbin/lisp" "/cs/lib/emacs/local/lisp/vortex" "/cs/lib/emacs/local/lisp/superman" "/cs/lib/emacs/local/lisp/supercite")

Documentation:
*List of directories to search for files to load.
Each element is a string (directory name) or nil (try default directory).
Initialized based on EMACSLOADPATH environment variable, if any,
otherwise to default specified in by file paths.h when emacs was
built.

Brook



--
Brook Conner		| Klacktoveedsedstene
Brown Computer Graphics	| Fortune sez: Brook's Law -- Adding manpower to a late
dbc@cs.brown.edu     	|  	software project makes it later
uunet!brunix!dbc dbc@browncs.bitnet   Box 1910 Brown U Prov RI 02912
Newsgroups: gnu.epoch.misc
From: garath@synecdoche.engin.umich.edu (Scott Grosch)
Subject: Re: Detecting Epoch vs Emacs at startup
Date: Sun, 13 Dec 92 15:09:32 EST
Organization: University of Michigan (CAEN)
Reply-To: garath@engin.umich.edu
Keywords: epoch, emacs
Originator: garath@synecdoche.engin.umich.edu


In article <1992Dec11.195452.14891@roadnet.com>, rgb@roadnet.ups.com (Rudy Bonefas) writes:
> Someone recently posted a message on how to identify whether you are running Epoch or
> Emacs within your .emacs file.  At the time, I didn't think I needed to know how to do this.  Now I do.  Could whoever posted that entry either re-post it or mail it directly to me?   Thanks.
> 
> "Orthodoxy is unconsciousness." - Winston Smith.
> 

Put the following in your .emacs file.  Then you can always do something like:

(if running-epoch (whatever))


(defvar running-epoch (boundp 'epoch::version))

-- 
Scott Grosch                              Internet: garath@engin.umich.edu
Programmer                                         Bitnet: user7a4b@umichu
Computer Aided Engineering Network                  University of Michigan
Newsgroups: gnu.epoch.misc
From: rgb@roadnet.ups.com (Rudy Bonefas)
Subject: Detecting Epoch vs Emacs at startup
Reply-To: rgb@roadnet.ups.com
Organization: Roadnet Technologies, Inc.
Date: Fri, 11 Dec 1992 19:54:52 GMT
Keywords: epoch, emacs

Someone recently posted a message on how to identify whether you are running Epoch or
Emacs within your .emacs file.  At the time, I didn't think I needed to know how to do this.  Now I do.  Could whoever posted that entry either re-post it or mail it directly to me?   Thanks.

"Orthodoxy is unconsciousness." - Winston Smith.

Newsgroups: gnu.epoch.misc,news.answers
From: rjkroege@mud.uwaterloo.ca (Robert Kroeger)
Subject: Epoch4.2 Xauthority problem
Organization: Computer Graphics Laboratory, University of Waterloo, Ontario, Canada
Date: Sat, 19 Dec 1992 19:37:48 GMT


I've just finished building Epoch4.2 on ULTRIX 4.2.  I have a question
and a possibly helpful point.

Point: The value for LINKER in m-mips.h, the recomended m-* file for
ULTRIX 4.2 is wrong.  It should be /usr/bin/ld.

Question 1: Now when I run Epoch on a different machine from the X
display, it requires the machine to be xhost-ed.  Previously, Epoch4.0
operated without this requirement.  To my knowledge, Xauthority is
operating correctly - as it works fine for Epch4.0 and other X
programs.  Why is this and how can I fix it?

Rob Kroeger
CGL
University of Waterloo



Newsgroups: gnu.bash.bug
From: zoo@cygnus.com (david d `zoo' zuhn)
Subject: suspended commands seem to finish
Organization: Cygnus Support -- +1 415 903 1434
Distribution: gnu
Date: Sat, 19 Dec 1992 23:23:14 GMT

bash 1.12.2, sun4 and sco and probably others

try the following command

% sleep 100 && echo moo

type ctrl-z before the sleep finished, and you'll see that the "echo moo"
command is executed, even though the sleep command hasn't completed
execution.  csh does the right thing, imo, in not running the echo until
the sleep command has finished.

  david d 'zoo' zuhn |    There is great disorder under the heavens,
    cygnus support   |         and the situation is excellent.
    zoo@cygnus.com   |    



Newsgroups: gnu.bash.bug
From: jtarr@husc8.harvard.edu (Jeff Tarr)
Subject: Won't read .bashrc
Summary: At login it won't read the .bashrc
Keywords: bash
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Dec 1992 20:20:30 GMT

bash doesn't seem to read my .bashrc file when I login.  It does read
my .bash_profile and .profile files, but not my .bashrc.  As a result my
PATH is not set correctly which just wreaks havok later.  I'm switching to
bash from csh.  I'm only a bash beginner so I suspect that this is my fault,
not a bug, but I have followed the man file exactly to no avail.

Thanks.

-- 
Jeff Tarr
Harvard University
jtarr@husc.harvard.edu
-- 
Jeff Tarr
Harvard University
jtarr@husc.harvard.edu

Newsgroups: gnu.bash.bug
From: TRANLE@intellicorp.com (Minh Tran-Le)
Subject: bash-1.12 and sunos4.1.3: problem with the pwd command ...
Reply-To: tranle@intellicorp.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 17 Dec 1992 00:42:10 GMT

Hi,
one of our sparc10 is running sunos4.1.3 and when I execute the following
set of commands the builtin `pwd' command hang:

    emacs &	# run emacs-18.59 Xwindows in the background
    pwd		# <-- the pwd command hang until emacs dies.

All the other command seems to work fine (e.g echo, ls, /bin/pwd ...)
And under sunos4.1.1 or sunos4.1.2 everything works fine.

Has anybody noticed the same problem ? is it sunos4.1.3 bug ?

Thanks,
Minh Tran-Le.
-------

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: Won't read .bashrc
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 04:41:58 GMT

> bash doesn't seem to read my .bashrc file when I login.  It does read
> my .bash_profile and .profile files, but not my .bashrc.  As a result my
> PATH is not set correctly which just wreaks havok later.  I'm switching to
> bash from csh.  I'm only a bash beginner so I suspect that this is my fault,
> not a bug, but I have followed the man file exactly to no avail.

This is what is supposed to happen.  From the man page:

Login shells:
  On login:
        if /etc/profile exists, source it.

        if ~/.bash_profile exists, source it,
          else if ~/.bash_login exists, source it,
            else if ~/.profile exists, source it.

If you want .bashrc run on login, add the following lines to the end of your
.bash_profile:

	if [ -f ~/.bashrc ]; then
		. ~/.bashrc
	fi

Chet


--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: Missing functionality from BASH ?
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Dec 1992 05:32:08 GMT

> a) CDSPELL. In ksh (or at least on SCO's ksh), if you mis-type a directory
>    name, cd finds the closes matching directory, and prompts you for a
>    y/n entry. Each time you say no to a directory, it carries on seaching
>    down CDPATH for another possible match. Only one the end of all possible
>    directories have been refused as options, does cd report that the directory
>    does not exist.

This is not a feature of `standard' ksh.  SCO must have added it.  It's
not in Posix.2.

> b) cd name substitution. If your current directory is, say /usr/spool/uucp
>    and you type in 'cd spool lib', ksh changes you to /usr/lib/uucp. ksh
>    substitutes the second parameter for that portion of PWD that matches
>    the first parameter. Very usefull feature that.

This is not in Posix.2 either, but is easily added with a function.  Bash
allows a function to replace a builtin, and provides the `builtin' keyword
to make the functionality of the builtin available to the function.  Here,
for instance, is a shell function that provides all of the functionality
of the ksh `cd', including the name substitution.

cd()
{
	case $# in
	0)	builtin cd "$HOME" ;;
	1) 	builtin cd "$@" ;;
	2)	old="$1"
		new="$2"
		dir=$(echo "$PWD" | sed "s:$old:$new:g")
		case "$dir" in
		"$PWD")	echo "bash: cd: bad substitution" >&2 ; return 1 ;;
		*)	echo "$dir"
			builtin cd "$dir"
			;;
		esac
		;;
	*)	echo "cd: wrong arg count" >&2 ; return 1 ;;
	esac
}

--
``The use of history as therapy means the corruption of history as history.''
	-- Arthur Schlesinger

Chet Ramey, Case Western Reserve University	Internet: chet@po.CWRU.Edu

Newsgroups: gnu.bash.bug
From: roland@gnu.ai.mit.edu (Roland McGrath)
Subject: bash doesn't notice SIGWINCH
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 17 Dec 1992 12:45:17 GMT

bash 1.12.1 on m68k-hp-bsd4.3

Start an xterm.  In that window, type enough at bash that it doesn't fit on
the line and you get the ">" at the end of the line.  Then enlarge the
window with your window manager.  bash still thinks the line is the
original length.

Newsgroups: gnu.bash.bug
From: maw@netcom.com (Martin Walker)
Subject: Missing functionality from BASH ?
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Sat, 12 Dec 1992 19:09:58 GMT

I know BASH is supposed to be POSIX compliant and all that, but not having
the POSIX standards documents, I don't know whether the following minor
features of the Korn shell are missing from BASH, or missing from POSIX:

a) CDSPELL. In ksh (or at least on SCO's ksh), if you mis-type a directory
   name, cd finds the closes matching directory, and prompts you for a
   y/n entry. Each time you say no to a directory, it carries on seaching
   down CDPATH for another possible match. Only one the end of all possible
   directories have been refused as options, does cd report that the directory
   does not exist.

b) cd name substitution. If your current directory is, say /usr/spool/uucp
   and you type in 'cd spool lib', ksh changes you to /usr/lib/uucp. ksh
   substitutes the second parameter for that portion of PWD that matches
   the first parameter. Very usefull feature that.

I hope to see these features in the next release of BASH. Congratulations
to GNU on a damn fine shell otherwise.

Kean Johnston.
-- 
Martin Walker               |  "One way to stop a runaway horse
++27-12-344-3973 (w)        |   is to bet on him"
++27-12-998-7263 (h)        |   maw@netcom.com
Pretoria, South Africa      |   martin@paradigm.CO.ZA

Newsgroups: gnu.g++.bug
From: klamer@mi.eltn.utwente.NL (Klamer Schutte)
Subject: 2.3.2: Internal compiler error
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 17 Dec 1992 13:28:24 GMT

On the following file:

template<class T>
class C
{
public:
	~C() {}
};

test()
{
	class B : public C<int>
	{ };
}

g++ 2.3.2 crashes, with the diagnostics:

1 klamer@mi7 12:28 35> g++ -v -c qqq.cc
Reading specs from /usr/local/lib/gcc-lib/sun4/2.3.2/specs
gcc version 2.3.2
 /usr/local/lib/gcc-lib/sun4/2.3.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix qqq.cc /tmp/cca02264.i
GNU CPP version 2.3.2 (sparc)
 /usr/local/lib/gcc-lib/sun4/2.3.2/cc1plus /tmp/cca02264.i -quiet -dumpbase qqq.cc -version -o /tmp/cca02264.s
GNU C++ version 2.3.2 (sparc) compiled by GNU C version 2.3.2.
qqq.cc: In function `int  test ()':
qqq.cc:11: Internal compiler error.
qqq.cc:11: Please report this to `bug-g++@prep.ai.mit.edu'.

Klamer

Klamer Schutte			Tel: +31-53-892778	Fax: +31-53-340045
Faculty of electrical engineering -- University of Twente, The Netherlands
preferred: klamer@mi.el.utwente.nl     SMTP: klamer@utelmi01.el.utwente.nl

Newsgroups: gnu.g++.bug
From: c70623@mwa.uibk.ac.at (Werner Benger)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Dec 1992 17:16:56 GMT

 There is a new error in the GNU C++ 2.3.2 Compiler, which had not
been in version 2.2.2 .  When compiling the following program, the
Compiler complains "bad argument 0 for function B::B".

/*************************  ERROR 1 *****************************************/
#include <stdio.h>

struct	A
{	int sum;

	A(int i,int j,int k)
	{
		sum=i+j+k;
	}
};

struct	B
{	int Sum;

	B(const A&a,const A&b)
	{
		Sum = a.sum + b.sum;
	}
};

B testB(A(1,2,3),A(4,5,6));

main()
{
	printf("21==? %u\n",testB.Sum);
	return 0;
}

/************************************************************************/
There is also an old error, which had already occured in version 2.2.2 .

/**************************** ERROR 2 ***********************************/
struct X
{
 	struct Y
 	{
 		Y()	{}		
 	};
 	
 	X::Y operator()(int x,int y);
 	{
 	X::Y Z; 
 		return Z; 
 	}
};
 
main()
{
X	a;
X::Y	b=a(0,0);
 
}

/***************************************************************************/
 
	Best greetings from  werner@ast1.uibk.ac.at 
 




Newsgroups: gnu.g++.bug
From: andahlst@utu.fi (Antero Dahlstr|m)
Subject: clear()
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Dec 1992 12:33:21 GMT

Your message,

Organization: Project GNU, Free Software Foundation,
           675 Mass. Ave., Cambridge, MA  02139, USA   +1 (617) 876-3296
Subject: b[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C
Status: R

Please resubmit this message with a clear Subject: line
and some real text to bug-g++@prep.ai.mit.edu !!

thanx -len

and the first one of mine;

   Kutsuin clear() funktiota ja k{{nt{j{ pyysi l{hett{m{{n t{m{n ilmoituksen.
   andahlst@utu.fi.
_____________________

I was calling standard clear function

   Screen bufScreen(1,22,'*');
   bufScreen.clear(' ');

I think there is no one. it didn't function. Now I have defined 
   
   Screen& Screen::clear(char bkground) {
                   //reset the cursor and clear the screen
                   char* p=cursor=screen;
                   while (*p) *p++ =bkground;
                   return *this;  //return invokin objekt
                                     }

and it is functioning ok. andahlst@utu.fi


Newsgroups: gnu.g++.bug
From: jbg@qualcomm.com (Jeff Gehlhaar)
Subject: G++ Bug Report 13
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 02:48:01 GMT

// A parameter in a library class member shadows another member
// Compiling this with ``g++ -v -c -Wshadow bug013.cc'' gets:
// Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/specs
// gcc version 2.3.2
// /usr/local/lib/g++-include/streambuf.h: In method `ios::ios (struct
streambuf* (=  0 ), class ostream* (=  0 ))':
// In file included from bug013.cc:9:
// /usr/local/lib/g++-include/streambuf.h:477: warning: declaration of
`tie' shadows a member of `this'

#include <streambuf.h>



Newsgroups: gnu.g++.bug
From: lanceo@cs.utexas.edu (L. Lance Obermeyer)
Subject: possible bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 08:36:33 GMT

This code snippet compiles with an error that might be a bug.
It works fine on sun CC v2.0

// bar.h

class bar
{	// ...
	void	myfunc(void (bar::*funcptr) (void*));
	// ...
};

I am using gcc v 2.3.2 on a sparc.

Newsgroups: gnu.g++.bug
From: tlukka@vinkku.hut.fi
Subject: The last message about 123
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 23:06:09 GMT

Oh, the version is 2.3.1.u2

	TJL

Newsgroups: gnu.g++.bug
From: dai@chmsr.isye.gatech.edu (Jim Dai)
Subject: template forward declarations
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 19:47:44 GMT

I know you are still working on template support for g++.
This may not be a bug. But I am reporting it anyway.

I am basically copy down an template class example from
Lippman's book (2nd ed.). 
The forward declaration has to use exact arguments. If I
omit "os" and "ar" in the following, the compiler complains.

template <class Type> ostream&
  operator<<(ostream& os, array<Type>& ar);

I am using 
/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/specs
gcc version 2.3.2

Codes are included below. Thanks for your excellent work.

Jim Dai

::::::::::::::
a_tst.cc
::::::::::::::
#include "array.h"
/* Template definitions can not split into more than one files.
 * I have to use include here.
 */

#include "array.cc" 

int main()
{
  int a[] = { 2, 3, 4, 5};
  array<int> b(a, 4);
  cout << b;
  return 0;
}

::::::::::::::
array.h
::::::::::::::
#ifndef _array_h
#define _array_h
#include <iostream.h>

template <class Type> class array;

template <class Type> ostream&
  operator<<(ostream& os, array<Type>& ar);

template <class Type> 
class array {
 public: 
  array(int sz) { init(0, sz); }
  array(const Type *ar, int sz) { init(ar, sz); }
  array(const array & iA) { init(iA.ia, iA.pSize);}
  virtual ~array() { delete [] ia; }
  
  array& operator = (const array&);
  void print(ostream&);
  int size() { return pSize; } 
  
  virtual Type& operator[](int ix) { return ia[ix]; }
  
 protected:
  void swap (int, int);
  void init(const Type*, int);
  
  int pSize;
  Type *ia;

};

  
#endif
::::::::::::::
array.cc
::::::::::::::
// #ifndef _array_cc 
// #define _array_cc

#include "array.h"
#include <assert.h>
#include <iostream.h>

template <class Type>
void  array<Type>::init(const Type *ar, int sz)
{
  ia = new Type[pSize=sz];
  assert (ia!= 0);
  
  for (int ix=0; ix<pSize;  ix++)
    ia[ix] = (ar!=0) ? ar[ix] : 0;
}

template <class Type>
array<Type>&  array<Type>::operator=(const array<Type> & iA)
{
  if (this == &iA) return *this;
  
  delete ia;
  init(iA.ia, iA.pSize);
  return *this;
}

template <class Type>
void array<Type>::print(ostream& os)
{

  const lineLength = 12;
  
  os << "( " << pSize << " )< ";
  for (int ix=0; ix <pSize; ix++) {
    if (ix % lineLength == 0 && ix) os << "\n\t";
    os << ia[ix];

    if (ix % lineLength != lineLength -1 &&
	ix != pSize -1) os << ", ";
  }
  os << " >\n";
}

template <class Type> ostream &
operator << ( ostream& os, array<Type>& ar)
{
  ar.print(os);
  return os;
}



// #endif

Newsgroups: gnu.g++.bug
From: jbg@qualcomm.com (Jeff Gehlhaar)
Subject: Template bug...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 09:25:52 GMT

The following code illustrates another template bug. 

It appears that the following:
          vector< vector<int> > u = vector< vector<int> >(vector<int>(1));

Does not create an instantiation of vector<int>. Thus causing the problem later.

::::::::::::::
does not compile (would compile if x[i] were explicitly cast to type T in
the operator << routine)
::::::::::::::
::::::::::::::
test.c
::::::::::::::
#include <stream.h>

/***************************************************************************
***
 * vector template definition
 ***************************************************************************
***/
template<class T> class vector {
private:
  T v[2];
public:
     vector(void)              {}
     vector(const T& y);

  T& operator [] (int i) const { return v[i]; }
};
template<class T> ostream& operator << (ostream& s, const vector<T>& x);


/***************************************************************************
***
 * vector template routines
 ***************************************************************************
***/
template <class T> vector<T>::vector(const T& y)
{
  for (int i = 0; i < 2; i++) v[i] = y;
}
template <class T> ostream& operator << (ostream& s, const vector<T>& x)
{
  for (int i = 0; i < 2; i++) s << x[i] << " ";
  return s;
}


/***************************************************************************
***
 * main routine
 ***************************************************************************
***/
int main(void)
{
//  vector<int>           x = vector<int>(1);
  vector< vector<int> > u = vector< vector<int> >(vector<int>(1));

//  cout << "x:    " << x    << "\n";
  cout << "u:    " << u    << "\n";
}
::::::::::::::
compilation output (g++ -v test.c -o test)
::::::::::::::
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/specs
gcc version 2.3.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/cpp -lang-c++ -v -undef
-D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__
-D__sun__ -D__unix__ -D__sparc -D__sun -D__unix test.c /usr/tmp/cca10091.i
GNU CPP version 2.3.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/cc1plus
/usr/tmp/cca10091.i -quiet -dumpbase test.cc -version -o
/usr/tmp/cca10091.s
GNU C++ version 2.3.2 (sparc) compiled by CC.
test.c: In function `class ostream& operator << (class ostream&, const
class vector<vector<int>>&)':
test.c:27: no constructor named `vector' in visible scope
test.c:27: no constructor named `vector' in visible scope
test.c:27: no constructor named `vector' in visible scope
test.c:27: no constructor named `vector' in visible scope


======================================================
Jeff Gehlhaar           Qualcomm Inc,  
jbg@qualcomm.com        San Diego, CA, USA
(619) 597-5241          "The Elegant Solution...."
======================================================


Newsgroups: gnu.g++.bug
From: darrenp@bruce.cs.monash.edu.au (Daz)
Subject: Annoying name conflict in g++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 17 Dec 1992 03:34:07 GMT

I don't even know who to 'blame' for this little debarcle - but applications
which include both curses.h and iostream.h (no not my code) have a conflict
between the SunOS clear macro in /usr/include/curses.h and a clear inline
in the streams library. Yep big deal - not really a major thing - but a little
annoying.

Thought you might be interested,

Sys details:

Reading specs from /u/dibbler0/gnu//lib/gcc-lib/sparc/2.3.2/specs
gcc version 2.3.2

SunOS 4.1.1 - sparc2

-- 
Darren Platt, Department of Computer Science
darrenp@dibbler.cs.monash.edu.au
Monash University, Clayton Melbourne, Victoria, Australia

Newsgroups: gnu.g++.bug
From: pes@regent.e-technik.tu-muenchen.dbp.DE (Peter Schauer)
Subject: Re: reported compiler error with g++ 2.3.2
Organization: Technical University of Munich, Germany
Distribution: gnu
Date: Sun, 13 Dec 1992 16:57:48 GMT

jeremym@syma.sussex.ac.uk (Jeremy Maris) writes:

>I tried to build groff (1.06) with gcc 2.3.2 and libg++ 2.3. Whilst compiling
>pic I got the following: (Ultrix 4.2)
>All was fine 'till then.

>object.cc: In method `circle_object::circle_object (double)':
>object.cc:1030: Internal compiler error.
>object.cc:1030: Please report this to `bug-g++@prep.ai.mit.edu'.

This is caused by the -g -O combination. The bug disappears if you use
-g
-O
-ggdb -O
I'd prefer the latter anyway as it allows decent debugging.
Just do a
make DEBUG=-ggdb
in the top level directory.
--
Peter Schauer			pes@regent.e-technik.tu-muenchen.de

Newsgroups: gnu.g++.bug
From: gb@cs.purdue.edu (Gerald Baumgartner)
Subject: GCC 2.3.2: unused macro definition in cp-tree.h
Organization: Department of Computer Sciences, Purdue University
Distribution: gnu
Date: Tue, 15 Dec 1992 14:21:20 GMT

The macro

	#define CLASSTYPE_NAMES(NODE) (TYPE_LANG_SPECIFIC(NODE)->names)

in cp-tree.h can safely be deleted.  There is no field called `names'
in (struct lang_type).

--Gerald

Newsgroups: gnu.g++.bug