HDTenEightyP/NetNews huggingface dataset:
From: bfox@gnu.ai.mit.edu (Brian Fox)
Newsgroups: gnu.bash.bug
Subject: always execute .bashrc
Date: 25 Jan 1993 20:29:30 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: bfox@ai.mit.edu

   From: chip@tct.com (Chip Salzenberg)
   Date: Sat, 23 Jan 1993 21:32:33 -0500 (EST)
   X-Mailer: ELM [version 2.4 PL20]
   Content-Type: text
   Content-Length: 1142      

   Quoting Brian Fox:
   > You are right, I do not see how that is a bug.  Vis a vis rsh and
   > desireable interactive behaviour, you cannot have your cake and eat it
   > too.

   Of course!  It _is_ impossible for bash to decide whether it is run
   from rsh or not.

   Therefore, I would suggest that rsh be configured or hacked to run
   something other than $SHELL -- $SHELL.rc perhaps.

Suggestions about rsh are always welcome, but do nothing to solve the
particular problem of imitating a badly specified language (sh) on a
fairly poor OS concept (unix).  My suggestion is to use "supdup"
protocol, and never to use rsh.  However, people will continue to use
rsh, so my suggestion is not generally useful.


   > Your example is the one instance where "-c" is specified, the input
   > stream is not a tty, and, for some unspecified reason, you do not wish
   > to run .bashrc.

   If consistency means nothing to you, then of course this inconsistency
   in your creation won't bother you.  I'm just glad I have source code.

If it were up to me, I would not have implemented something as ugly as
"sh" syntax, which is fraught with inconsistencies.  Bash is not my
"creation", it is a necessary evil, and I hope, the least of many.

However, I would like to point out that interactive commands can
always use the `-norc' flag, in the same fashion that csh users use
`-f'.

Brian
From: karl@owl.HQ.ILeaf.COM
Newsgroups: gnu.bash.bug
Subject: type and directory
Date: 26 Jan 1993 22:05:04 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: karl@hq.ileaf.com

I suspect this has already been reported, but in bash 1.12, the type
command pays attention to directories as well as commands (contrary to
the spec).  `type .' is particularly amusing.

This happens on all architectures I works on (sun 4/sunos 4.1.3, 486/isc
2.2.1, etc, etc.)
From: chip@tct.COM (Chip Salzenberg)
Newsgroups: gnu.bash.bug
Subject: Re: always execute .bashrc
Date: 25 Jan 1993 20:23:33 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Quoting Brian Fox:
> You are right, I do not see how that is a bug.  Vis a vis rsh and
> desireable interactive behaviour, you cannot have your cake and eat it
> too.

Of course!  It _is_ impossible for bash to decide whether it is run
from rsh or not.

Therefore, I would suggest that rsh be configured or hacked to run
something other than $SHELL -- $SHELL.rc perhaps.  So /bin/bash.rc
would use a new "please run the .bashrc file" option:

   #!/bin/sh
   SHELL=/bin/bash; export SHELL
   exec /bin/bash -rc ${1+"$@"}

Failing the ability to hack rsh, I'd arrange for the above script to
be the login `shell' of all bash users.  Therefore, login shells and
rsh shells would always get .bashrc and no others would.

> > bsh -norc -c 'wc' < random.file
> 
> Your example is the one instance where "-c" is specified, the input
> stream is not a tty, and, for some unspecified reason, you do not wish
> to run .bashrc.

If consistency means nothing to you, then of course this inconsistency
in your creation won't bother you.  I'm just glad I have source code.
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
From: chip@tct.COM (Chip Salzenberg)
Newsgroups: gnu.bash.bug
Subject: Re: always execute .bashrc
Date: 22 Jan 1993 21:26:52 -0500
Organization: TC Telemanagement, Clearwater, FL
Distribution: gnu

In an earlier message to bug-bash, I wrote:
> Chet understates the problem.  Bash runs .bashrc when you do this:
>      bash -c 'wc' < random.file
> Everyone (except Chet and Brian, it seems) can see that's a bug.

My statement implies that Chet approves of the bug.  However, he does
NOT approve.  Rather, he has agreed with me on several occasions that
the behavior in question should be changed.

It had been so long since our previous discussion that I'd forgotten.

"Sorry about that, Chief."
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
  "you make me want to break the laws of time and space / you make me
   want to eat pork / you make me want to staple bagels to my face /
   and remove them with a pitchfork" -- Weird Al Yankovic, "You Make Me"
From: chip@tct.COM (Chip Salzenberg)
Newsgroups: gnu.bash.bug
Subject: Re: always execute .bashrc
Date: 25 Jan 1993 21:03:33 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Quoting Brian Fox:
> However, I would like to point out that interactive commands can always
> use the `-norc' flag, in the same fashion that csh users use `-f'.

While you're at it, why not add a "--no-recurse" option to rm?
-- 
Chip Salzenberg at Teltronics/TCT  <chip@tct.com>, <73717.366@compuserve.com>
From: huober_r@hal.rz.uni-ulm.de (Reiner Huober)
Newsgroups: gnu.bash.bug
Subject: Systemwide aliases (.bashrc, ENV)
Date: 26 Jan 1993 21:55:18 -0500
Organization: Universitaet Ulm
Distribution: gnu

Hi there,

I don't know if "bug" is the right word, but I think that
the "bash-wizards" are most likely to be in this group and
i found now group like "gnu.bash.discuss".

on our Systems, we'd like to have systemwide aliases (like
"alias passwd=yppasswd"), because there is a need for some of
our aliases (like "soft='source /usr/local/scripts/soft'") to 
be not just command, but an alias or function.

We could define them in /etc/profile for a login shell, but
unfortunately most of our Sun-Openwin Shells are interactive,
but not login shells (our profile is quite long, so starting
bash -login on all new xterms would be time consuming).

We could set "ENV" to something like /etc/bashrc, but this
is only obeyed by noninteractive shells. 

We could recommend our users to have the aliases in their
.bashrc, but accidently some of our users (>300) delete
their files and then they say "why can't I set the passwd" or
"whereis that soft command gone".

Currently we use functions, which we declare in "/etc/profile",
and export them. But this breaks our "env"-command. I wonder if
this bash-thing has nothing like a systemwide "bashrc" for 
interaction, nologin shells.

Thanks in advance

Reiner Huober
---------------
email: reiner.huober@rz.uni-ulm.de
From: chet@odin.ins.cwru.edu (Chet Ramey)
Newsgroups: gnu.bash.bug
Subject: Re: How to build with -O?
Date: 22 Jan 1993 21:26:56 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: chet@po.cwru.edu

> What's the easiest way to build bash-1.12 with -O instead of -g?

Change the occurrence of -g to -O in the assignment to DEBUG_FLAG
in cpp-Makefile and type `make clean; make'

--
``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
From: fjh@munta.cs.mu.oz.au (Fergus James HENDERSON)
Newsgroups: gnu.bash.bug
Subject: Linux bash sometimes dies after ^C
Date: 26 Jan 1993 22:01:40 -0500
Organization: Computer Science, University of Melbourne, Australia
Distribution: gnu

The Linux version of Bash consistently dies when I type the interrupt
key ^C after entering the command
	<fjh:~> * * * * * *
in a directory with about 1000 files. (With smaller directories I don't
have time to press ^C before the next prompt returns.)

If run in a top-level shell it just returns to the "login:" prompt.
If run from a secondary-level shell it gives the message "IOT Trap/Abort
and then returns to the invoking shell.

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!
From: Mark.Bush@prg.ox.ac.UK (Mark Bush)
Newsgroups: gnu.bash.bug
Subject: Re: always execute .bashrc
Date: 25 Jan 1993 20:57:57 -0500
Organization: Oxford University Computing Laboratory
Distribution: gnu

In article <m0nFPhi-0000XBC@animal.tct.com> chip@tct.COM (Chip Salzenberg) writes:
#In an earlier message to bug-bash, I wrote:
#> Chet understates the problem.  Bash runs .bashrc when you do this:
#>      bash -c 'wc' < random.file
#> Everyone (except Chet and Brian, it seems) can see that's a bug.
#
#My statement implies that Chet approves of the bug.  However, he does
#NOT approve.  Rather, he has agreed with me on several occasions that
#the behavior in question should be changed.

Not everyone thinks this is a bug!  What is wrong with the shell trying to
source .bashrc on *every* invocation (with login shell being the only
exception)?  If you specifically don't want it to read the startup file, add
a -norc flag.  If you have stuff in .bashrc which you specifically don't
want read, protect it with an `if' checking the value of PS1.

If bash works in this way, then *everyone* can get the behaviour they want
with minimum fuss.  Otherwise, how does someone who wants to make use of
their aliases and such within the environments that bash normally doesn't
source the .bashrc?

Mark
From: neal@ctd.COMsat.COM (Neal Becker)
Newsgroups: gnu.bash.bug
Subject: How to build with -O?
Date: 21 Jan 1993 18:20:34 -0500
Organization: COMSAT Labs
Distribution: gnu

What's the easiest way to build bash-1.12 with -O instead of -g?
From: friedman@gnu.ai.mit.edu (Noah Friedman)
Newsgroups: gnu.bash.bug
Subject: Re: always execute .bashrc
Date: 26 Jan 1993 21:41:09 -0500
Organization: Free Software Foundation, 675 Mass Ave. Cambridge, MA 02139
Distribution: gnu

In article <1993Jan25.115536.5935@thom5.ecs.ox.ac.uk> Mark.Bush@prg.ox.ac.UK (Mark Bush) writes:
>What is wrong with the shell trying to source .bashrc on *every*
>invocation (with login shell being the only exception)?  If you
>specifically don't want it to read the startup file, add a -norc flag.
>If you have stuff in .bashrc which you specifically don't want read,
>protect it with an `if' checking the value of PS1.

This would be incompatible with standard bourne shell behavior.  What
happens if you execute a bash shell script?

Even if bash were to adopt the behavior you specified, a single-letter
option equivalent to `--norc' is necessary, since you can't group `--norc'
with other options and the BSD #! kernel hack only allows one argument to
the interpreter other than the path of the script file (which it adds
implicitly).
From: chet@odin.ins.cwru.edu (Chet Ramey)
Newsgroups: gnu.bash.bug
Subject: Re: bash for beginners
Date: 21 Jan 1993 18:05:52 -0500
Organization: GNUs Not Usenet
Distribution: gnu
Reply-To: chet@po.cwru.edu

> I have compiled bash 1.12 on a sparcstation running
> sunos 4.1.2 .
> 
> My problem is that the arrow keys don't work in a
> sun command tool ( $TERM=sun-cmd ).

There are two problems.  First, the termcap definition lies about
the capabilites supported by cmdtool.  Second, cmdtool doesn't let
input get through to the application unscathed -- since it wants
to let the user do mouse-based line editing and the like, it intercepts
input.  I suspect a combination of those things is causing your
difficulty.

--
``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
From: dtm@corp.SUn.COM (Duane T. Mun)
Newsgroups: gnu.bash.bug
Subject: Why can't bash do this...
Date: 25 Jan 1993 20:14:14 -0500
Organization: Sun Microsystems, Inc.
Distribution: gnu

I'm having a problem...why does bash choke on this:

	cmdname=`_=\`/bin/basename $0\`; /bin/expr $_ : '\(.*\),v' \| $_`

Here's some debug info from bash:

	+++ /bin/basename ./tst
	++ _=tst
	++ /bin/expr : \(.*\),v |
	expr: syntax error

$_ isn't being assign anything from /bin/basename.

This works fine with /bin/sh:

	+ cmdname=
	+ /bin/basename ./tst 
	_=tst
	+ /bin/expr tst : \(.*\),v | tst 
	cmdname=tst

Thanks.
From: vtessier@vela.acs.oakland.edu (Vince Tessier)
Newsgroups: gnu.bash.bug
Subject: Re: How to build with -O?
Date: 22 Jan 1993 21:08:02 -0500
Organization: Oakland University, Rochester MI.
Distribution: gnu

neal@ctd.COMsat.COM (Neal Becker) writes:

>What's the easiest way to build bash-1.12 with -O instead of -g?

My diffs say I changed cpp-Makefile as follows (from 'diff -u'):

@@ -192,7 +192,7 @@
 SYSTEM_FLAGS = $(LINEBUF) $(VPRINTF) $(UNISTD) $(GROUPS) $(RESOURCE) \
        $(SIGHANDLER) $(SYSDEP) $(WAITH) $(GETWD) $(DUP2) $(STRERROR) \
        -D$(MACHINE) -D$(OS)
-DEBUG_FLAGS = $(PROFILE_FLAGS) -g
+DEBUG_FLAGS = $(PROFILE_FLAGS) -O2
 LDFLAGS        = $(NOSHARE) $(SYSDEP_LD) $(EXTRA_LD_PATH) $(DEBUG_FLAGS)
 CFLAGS = $(DEBUG_FLAGS) $(SYSTEM_FLAGS) -DSHELL $(ALLOCA_CFLAGS)
 CPPFLAGS= -I$(LIBSRC)

DEBUG_FLAGS was defined as '-g'; I changed it to '-O2'

Look also at the Makefiles in the subdirs under 'lib'
-- 
Vince Tessier (vtessier@vela.acs.oakland.edu)		"Execute Plan `B'."
From: dtm@corp.SUn.COM (Duane T. Mun)
Newsgroups: gnu.bash.bug
Subject: Re: bash for beginners
Date: 21 Jan 1993 18:13:49 -0500
Organization: Sun Microsystems, Inc.
Distribution: gnu

On 20 Jan 1993 22:37:44 -0500, arndt@kaa.informatik.rwth-aachen.de (Stefan Arndt) said:

Stefan> My problem is that the arrow keys don't work in a sun command
Stefan> tool ( $TERM=sun-cmd ).

I've had several problems running bash with CommandTool.  So...I use
xterm instead.  This seems to have _fixed_ all of the problems I was
having.

--
From: wbader@csee.lehigh.edu (wbader)
Newsgroups: gnu.bash.bug
Subject: bash, sco unix and sco xenix
Date: 26 Jan 1993 22:19:52 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Changes to build bash-1.12 under SCO Unix 3.2v4.0:

In the M_UNIX section of machines.h:

#    if !defined (HAVE_GCC)
#      define REQUIRED_LIBRARIES -lPW -lmalloc -lc_s
#    endif /* !HAVE_GCC */

SCO Unix has alloca() in -lPW.
malloc pulls in a faster malloc than the one in -lc
-lc_s uses a shared library version of the c runtimes

jobs.c:

The ' #if defined (SCO) ' sections make bash hang on the call to waitpid.
I removed the SCO conditional code, and bash no longer hangs.
Apparently, SCO fixed the sigsuspend() call in 3.2v4.0, and somehow broke
something that the workaround uses.

lib/readline/readline.c:

*** readline.c-	Mon Jan 25 15:21:13 1993
--- readline.c	Tue Jan 26 14:29:50 1993
***************
*** 4530,4533 ****
--- 4530,4537 ----
    int reverse = (direction < 0);
  
+ #if 1
+   int pre_search = 0;
+ #endif
+ 
    /* Create an arrary of pointers to the lines that we want to search. */
    maybe_replace_line ();
***************
*** 4560,4565 ****
--- 4564,4576 ----
  
    /* Initialize search parameters. */
+ #if 1
+   strncpy(search_string, the_line, 127);
+   search_string[127] = '\0';
+   search_string_index = strlen(search_string);
+   if (direction < 0 && rl_point > 0) { pre_search = 1; rl_point = 0; }
+ #else
    *search_string = '\0';
    search_string_index = 0;
+ #endif
  
    /* Normalize DIRECTION into 1 or -1. */
***************
*** 4576,4579 ****
--- 4587,4593 ----
    while (!done)
      {
+ #if 1
+       if (pre_search) { c = -1; pre_search = 0; } else
+ #endif
        c = rl_read_key ();
  
So history searches start with the text already on the line as the pattern.


changes for SCO Xenix 2.3.3:

machines.h:

Xenix 2.3 should not use -DREVERSED_SETVBUF_ARGS.
Only Xenix 2.2 has them reversed.

Xenix 2.3 does not have getwd(), and should #undef HAVE_GETWD.

readline.c:

Added Xenix to list of systems that #undef HAVE_BSD_SIGNALS.

----------------------------------------

How hard would it be to add
((...))  (for quoted expressions, equivalent to let "...") and
[[...]]  (shorthand for test. evaluates an expression and returns 0 for true)
These two changes would allow bash to run more ksh scripts.


William Bader
Software Consulting Services
3162 Bath Pike
Nazareth, PA  18064
phone: 215-837-8485
fax:   215-837-8080
email: wbader@scarecrow.csee.lehigh.edu,
       wbader@einstein.mse.lehigh.edu,
       lehi3b15.csee.lehigh.edu!batman!bader
From: uli@intellektik.INformatik.TH-darmstadt.DE (Ulrich Grepel)
Newsgroups: gnu.g++.bug
Subject: internal compiler error 62 in gcc 2.3.3
Date: 26 Jan 1993 21:59:41 -0500
Organization: GNUs Not Usenet
Distribution: gnu

The following code makes gcc 2.3.3 (configured for NeXT)
to issue 'Internal compiler error 62.', 'Please report...'.

You're welcome...

Bye,

Uli

------------------8<---------------------
class A
{
protected:
    struct B
    {
        int c;
    };
    typedef struct B *D;
};

class E : public A
{
    D f[10];                        // this is the errorneous line
};
------------------8<---------------------
From: K3EES4_SU@siiks_a1.bosch.DE
Newsgroups: gnu.g++.bug
Subject: G++
Date: 21 Jan 1993 18:03:47 -0500
Organization: GNUs Not Usenet
Distribution: gnu

From:	NAME: K3/EES4-Schulz Kay            
	FUNC: K3/EES4                         
	TEL: 0711/811-20993                   <K3EES4_SU@SIIKS_A1@SIIKS>
To:	in%"gnu-g++@prep.ai.mit.edu"@gxlink

Dear Ladies and Gentlemen,
I am developping on an Ultrix 4.2 and I use your 
g++ 1.4
and gcc 2.1

I can't read news so I have a question if the following is a 
bug of this old version or not!

I have a base class and a derived class. I use destructors:
e.g.
class A
{
	A(); //Constr.
	virtual ~A(); //DESTR.
	//body
}
class B:public A
{
	B();	//Constr.
	~B():	//Destr.
	//more code
}
Stroustrup says this should work, it produces the following output:
_$_8A
_$_20B

Why?
If I use this:
class A
{
	A();
	~A();
	//virtual functions following
}
class B
{
	B();
	//code for virtual functions in class a or definition
}
I get the output:
warning: class A has virtual functions but non-virtual destructor.

I need help, else I can't go on working, or only withou
destructors . Is a bug of your compiler or linker and is fixed
in the newer versions or is it a feature or is it correct?

Thanks

KAY SCHULZ
k3ees4_su@siiks_a1.bosch.de
Falkenweg 9
7120 Bietigheim-Bissingen
GERMANY
Tel. private: 0049714265643
Tel. Job: 004971181120993
From: bret@essex.ac.UK
Newsgroups: gnu.g++.bug
Subject: bug report ...
Date: 26 Jan 1993 22:08:28 -0500
Organization: GNUs Not Usenet
Distribution: gnu

Just doin what gcc tells me too. Trying to compile groff on a DECstation
5000/25 and this happens

gcc -O -I. -I. -I../include -I./../include -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_DIR_H=1 -DHAVE_CC_LIMITS_H=1 -DHAVE_CC_UNISTD_H=1 -DSTDLIB_H_DECLARES_GETOPT=1 -DSTDLIB_H_DECLARES_PUTENV=1 -DHAVE_MMAP=1 -DHAVE_RENAME=1 -DHAVE_SYS_SIGLIST=1 -DWCOREFLAG=0200 -g  -c object.cc
In file included from /usr/local/lib/gcc-lib/decstation-ultrix/2.3.3/include/syslimits.h:6, from /usr/local/lib/gcc-lib/decstation-ultrix/2.3.3/include/limits.h:11, from ../include/cset.h:22, from pic.h:28, from object.cc:21:
/usr/include/limits.h:190: warning: `FLT_MAX' redefined
/usr/local/lib/gcc-lib/decstation-ultrix/2.3.3/include/float.h:35: warning: this is the location of the previous definition
/usr/include/limits.h:197: warning: `HUGE_VAL' redefined
/usr/local/lib/g++-include/math.h:158: warning: this is the location of the previous definition
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'.
*** Error code 1

Bret
From: yb@lri.FR
Newsgroups: gnu.g++.bug
Subject: badly generated operator new in template
Date: 26 Jan 1993 22:06:10 -0500
Organization: GNUs Not Usenet
Distribution: gnu

g++ 2.3.3 generates incorrect operator new when it is defined in a template class. 
Looking at the assembly code, I noticed that the allocated-size is not loaded
from the good register.

The following piece of code illustrates this problem :

% cat foo.cc
#include <stddef.h>
#include <stdio.h>

template <class T>
class A {
public:
	T v;
	void* operator new (size_t);
};

template <class T> void*
A<T> :: operator new (size_t s)
{
	printf ("%d\n", s);
	return new char [s];
}

main ()
{
	printf ("%d\n", sizeof(A<int>));
	A<int>* a = new A<int>;
}
% gcc -v
Reading specs from /usr/local/gnu/lib/gcc-lib/hp700-hpux/2.3.3/specs
gcc version 2.3.3
% gcc foo.cc
% a.out
4
-278528
Virtual memory exceeded in `new'
----------------
Interesting !

+--------------------------+------------------------------------+
|                          |       E-mail : yb@lri.lri.fr       |
|     Yves Berteaud        |                yb@FRLRI61.BITNET   |
|                          |                                    |
|       +-=-+-=-+          |       Voice :  33 (1) 69-41-69-10  |
|                          |       Fax   :  33 (1) 69-41-65-86  |
+--------------------------+------------------------------------+
|      ######      **                                           |
|     ##     #         Laboratoire de recherche en informatique |
|    ##       #   ##   Batiment 490                             |
|   ##       #   ##    Universite de Paris-Sud                  |
|  ##    ####   ##     91405 ORSAY Cedex                        |
| ######    ## ##      FRANCE                                   |
|######      ###                                                |
+---------------------------------------------------------------+
From: dlong@cse.ucsc.EDU (Dean R. E. Long)
Newsgroups: gnu.g++.bug
Subject: g++ 2.3.3 const non-warning
Date: 22 Jan 1993 21:45:33 -0500
Organization: University of California, Santa Cruz (CE/CIS Boards)
Distribution: gnu

I would expect g++ to give me a warning for calling a non-const
member function with a const object in the following, but it does not:

class B {
    int x;
public:
    void foo(void) { x = 1; }
};

class A {
    B *p;
public:
    A() { p = 0; }
    const B & ro() { return *p; }
};

main()
{
    A a;
    a.ro().foo();	// warn me, please!
}
From: dak@tabaqui.informatik.rwth-aachen.de (David Kastrup)
Newsgroups: gnu.g++.bug
Subject: gcc-2.3.3, option -dynamic quite spectacular
Date: 22 Jan 1993 21:05:54 -0500
Organization: Rechnerbetrieb Informatik - RWTH Aachen
Distribution: gnu

The option is passed to all phases of the compiler, which feel compelled
to treat it as some sort of debug option, and generate masses
of debug files, and a process list. Quite funny.
From: willoch@oslo.sgp.slb.com (thorbjorn willoch)
Newsgroups: gnu.g++.bug
Subject: Please report this to `bug-g++@prep.ai.mit.edu'.
Date: 26 Jan 1993 21:50:11 -0500
Organization: GNUs Not Usenet
Distribution: gnu

gcc-2.3 -x c++ t.c -traditional
t.c:1: warning: all member functions in class `a' are private
t.c:1: warning: class `a' only defines private constructors and has no friends
t.c: In function `int  f (...)':
t.c:4: Internal compiler error.
t.c:4: Please report this to `bug-g++@prep.ai.mit.edu'.


t.c:
class a { int b; a(){} };
int f()
{
 a *aa= new a[100];
delete [100] aa;
}


Thorbjorn