HDTenEightyP/NetNews huggingface dataset:
From: brendan@cygnus.com (Brendan Kehoe)
Subject: [laurenz@juno.neuroinformatik.ruhr-uni-bochum.de : gcc-2.2.2 libg++-2.2 stream bugs]
Reply-To: brendan@cygnus.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 02:19:51 GMT

------- Start of forwarded message -------
From: laurenz@juno.neuroinformatik.ruhr-uni-bochum.de (Laurenz Wiskott)
Subject: gcc-2.2.2 libg++-2.2 stream bugs
To: bug-gcc@prep.ai.mit.edu
Cc: neef@neuroinformatik.ruhr-uni-bochum.de,
        laurenz@neuroinformatik.ruhr-uni-bochum.de
Date: Fri, 9 Oct 92 10:07:15 +0100

	Dear 'GNU',

I've great respect for your Organization and like your software very
much. Many thanks for all that.

We are just changing from the AT&T C++ compiler to your gcc-2.2.2 with
the libg++-2.2. And the bugs changes also. I think I've found at least
one bug concerning the file streams. Here follows a simple example:

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

#include <fstream.h>

main()
{
  // the test files test1 and test2 do not yet exist ;

  // this behaves as expected ;
  ifstream ifile;
  ifile.open("test1",ios::in);
  cerr << ifile.good() << flush;
  ofstream ofile;
  ofile.open("test1",ios::out);   // the test1 file will be created here ;
  ofile << "data1" << flush;
  cerr << ofile.good() << flush;

  // but it is not possible to open a fstream 
  // in order to write something onto a file 
  // after you have tried to open it fruitless for a read access ;
  fstream iofile;
  iofile.open("test2",ios::in);
  cerr << iofile.good() << flush;
  iofile.close();              // even with a close() command ;
  iofile.open("test2",ios::out); 
  cerr << iofile.fail() << iofile.good() << flush; // output: 40
  iofile << "data2" << flush;   // no data in the test2 file ;

  // but it works with the AT&T compiler ;
};

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

The second is more an uncomfortable feature than really a bug I think.
Consider the following two programs.

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

#include <stream.h>

typedef char arrType;
#define arrSize 16

main()
{
  arrType arr[arrSize];
  for (int i=0; i<arrSize; i++)
    arr[i]=(arrType)i;
  cout.write((char *)arr,sizeof(arrType)*arrSize);
//  cout.flush();
}

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

#include <stream.h>

typedef char arrType;
#define arrSize 16

main()
{
  arrType arr[arrSize];
  cin.read((char*)arr,sizeof(arrType)*arrSize);
  for (int i=0; i<arrSize; i++)
    cerr << i << " : " << float(arr[i]) << "\n";
}

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

Compile it to get the executables 'out' and 'in' and pipe the result
of the first to the second: out|in. You can do it with or without the
flush command. The flush seems necessary but as I think it would be
more comfortable if it would not. 


	Kind regards, Laurenz Wiskott.



------- End of forwarded message -------

Newsgroups: gnu.g++.lib.bug
From: G.Joly@cs.ucl.ac.uk (Gordon Joly)
Subject: Re: SunOS shared library version
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 17:32:35 GMT

> > Is it possible to produce a shared library version of libg++ (2.2)?
> 
> It should be possible.  In the past, we supported libg++ as
> a SunOS shared library for one customer, but that support
> got dropped in favor on concentrating on getting libg++ more portable.
> I will welcome patches that ease bulding of shared libraries
> - especially if acompanied by documentation on how to do it!
> 
>         --Per Bothner
> Cygnus Support     bothner@cygnus.com


I will try to put something together: but I guess I shall to 
read standards.texi:-)


Gordon Joly      Phone  +44 71 387 7050 ext 3703      FAX  +44 71 387 1397
Internet: G.Joly@cs.ucl.ac.uk        UUCP: ...!{uunet,uknet}!ucl-cs!G.Joly
Computer Science, University College London, Gower Street, LONDON WC1E 6BT


Newsgroups: gnu.g++.lib.bug
From: mckellar@cs.ualberta.ca (Neil McKellar)
Subject: libg++-2.2 test suite
Keywords: gnu,g++,libg++
Organization: University of Alberta, Edmonton, Canada
Distribution: gnu
Date: Wed, 14 Oct 1992 09:26:29 GMT

Hi.  I am installing libg++-2.2 on an SGI running IRIX 4.0.4 using gcc 2.2.2.
I ran configure.

  % configure mips-sgi-irix4.0.4
  % make

It compiled fine, so I decided to run the test suite.

  % make check

Things went fine until we got to tComplex.cc in libg++/tests.
tComplex.cc compiles fine, but fails on

  a / b = (0.5609760976, 0.0487804878)

  where a = (2.0, 3.0)
        b = (4.0, 5.0)

At this point, close_enough() fails to assert() and dumps core.
Since the division by (1,0) earlier in the test succeeded, I can't understand
why this calculation fails.  Everything has been done using doubles for the
real values, so a loss of accuracy should not be the problem.

It seems strange that anything in the test suite should fail.  I imagine this
stuff is fairly well proven.  Have I done something silly during setup?
Any help or ideas about this would be appreciated.  Thanks in advance.

Neil McKellar (mckellar@cs.ualberta.ca)


Newsgroups: gnu.g++.lib.bug
From: fredr@raven.bu.edu (Fred Richardson)
Subject: Bug?
Organization: I can do that too !!!
Distribution: gnu
Date: Fri, 9 Oct 1992 21:10:37 GMT

I think I've found a bug which occurs when virtual functions are
overriden and called by the construction routine.  It looks like if a
virtual function is over riden by a derived class and it is called in the
base classes constructor then only the base classes implementation of the
virtual function will be called.

Here's a long example
(sorry, I could think of a shorter one):

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
/******************************************************************************
This is a test of virtual function overriding.


******************************************************************************/

#include <stdlib.h>
#include <String.h>
#include <string.h>

class base
{
  public:
    base(char* astr);
    virtual char* testVirtual();
    void test();
  protected:
    char* theStr= NULL;
};

class derived : public base
{
  public:
    derived(char* astr);
    char* testVirtual();  // Over-ridden virtual function
};

 base::base(char* astr)
{
    theStr = strdup(astr);
    test();  // call during initialization
}

char* base::testVirtual()
{
    String s = theStr;
    s = "base class: " + s + "\n";
    return(s);
}

void base::test()
{
    cout << testVirtual();
}

 derived::derived(char* astr) : base(astr)
{
}

char* derived::testVirtual()
{
    String s = theStr;
    s = "derived class: " + s + "\n";
    return(s);
}

int main(int argc, char *argv[])
{
    if (argc < 2)
	return(0);
    
    cout << "Here's the output during construction:\n";
    derived d(argv[1]);
    cout << "Here's the output after construction:\n";
    d.test();
    
    return(0);
}

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Here's the ouput from the shell when running the programming:

mynah:54> test_virt "Hello World"
Here's the output during construction:
base class: Hello World
Here's the output after construction:
derived class: Hello World
mynah:55> 

So as you can see, the derived classes virtual function is called during
initialization.  This is a serious limitation, especially if one wants to
allocate things differently during construction.

Newsgroups: gnu.g++.lib.bug
From: hillb@cs.ucdavis.edu (Brian C Hill)
Subject: DEC bug ...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 22:23:33 GMT

	I am trying to compile libg++2.2 and this is what happens:

===========================================================
$ make all 
echo "# !Automatically generated from ./functions.def"   "- DO NOT EDIT!" >neede
d2.awk
grep '^DEFVAR(' < ./functions.def   | sed -e '/DEFVAR/s|DEFVAR.\([^,]*\).*|/\1/
{ printf \"#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|'   >>needed2.awk
grep '^DEFFUNC(' < ./functions.def   | sed -e '/DEFFUNC/s|DEFFUNC.\([^,]*\).*|/\
1/ { printf \"#ifndef NEED_\1\\n#define NEED_\1\\n#endif\\n" }|'   >>needed2.awk
cc -Wf,-XNg1000 -c -g -I. -I./../include  ./dummy.c
(cc -Wf,-XNg1000  dummy.o  ) >errors 2>&1 || true
rm -f a.out dummy.o
echo "/* !Automatically generated from ./functions.def"   "- DO NOT EDIT! */" >c
onfig.h
awk -f needed2.awk <errors >>config.h
cc -Wf,-XNg1000 -c -g -I. -I./../include  basename.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  getopt.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  getopt1.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  obstack.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  spaces.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  concat.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  fdmatch.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  argv.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  strerror.c
cc -Wf,-XNg1000 -c -g -I. -I./../include  strsignal.c
echo "# !Automatically generated from ./functions.def"   "- DO NOT EDIT!" >neede
d.awk
grep '^DEF(' < ./functions.def      | sed -e '/DEF/s|DEF.\([^,]*\).*|/\1/ { prin
tf \"\1\.o " }|'      >>needed.awk
awk -f needed.awk <errors >needed-list
echo  >>needed-list
cc -Wf,-XNg1000 -c -g -I. -I./../include  strdup.c
rm -rf libiberty.a
ar qc libiberty.a    basename.o getopt.o getopt1.o obstack.o spaces.o concat.o
fdmatch.o argv.o strerror.o strsignal.o strdup.o
ranlib libiberty.a
rootme=`pwd` ; export rootme; CC="cc -Wf,-XNg1000 `if [ -f ${rootme}/../gcc/gcc
] ;  then echo -I${rootme}/../gcc/include ;  else echo ; fi`"; export CC;  ./uti
ls/gen-params  >tmp-params.h
ldopen: cannot open dummy.o
nm: Error: cannot open dummy.o
ldopen: cannot open dummy.o
nm: Error: cannot open dummy.o
nm failed to find FUNC in dummy.o!
sh: -1: bad number
*** Error code 1

Stop.
*** Error code 1

Stop.
$
===========================================================

Newsgroups: gnu.g++.lib.bug
From: bothner@cygnus.com
Subject: Re: SunOS shared library version
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 15:08:14 GMT

> Is it possible to produce a shared library version of libg++ (2.2)?

It should be possible.  In the past, we supported libg++ as
a SunOS shared library for one customer, but that support
got dropped in favor on concentrating on getting libg++ more portable.
I will welcome patches that ease bulding of shared libraries
- especially if acompanied by documentation on how to do it!

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.g++.lib.bug
From: adunham@noacl.cs.uno.edu (dunham)
Subject: compiling libg++ on a NeXT
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 10 Oct 1992 04:36:43 GMT

Hello GNU,
  I am trying to use the C++ shipped with a NeXT.  I have not been
able to compile libg++ (a necessary part of C++).  The error
message is
Make:  Don't know how to make /g++-include/std.h.  Stop.
*** Exit 1
Stop.

Any help you can give me on how to install the latest versions of
GNU software that runs on NeXT machines will be much appreciated.

Thanks,
  * AndREa *
  Andrea Dunham  (adunham@cs.uno.edu)

Newsgroups: gnu.g++.lib.bug
From: klamer@mi.el.utwente.NL (Klamer Schutte)
Subject: SunOS shared library version
Organization: University of Twente, BSC-El
Distribution: gnu
Date: Mon, 12 Oct 1992 10:06:01 GMT

Is it possible to produce a shared library version of libg++ (2.2)?
Currently any program using the iostream facility gets so big...

For example the following program:

#include        <iostream.h>

main()
{
        cout << endl;

        return 0;
}

gets the size:

0 klamer@mi7 11:08 6> size a.out
text    data    bss     dec     hex
90112   8192    0       98304   18000

when the same program compiled with sun C++ 2.1, using their shared C++ lib
has the size:

0 klamer@mi7 11:10 9> size a.out
text    data    bss     dec     hex
8192    8192    0       16384   4000

Has compiling as a shared library been tried? Is it succesfull? Is there a
great performance penalty?

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++.lib.bug
From: bothner@cygnus.com
Subject: Re: compiling libg++ on a NeXT
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 11 Oct 1992 06:48:59 GMT

> Make:  Don't know how to make /g++-include/std.h.  Stop.

Some make macro name is undefined (empty).
Study the Makefile.
	--Per


Newsgroups: gnu.groff.bug
From: jjc@jclark.com (James Clark)
Subject: \} at end of line sometimes elicits strange warning (groff -ww)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 12 Oct 1992 08:04:25 GMT

   INPUT FILES:
	   .if 1 \{\
	   .nr x 1 \}

   COMMAND LINE: groff -ww

   DESCRIPTION OF INCORRECT BEHAVIOUR:
	   <standard input>:2: warning: `\}' where number expected

	   Is a warning really called for here?
	   Similarly for `.sp \}', etc.

If you don't want these warnings, you can disable them with
`-Wright-brace'.

`\}' behaves in a rather bizarre way: it disappears much later than
might be expected.  If you use `\}' in a place where a numeric
argument is expected, troff will behave as if an invalid argument had
been supplied rather than as if no argument had been supplied.  This
is true for both GNU troff and traditional troff.  Traditional troff
and GNU troff differ in their treatment of requests that have invalid,
optional arguments: traditional troff sometimes ignores the entire
request, sometimes behaves as if the invalid argument was missing, and
sometimes behaves as if the argument was zero; GNU troff usually
ignores the request (perhaps it would be better if it always treated
an invalid, optional argument as missing.)

For example, this

   .ps 10
   .ps 8
   .if 1 \{\
   .ps \}
   .tm \n(.s

will print `8' not `10'.

These problems can all be avoided by putting the `\}' on a separate
line:

   .if 1 \{\
   .   nr x 1
   .\}

James Clark
jjc@jclark.com


Newsgroups: gnu.groff.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: \} at end of line sometimes elicits strange warning (groff -ww)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 8 Oct 1992 00:20:08 GMT

GROFF VERSION: 1.06

MACHINE: Sun Sparcstation 1

OS: SunOS 4.1.2

COMPILER: gcc 2.2.2

INPUT FILES:
	.if 1 \{\
	.nr x 1 \}

COMMAND LINE: groff -ww

DESCRIPTION OF INCORRECT BEHAVIOUR:
	<standard input>:2: warning: `\}' where number expected

	Is a warning really called for here?
	Similarly for `.sp \}', etc.

Newsgroups: gnu.groff.bug
From: gnulists@ai.mit.edu (GNU Mailing List Maintenance)
Subject: \} at end of line sometimes elicits strange warning (groff -ww)
Reply-To: gnu@prep.ai.mit.edu
Organization: Project GNU, Free Software Foundation,
           675 Mass. Ave., Cambridge, MA  02139, USA   +1 (617) 876-3296
Distribution: gnu
Date: Tue, 13 Oct 1992 05:45:34 GMT

   INPUT FILES:
	   .if 1 \{\
	   .nr x 1 \}

   COMMAND LINE: groff -ww

   DESCRIPTION OF INCORRECT BEHAVIOUR:
	   <standard input>:2: warning: `\}' where number expected

	   Is a warning really called for here?
	   Similarly for `.sp \}', etc.

If you don't want these warnings, you can disable them with
`-Wright-brace'.

`\}' behaves in a rather bizarre way: it disappears much later than
might be expected.  If you use `\}' in a place where a numeric
argument is expected, troff will behave as if an invalid argument had
been supplied rather than as if no argument had been supplied.  This
is true for both GNU troff and traditional troff.  Traditional troff
and GNU troff differ in their treatment of requests that have invalid,
optional arguments: traditional troff sometimes ignores the entire
request, sometimes behaves as if the invalid argument was missing, and
sometimes behaves as if the argument was zero; GNU troff usually
ignores the request (perhaps it would be better if it always treated
an invalid, optional argument as missing.)

For example, this

   .ps 10
   .ps 8
   .if 1 \{\
   .ps \}
   .tm \n(.s

will print `8' not `10'.

These problems can all be avoided by putting the `\}' on a separate
line:

   .if 1 \{\
   .   nr x 1
   .\}

James Clark
jjc@jclark.com



Newsgroups: gnu.groff.bug
From: jjc@jclark.com (James Clark)
Subject: Ultrix man pages with groff
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 07:46:12 GMT

   However, the tmac.an macros for Ultrix
   are very different from groff's version: Ultrix's version
   takes control of the whole page layout and defines some
   macros of which the man pages make essential use.

The file tmac/man.ultrix in the groff distribution provides
definitions of a couple of macros peculiar to Ultrix.  This would need
to be installed as /usr/local/lib/groff/tmac/man.local.

If you still have problems, I suggest you submit a complete bug
report.  See the file BUG-REPORT in the groff distribution.

James Clark
jjc@jclark.com

Newsgroups: gnu.ghostscript.bug
From: druthven@us.oracle.COM (David Ruthven)
Subject: Re: multiple bits per pixel on X?
Organization: Oracle Corp., Redwood Shores CA
Distribution: gnu
Date: Fri, 16 Oct 1992 13:15:40 GMT

Is it possible to produce high quality text when using ppmraw or some other
image format?  We want to convert postscript documents into image files (1
per page) for subsequent display using a standard image viewer.

Regards

David
_______________________________________________________________________________
David Ruthven, Unix Post Sales Support, Oracle UK, The Ring, Bracknell RG12 1BW
Email: druthven@uk.oracle.com      Tel: +44.344.415322      Fax: +44.344.415100

Newsgroups: gnu.ghostscript.bug
From: eichi@forty2.physik.unizh.ch (Stefan Eichenberger)
Subject: Problems with ghostscript 2.5.x
Organization: Physics Institute, University of Zuerich, Switzerland
Distribution: gnu
Date: Mon, 12 Oct 1992 10:24:03 GMT

I noticed two problems in ghostscript releases 2.5.x! Sorry for my ignorance
if they have been posted here long ago and I missed them...

1. Problem with bj10e printer driver
   I had no luck in producing any text output with this driver in 360 dpi
   resolution. It works fine with 180 dpi (-r180) and on the golfer.ps
   file, which does not include any text. However, even a simple *.ps file
   which needs loading just two fonts produces garbage output:
   One recognizes the line structure of the text, but each line is sort
   of smeard out and just a gray-shaded sort of thing across the page.
   No problem with ghostscript 2.4 however.
2. Postscript language problem
   A *.ps file created with WordPerfect 5.1 for DOS and the HP Laserjet III
   postscript driver run just fine under ghostscript 2.4 but produces an
   error message under 2.5.x. The WP-file used was the Printer.tst file which
   comes with the WP distribution. The complaint is made when something should
   be printed shadowed and PaintType is somehow causing the problem. I can
   provide the *.ps file, but have not enough knowledge myself to determine
   whether the postscript code itself is correct.

Both problems were reproduced on ghostscript 2.5, 2.5.1 and 2.5.2 on a 386SX
and 486-50 PC with 5 and 8 MByte of RAM under DOS 5.0 using either of the
executables: gs.exe, gs386.exe and gs386win.exe (under windows 3.1). I used 
a generic autoexec.bat and config.sys and tried various DIP switch settings on
the bj10e printer. I haven't checked ghostscript 2.4.1 and 2.4.2


-- 
----------------------------------------------------------------------------
iNet:      eichi@physik.unizh.ch                 Stefan Eichenberger
UUCP:      ...mcsun!chx400!forty2!eichi          Physics Institut
BITNET:    K807817@CZHRZU1A                      University of Zurich

Newsgroups: gnu.ghostscript.bug
From: dipak@radiant.NOname (Dipak Chowdhury)
Subject: Ghostscript for windows
Reply-To: dipak@radiant.noname
Organization: Applied Physiscs, Yale University
Distribution: gnu
Date: Wed, 14 Oct 1992 19:29:11 GMT

I am having problem running Ghostscript 2.5.2 under Windows 3.1. It opens a window and then
it dies. Is there any especial setup in the win.ini file that I need to do? Did anyond have the same
problem? Thanks in advance.
		                              dipak@radiant.eng.yale.edu



Newsgroups: gnu.ghostscript.bug
From: max@nj.nec.com (Maximilian Ott)
Subject: Device driver for HP 7600 plotter??
Organization: C&C Research Labs, NEC USA, Princeton, N.J.
Distribution: gnu
Date: Wed, 14 Oct 1992 01:56:02 GMT

Has anyone attempted to write a device driver for the HP 7600 plotter.
It has raster graphics but I'm not sure if one will blow up
ghostscript as uncompressed raster images can easily reach 150MB for a
single color.

Of course the best port would attempt to convert a ps file into a list
of vectors. Has anyone tried that. Which graphics primitives will be
finally rasterized and where does this happen?

Any help would be greatly appreciated.

Regards,

max
-- 
Max Ott                 max@ccrl.nj.nec.com         phone: (609)951-2469
NEC C&C Research        Princeton, NJ, 08540        fax:   (609)951-2499
From: ulrich@galki.toppoint.DE (Ulrich Gall)
Newsgroups: gnu.ghostscript.bug
Subject: Ghostscript fonts look bad
Date: 16 Oct 92 12:00:57 GMT
Distribution: gnu
Organization: private UUCP site, Kiel, Germany

A fews weeks ago, I installed GS 2.4 and fonts from the SIMTEL CD. I really
like the package - however, I don't like the fonts.

The SIMTEL fonts look just terrible.

I converted fonts from another source, they were much better, but some of the
letters were REALLY strange.

Is this a GS bug? Is it better in GS 2.5?

Which fonts are the best to use with GS?

Thanks a lot,

Ulrich

[A note to the moderator: I posted 2 requests in this group about a week ago,
and they never appeared in the net. Please send me a message what ever
happened to them since I'm starting to worry if there is something wrong on my
system. Thanks!]
Ulrich Gall, Seebrooksberg 2, W-2300 Klausdorf, Germany
Tel.: +49-431-790292, EMail: ulrich@galki.toppoint.de


Ulrich Gall, Seebrooksberg 2, W-2300 Klausdorf, Germany
Tel.: +49-431-790292, EMail: ulrich@galki.toppoint.de
Newsgroups: gnu.ghostscript.bug
From: wkn@leland.stanford.edu (Ken Neighbors)
Subject: Re: Why doesn't gs386 support DPMI? (It does!)
Keywords: DOS, DPMI
Organization: DSG, Stanford University, CA 94305, USA
Distribution: gnu
Date: Wed, 14 Oct 1992 05:49:49 GMT

In article <1992Oct13.054447.12316@leland.Stanford.EDU> wkn@leland.Stanford.EDU (Ken Neighbors) writes:
>I'm getting tired of all the programs that use some proprietary
>memory manager that's incompatible with Dos Protected Mode Interface.

I griped too soon.  Apparently, the AUTO setting for DPMI_DOS_API is not
sufficient.  You have to set it to ENABLED.  Hope this helps someone else.
(This is in OS/2 2.0, settings for a DOS session.)

Ken

Newsgroups: gnu.ghostscript.bug