HDTenEightyP/NetNews huggingface dataset:
From: detlefs@src.dec.com (Dave Detlefs)
Subject: Byte-compilation problems
Organization: DEC Systems Research Center
Date: Wed, 11 Nov 92 18:43:08 GMT


I've been having a problem with byte-compilation.  There's a certain
(pretty big!) .el file I have that works fine if I load the .el, but
if I byte-compile it and load the .elc, I get immediately get a
message like

  EMACS BUG! INVALID DATATYPE (#o 20) save your buffers and exit blah blah

Further, byte-compiling this file takes a *long* time, on the order of
ten minutes; it seems near the end that at least one GC happens
between every two defuns compiled.  Sometimes, it seems to get hung up
and never complete at all.

When I byte-compile this file with gnuemacs, it zips by in about 10
seconds, and the resulting .elc seems to work fine.

The only thing I can imagine is that the heap size for the epoch is
too small, and the heap size for the gnuemacs I was using was set
large enough.  I poked around, but I don't see what controls the size
of the heap.  Is this a reasonable hypothesis; has anyone noticed
similar problems; any ideas?

Thanks...

Dave
Newsgroups: gnu.epoch.misc
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: Scrolling broken, detailed info enclosed
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 13 Nov 1992 04:10:15 GMT

Lonhyn T. Jasinskyj writes:
> VERSION:  Epoch 4.2, but the same held for Epoch 4.x, not sure about 3.x
> 
> on an SGI Iris running Irix 4.0.x (not really important, I think
> this should happen on any architecture)

I absolutely cannot reproduce this, and I'm running on an IRIS Indigo
under 4.0.2.  In fact, I've never seen it...

Marc

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu

Newsgroups: gnu.epoch.misc
From: scotth@oldman.com (Scott Herzinger)
Subject: epoch focus policy
Organization: Wind River Systems
Distribution: na
Date: Sat, 14 Nov 1992 00:14:51 GMT

How does one control focus in epoch? I haven't found anything helpful
in the manual yet. If it's there, please let me know. If it's not, can
someone help? I'm relatively new to epoch.

Window manager is twm, X is R5. Focus normally follows the pointer
from X window to X window. When I launch epoch, it also starts out
that way.

As I move from screen to screen, focus initially follows the pointer.
Eventually, epoch fails to move the focus to the screen that contains
the pointer.  Instead, focus remains on the last screen that I clicked
in. I have to click to move the focus to a different screen. It stays
this way until I quit epoch.

I don't know if the change in focus policy occurs due to a bug, upon
some even, or what. I don't do anything in particular that I've been
able to associate with the change in behavior.

Any suggestions?

Thanks,

Scott		scotth@wrs.com		(510) 814-2079
Newsgroups: gnu.epoch.misc
From: rv@cs.brown.edu (rodrigo vanegas)
Subject: bug with X window focus switching?
Organization: Dept. of Computer Science, Brown University
Distribution: gnu
Date: Tue, 10 Nov 1992 04:01:26 GMT

I think I have found a bug with Epoch 4.2.  

Usually, four different indicators change state when i move my mouse
about my X terminal changing pointer the focus from one window to
another.

  1) the window border changes color.
  2) the titlebar is highlighted or changed back to normal.
  3) the border of the relevant window entry the in icon manager is
     highlighted.
  4) and, cursor is "filled" or "hollowed".

Also, with my current setup (X11R4 and twm), I can change the pointer
focus in three different ways.

  1) move the pointer into the window, using the mouse
  2) move the pointer over the entry in the icon manager, using the mouse.
  3) and, move the pointer through the entries in the icon manager
     using keymappings (defined in .twmrc).

The bug is essentially this: When switching the pointer focus from or
to an epoch window using method number 3, then indicator number 4 does
not change state.

Has anyone had similar problems?



rodrigo vanegas
rv@cs.brown.edu
brown university
Newsgroups: gnu.epoch.misc
From: marca@ncsa.uiuc.edu (Marc Andreessen)
Subject: ``marker does not point anywhere'' from hell....
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 00:33:59 GMT

The patch at the end of this message will at the very least keep X
servers from being fried on the ``marker does not point anywhere''
bug.  However, I still don't know why it happens, especially since I
have no way of reproducing it (it's never happened to me).

If the bug hits after you install this patch, let me know what gets
printed out...

Marc

--------------------------------- CLIP CLIP ----------------------------------
*** marker.c.old        Wed Aug 26 21:55:15 1992
--- marker.c    Fri Nov  6 06:30:45 1992
***************
*** 256,262 ****
    register int i = m->bufpos;
  
    if (!buf)
!     error ("Marker does not point anywhere");
  
    if (i > BUF_GPT (buf) + BUF_GAP_SIZE (buf))
      i -= BUF_GAP_SIZE (buf);
--- 256,268 ----
    register int i = m->bufpos;
  
    if (!buf)
!     {
!       printf ("--> marker %08x\n", marker);
!       printf ("    m      %08x\n", marker);
!       printf ("    m->buffer %08x\n", m->buffer);
!       printf ("    m->bufpos %d\n", m->bufpos);
!       /* error ("Marker does not point anywhere"); */
!     }
  
    if (i > BUF_GPT (buf) + BUF_GAP_SIZE (buf))
      i -= BUF_GAP_SIZE (buf);
--------------------------------- CLIP CLIP ----------------------------------

--
Marc Andreessen
Epoch Development Team
University of Illinois at Urbana-Champaign
marca@ncsa.uiuc.edu

Newsgroups: gnu.epoch.misc
From: anon@eecs.umich.edu (Omar S. Juma)
Subject: Re: Got a good Epoch icon for root menus?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 11 Nov 1992 21:14:32 GMT

> 
> 
> 	Howdy, I'm looking for a bitmap that would make a good
> Epoch icon, to be used in an mwm or olvwm root menu.  Email would be fine.
> 
> 				Daniel
> -- 
>      Daniel Smith, Autodesk, Sausalito, California, (415) 332-2344 x 2580
> 	      Disclaimer: written by a highly caffeinated mammal
> 	    dansmith@autodesk.com            dansmith@well.sf.ca.us
> 
> 

Here's a first attempt:

#define EpochStd_48x48_width 48
#define EpochStd_48x48_height 48
#define EpochStd_48x48_x_hot -1
#define EpochStd_48x48_y_hot -1
static char EpochStd_48x48_bits[] = {
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xc0, 0xff, 0xff, 0xff, 0x01, 0x00,
   0x40, 0x00, 0x00, 0x00, 0x03, 0x00, 0x40, 0x00, 0x00, 0x00, 0x1d, 0x00,
   0x40, 0x00, 0x00, 0x00, 0x39, 0x00, 0x40, 0x00, 0x00, 0x00, 0x71, 0x00,
   0x40, 0xf8, 0xff, 0x0f, 0xe1, 0x00, 0x40, 0x00, 0x00, 0x00, 0xc1, 0x01,
   0x40, 0xf0, 0xff, 0x3f, 0xff, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xf8, 0x0f, 0x00, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xf8, 0x3f, 0x00, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xe0, 0xff, 0x07, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xe0, 0xff, 0x03, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xe0, 0xff, 0x1f, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xf8, 0x3f, 0x00, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xf8, 0xff, 0x00, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0x78, 0x00, 0x00, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xf0, 0xff, 0x03, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xe0, 0xff, 0x07, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xf0, 0xff, 0x03, 0x80, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0xe0, 0xff, 0x0f, 0x8e, 0x03, 0x40, 0x00, 0x00, 0x00, 0x81, 0x03,
   0x40, 0xf8, 0xff, 0x01, 0x81, 0x03, 0x40, 0x00, 0x00, 0x00, 0x8f, 0x03,
   0x40, 0xf8, 0x1f, 0x00, 0x81, 0x03, 0x40, 0x00, 0x00, 0x00, 0x81, 0x03,
   0x40, 0x00, 0x00, 0x00, 0x8e, 0x03, 0x40, 0x00, 0x00, 0x00, 0x80, 0x03,
   0x40, 0x00, 0x00, 0x00, 0x80, 0x03, 0xc0, 0xff, 0xff, 0xff, 0xff, 0x03,
   0x00, 0xff, 0xff, 0xff, 0xff, 0x03, 0x00, 0xff, 0xff, 0xff, 0xff, 0x03,
   0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};

Do these managers accept external specification of pixmaps?


...anon...
anon@eecs.umich.edu
Newsgroups: gnu.epoch.misc
From: rv@cs.brown.edu (rodrigo vanegas)
Subject: bug with X window focus switching?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 19:41:59 GMT


>rodrigo> Has anyone had similar problems?

> I am able to reproduce your results.

> The same behavior occurs with an xterm. I do not consider this a bug.


That's funny.  It happens neither to my xterms nor to my emacs.
Is the cursor always filled for you?


rodrigo
From: hollick@itchy.cis.upenn.edu (Mike Hollick)
Newsgroups: gnu.epoch.misc
Subject: Lightbrite analog for printing?
Summary: hooked on highlighting
Date: 13 Nov 92 15:31:10 GMT
Organization: UPENN Computer Graphics Research Laboratory


Hello.  I was wondering if there was any package that could print
files with highlighting, similar to the lightbrite package.  Of
course, since we don't have color postscript, it would have to use
fonts, underlining, etc. instead....  Does such a thing exist?  If
not, is there something similar that I could modify?  Thanks a lot!

--> Mike
From: pinard@iro.umontreal.CA (Francois Pinard)
Newsgroups: gnu.bash.bug
Subject: cd x y
Date: 5 Nov 92 20:53:07 GMT
Distribution: gnu
Organization: GNUs Not Usenet


   > I'm using GNU bash 1.12.  Is this normal that cd accepts more than one
   > argument, without complaining?

   Sure, it's normal.  sh accepts two arguments without complaint.

This is not because one sins that it becomes normal to sin.  Are you
kidding me?  In case not, (Chet is usually a serious guy :-), let me
attempt another phrasing:

	Should cd accept more than one argument without complaining?
	Would'nt it be better if bash complained when this happens?

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!
From: ohl@chico.harvard.edu (Thorsten Ohl)
Newsgroups: gnu.bash.bug
Subject: bash-1.12 vs. NeXTStep 3.0
Date: 5 Nov 92 12:13:11 GMT
Distribution: gnu
Organization: GNUs Not Usenet

In order to build bash-1.12 on the NeXT, I found the following trivial
patch necessary:

RCS file: /home/sources/gnu/bash/machines.h,v
retrieving revision 1.1
diff -c -7 -r1.1 machines.h
*** 1.1	1992/11/05 20:35:12
--- machines.h	1992/11/05 21:20:19
***************
*** 535,548 ****
--- 535,549 ----
  #if defined (NeXT)
  #define M_MACHINE "NeXT"
  #define M_OS Bsd
  #define HAVE_VFPRINTF
  #define HAVE_SYS_SIGLIST
  #define HAVE_GETGROUPS
  #define HAVE_STRERROR
+ #define HAVE_RESOURCE
  #define VOID_SIGHANDLER
  #undef USE_GNU_MALLOC
  #endif
  
  /* ************************ */
  /*			    */
  /*	hp9000 4.3 BSD	    */


Still, getwd(3) seems to be broken on the NeXT: sometimes it will
return a zero length string in the buffer.

`alias pwd=/bin/pwd' is an ugly workaround, has anybody tried to get a
patch from NeXT or else tried the getcwd() that comes with bash?

/// Thorsten Ohl, Physics Dept, Harvard University, Cambridge, MA 02138, USA
//////// net: ohl@physics.harvard.edu, ohl@crunch.ikp.physik.th-darmstadt.de
////////////////////////////// voice: +1-617-495-3219,  fax: +1-617-496-8396
From: joares@colargol.ai.mit.EDU (Jo-Are Stubmo)
Newsgroups: gnu.bash.bug
Subject: Re: problem with bash + xon + sunos ...
Date: 5 Nov 92 11:56:11 GMT
Distribution: gnu
Organization: Colargol, Trondheim College of Engineering

Minh Tran-Le (TRANLE@intellicorp.com) wrote:
: Hi,
: I have `bash' as my standard login shell under sunos 4.1.1 and I am
: trying to use the X11 R5 script `xon' that allow to create an xterm
: on a remote machine using your local display.  Has anybody noticed
: that on the sun the xon script keep the connection open until the 
: remote xterm dies.
: 
: The xon script does something like this:
: 
:   rsh remotehost "sh -c 'DISPLAY=currentdisplay:0.0 xterm -ls >/dev/null \
:   2>&1 &'"
: 
: This should run the remote xterm in the background at the remote host.
: 
: If your login shell is bash then the rsh command hangs until the remote
: xterm dies.  If your login shell is csh or your remote host is not 
: running sunos (e.g. rs6000 running bash) then the xon command terminate
: immediatly without waiting for the remote xterm to die.
: 
: Thanks,
: Minh Tran-Le.
: -------

Hi!

If you have problems using xon you could try xrsh which is a shell script
that allows you to start a command at another machine displaying the output
on your local machine just as xon does. I can do 'xrsh alpha' from machine
beta to start a xterm at machine alpha. I can also do a long command from
xrsh. You can find xrsh on nic.funet.fi:/pub/X11/contrib/xrsh

bjornw>
--
The sooner all the animals are dead, the sooner we'll find all their money.
Newsgroups: gnu.bash.bug
From: chet@odin.ins.cwru.edu (Chet Ramey)
Subject: Re: cd x y
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 11:07:46 GMT

>    > I'm using GNU bash 1.12.  Is this normal that cd accepts more than one
>    > argument, without complaining?
> 
>    Sure, it's normal.  sh accepts two arguments without complaint.
> 
> This is not because one sins that it becomes normal to sin.  Are you
> kidding me?  In case not, (Chet is usually a serious guy :-), let me
> attempt another phrasing:
> 
> 	Should cd accept more than one argument without complaining?
> 	Would'nt it be better if bash complained when this happens?

If you think sh compatibility is important, then it should not complain.

One can always put the following into ~/.bashrc:

cd()
{
	if [ $# -gt 1 ]; then
		echo "cd: too many arguments" 1>&2
		return 1
	fi
	builtin cd "$@"
}

In fact, if you want to go all the way to ksh, try this:

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
}

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: cd x y
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 05:01:54 GMT

> I'm using GNU bash 1.12.  Is this normal that cd accepts more than one
> argument, without complaining?

Sure, it's normal.  sh accepts two arguments without complaint.

--
``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: AIX 3.2
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 04:57:53 GMT

> I have encountered the following problem while attempting to make bash 1.12
> on an IBM RS/6000 model 350 running AIX 3.2 (by the way, it worked well
> on Ultrix 4.2):

Make the offending lines in general.h look like this:

#if !defined (__STDC__) && !defined (index)
char *index (), *rindex ();
#endif

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: problem with bash + xon + sunos ...
Reply-To: chet@po.cwru.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 5 Nov 1992 04:48:35 GMT

> I have `bash' as my standard login shell under sunos 4.1.1 and I am
> trying to use the X11 R5 script `xon' that allow to create an xterm
> on a remote machine using your local display.  Has anybody noticed
> that on the sun the xon script keep the connection open until the 
> remote xterm dies.
> 
> The xon script does something like this:
> 
>   rsh remotehost "sh -c 'DISPLAY=currentdisplay:0.0 xterm -ls >/dev/null \
>   2>&1 &'"
> 
> This should run the remote xterm in the background at the remote host.
> 
> If your login shell is bash then the rsh command hangs until the remote
> xterm dies.  If your login shell is csh or your remote host is not 
> running sunos (e.g. rs6000 running bash) then the xon command terminate
> immediatly without waiting for the remote xterm to die.

It's a bug in rsh that Sun has not yet fixed.  Here's a message I sent to
the IBM guy who had the same problem (which is why it's fixed in AIX):

Date: Sat, 27 Apr 91 19:31:16 -0400
From: Chet Ramey <chet@odin.INS.CWRU.Edu>
To: bfox@ai.mit.edu
Subject: Re: [pedz@aixwiz.austin.ibm.com: fd 9 left open bug]
Cc: chet@odin.INS.CWRU.Edu, pedz@aixwiz.austin.ibm.com

> Below is something I call Xemacs which goes across the net, sets up the
> display variable and then kicks off emacs in such a way that rshd
> terminates.  The trick is that the shell must die and all file
> descriptors going back to rshd must be closed.  The same basic script
> works with csh but I had to add in the "9>&-" part at the end to make
> it work with bash.   This is because somehow, file descriptor 9 is left
> open and I guess it must be a dup of stdin, stdout, or stderr.

This is a bug alright, but it's a bug with rshd that's not fixed until
4.3-reno.

rshd sets up a pipe (int pv[2]; if you have the source to the tahoe rshd)
to the process it executes and uses it to manage error and control output
from over the net.  In the child process, it does a dup2(pv[1], 2), but
never calls close(pv[1]).  Adding that code to the 4.3-tahoe rshd makes it
(and the Xemacs script) work right.

I don't know how to solve this cleanly in bash.  Doing a blanket close of
all open file descriptors > 2, < 20 is a no-no, especially when we're not
interactive.  csh `works' because it does the blanket close on startup, but
csh can get away with doing that because it doesn't let you manipulate
arbitrary file descriptors.

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: jjd@spserv.bbn.com (James J Dempsey)
Subject: Re: problem with bash + xon + sunos ...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 6 Nov 1992 15:11:58 GMT

> > I have `bash' as my standard login shell under sunos 4.1.1 and I am
> > trying to use the X11 R5 script `xon' that allow to create an xterm
> > on a remote machine using your local display.  Has anybody noticed
> > that on the sun the xon script keep the connection open until the 
> > remote xterm dies.

People who are having this problem with SunOS might consider using the
xrsh script that is available on export.lcs.mit.edu:contrib/xrsh-5.4.shar.

It has a multitude of features not available in the R5 xon, and
explicitly uses csh as the remote shell so that even bash users have
the remote rsh exit before the remote xterm.

The local rsh does stick around until the remote client exits on some
System V machines such as HP-uX because have different bugs, but I
haven't been able to solve that in a portable way.

		--Jim Dempsey--
		jjd@bbn.com

Newsgroups: gnu.g++.bug
From: timhu@ico.isc.com (Timothy Hu)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 03:20:42 GMT

Sir/Madam: (bug-g++@prep.ai.mit.edu)

I'm trying to install g++ v1.42.0 on SPARC 1+ running SunOS 4.1.2. When I run
config as follows:

config.g++ sunr-os4


I get the following error:

config.g++: cannot create a link `config.h',
since the file `config/xm-sunr-os4.h' does not exist.

I have gcc v2.3.1 installed.

Where do I go from here?

Thanks,
Tim


Newsgroups: gnu.g++.bug
From: timhu@ico.isc.com (Timothy Hu)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 10 Nov 1992 04:04:30 GMT

Sir/Madam: (bug-g++@prep.ai.mit.edu)

I'm trying to install g++ v1.42.0 on SPARC 1+ running SunOS 4.1.2.

When running "make maketest", the file make-links.g++ can't seem to make the links
to the following files in gcc (because they don't exist in gcc or gcc/config:

  symout.c global-alloc.c symseg.h gdbfiles.h stddef.h limits.h

I have gcc v2.3.1 installed.

Where do I go from here?

Thanks,
Tim


Newsgroups: gnu.g++.bug
From: lewis@sophists.COM
Subject: Bug parsing enumerators in nested enum with gcc 2.3.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 9 Nov 1992 18:15:05 GMT

/*
 * I believe the initializer below should be allowed?
 * I've found nothing in the ARM that proves this conclusively,
 * but ARM page 114 gives an example of an enum with the initializer
 * for the enumerator being an expression involving a previously
 * defined initializer. The example was a global enum, not a nested
 * one however.
 *
 * The problem seems to be that you consider the scope of the initializers
 * to be the global scope, and I think the scope should include the current
 * enumerators.
 *
 *
 * The file is compiled with gcc 2.3.1 as follows:
 *      g++ -c bug.c
 *
 * and the output is:
 *
 * bug.c:32: `b' undeclared, outside of functions
 * bug.c:32: enumerator value for `bfirst' not integer constant
 */

enum {
        a,
        first = a,      // compiles OK
};


struct fred {
        enum {
                b,
                bfirst = b,     // compiles with CFront, but not g++
        };
};
Lewis Gordon Pringle, Jr.                                (lewis@sophists.com)


Newsgroups: gnu.g++.bug
From: mrs@cygnus.com (Mike Stump)
Newsgroups: gnu.g++.bug
Subject: Re:  g++ 2.2.1 template bug (2)
Date: 6 Nov 92 08:28:00 GMT
Article-I.D.: cygnus.9211060828.AA01426
Distribution: gnu
Organization: GNUs Not Usenet

This problem has been fixed, and should not exist in the next release of gcc.

> Message-Id: <9206121504.AA01165@joker>
> From: stefan@mpi-sb.mpg.de
> To: bug-gcc@prep.ai.mit.edu
> Date: Fri, 12 Jun 92 17:04:20 +0200
> Organization: Universitaet des Saarlandes
>               D-W-6600 Saarbruecken, Germany

> // g++-2.2.1: member functions returning a template type 

> template <class T> struct list { };

> struct A
> {
>   list<int> L;

>   list<int>  get_list();

> };


> list<int> A::get_list() { return L; }


> /*

> OUTPUT:

> Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.1/specs
> gcc version 2.2.1
>  /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.1/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 template2.c /usr/tmp/cca16493.i
> GNU CPP version 2.2.1 (sparc)
>  /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.1/cc1plus /usr/tmp/cca16493.i -quiet -dumpbase template2.cc -version -o /usr/tmp/cca16493.s
> GNU C++ version 2.2.1 (sparc) compiled by GNU C version 2.2.1.
> template2.c:17: semicolon missing after declaration of `list<int>'
> template2.c: In method `int  A::get_list (struct A*)':
> template2.c:17: conflicting types for `int  A::get_list (struct A*)'
> template2.c:12: previous declaration of `struct list<int> A::get_list ()'
> template2.c: In method `struct list<int> A::get_list ()':
> template2.c:17: aggregate value used where an integer was expected

> */
Newsgroups: gnu.g++.bug