HDTenEightyP/NetNews huggingface dataset:
From: dougm@cs.rice.edu (Doug Moore)
Subject: bottomless recursion in stream output
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 03:15:05 GMT

(previous posted inadvertantly to bug-g++)

Consider the following program:
---- cut here ---------
#include <iostream.h>

main()
{
  for(int i = 0 ; i < 396 ; i++)
    {
      cerr << "i = " << i << "\n";
      cerr << "AAAAAAAAAAAA\n";
    }
}
---- cut here ---------

Seems innocent, doesn't it?

Well, if one compiles it with g++2.1*, using a version of libg++-2.0
compiled with g++2.1* on a sparc2, sunos 4.1, Sun loader, collect2,
and one runs it, it dies with a bottomless recursion.  The last thing printed is

i = 395

and the death occurs in the attempt to print the newline at the end of
that line.  Significantly, that newline happens to be the 8193rd
character of output produced by this program.

The bottomless recursion has the following (partial) backtrace as it
begins its descent into the void:

#0  filebuf::overflow (this=0x1a5f8, c=10) at filebuf.C:213
#1  0x11674 in streambuf::sputc (this=0x1a5f8, c=10)
    at /marsh/comp212/gnu/libg++-2.0/libg++/iostream/streambuf.h:278
#2  0x5718 in filebuf::overflow (this=0x1a5f8, c=10) at filebuf.C:261
#3  0x11674 in streambuf::sputc (this=0x1a5f8, c=10)
    at /marsh/comp212/gnu/libg++-2.0/libg++/iostream/streambuf.h:278
#4  0x5718 in filebuf::overflow (this=0x1a5f8, c=10) at filebuf.C:261
#5  0x1199c in streambuf::sputn (this=0x1a5f8, s=0x2299 "", n=1) at streambuf.C:46
#6  0x68d0 in filebuf::sputn (this=0x1a5f8, s=0x2298 "\n", n=1) at filebuf.C:546
#7  0xa98c in operator<< (stream=@0x1a694, s=0x2298 "\n") at iostream.C:506
#8  0x2310 in main () at bug.cc:7

and here is the (routine) compiler output from compiling the program:

c++ -g -Wall -v bug.cc
Reading specs from /marsh/comp212/lib/gcc-lib/sun4/2.1/specs
gcc version 2.1
 /marsh/comp212/lib/gcc-lib/sun4/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 -g -Wall bug.cc /usr/tmp/cca25242.i
GNU CPP version 2.1 (sparc)
 /marsh/comp212/lib/gcc-lib/sun4/2.1/cc1plus /usr/tmp/cca25242.i -quiet -dumpbase bug.cc -g -Wall -version -o /usr/tmp/cca25242.s
GNU C++ version 2.1 (sparc) compiled by GNU C version 2.1.
 as -o bug.o /usr/tmp/cca25242.s
 /marsh/comp212/lib/gcc-lib/sun4/2.1/ld -e start -dc -dp /lib/crt0.o -L/marsh/comp212/lib/gcc-lib/sun4/2.1/ -L/marsh/comp212/lib/ bug.o -lg++ -lm -lgcc -lc -lg -lgcc

Compilation finished at Mon Apr 13 17:48:29


I wish I could suggest a patch, but the code is too opaque for me.

Doug Moore (dougm@cs.rice.edu)

* with Tiemann and Stump patches applied

Newsgroups: gnu.g++.lib.bug
From: wr@asoftus.UUCP (Wolfgang Rohdewald)
Subject: bug report GC2.1
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 14 Apr 1992 19:53:04 GMT

Hello ! I know this is not the correct mail address, but I did not find
any other - there is no email address in the gcc2.1 release. Please tell
me the correct address and pass this bug report on !

I installed GCC2.1 on SCO ODT 1.1, with configure ibm-i386-sco and no changes
  whatsoever to any file. The installation ran quite smoothly.

My two bugs:

1.  using the option -save-temps always results in a core dump at different
    places, but always in the init phase of gcc.

2.  I extracted the following from the Booch C++ library which makes heavy
    use of templates. But the use of their template preprocessor is just
    awkward. I think you should ask them for a free copy since this will
    really test your template code.


	template<class Item>class Node {};
	typedef Node<Item> NI;			
    // above gives `Item' undeclared, outside of functions
	template<class Item>Node<Item>::Node(Node* next) {}
    // above works
	template<class Item>Node<Item>::Node(Node<Item>* next) {}
    // above gives parse error before '>'


-- 
Wolfgang Rohdewald		Algosoft USA Inc.
125 Swinging Bridge Lane	Phone : +1-303-927-8041
P.O.Box 556      		Fax   : +1-303-927-9999
BASALT, Colorado 81621		E-Mail: uunet!asoftus!wr
---

Newsgroups: gnu.g++.lib.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: iostream bug/fix on Sequent Symmetry
Organization: Harvey Mudd College
Distribution: gnu
Date: Sat, 28 Mar 1992 23:24:43 GMT

sbufvscan.C uses strol to read in integers, but the Sequent doesn't have
strtol in libc.

Since the strtoul which comes with iostream checks for unary minus and seems
to process it correctly, just changing all references to strtol into
references to strtoul works fine.

Diffs:

*** sbufvscan.C~	Sat Mar 28 15:22:30 1992
--- sbufvscan.C	Sat Mar 28 15:23:00 1992
***************
*** 178,184
  			/* FALLTHROUGH */
  		case 'd':
  			c = CT_INT;
! 			ccfn = (u_long (*)(const char, char**, int))strtol;
  			base = 10;
  			break;
  

--- 178,184 -----
  			/* FALLTHROUGH */
  		case 'd':
  			c = CT_INT;
! 			ccfn = strtoul;
  			base = 10;
  			break;
  
***************
*** 184,190
  
  		case 'i':
  			c = CT_INT;
! 			ccfn = (u_long (*)(const char, char**, int))strtol;
  			base = 0;
  			break;
  

--- 184,190 -----
  
  		case 'i':
  			c = CT_INT;
! 			ccfn = strtoul;
  			base = 0;
  			break;
  
***************
*** 266,272
  			if (isupper(c))
  				flags |= LONG;
  			c = CT_INT;
! 			ccfn = (u_long (*)(const char, char**, int))strtol;
  			base = 10;
  			break;
  		}

--- 266,272 -----
  			if (isupper(c))
  				flags |= LONG;
  			c = CT_INT;
! 		        ccfn = strtoul;
  			base = 10;
  			break;
  		}




Newsgroups: gnu.g++.lib.bug
From: Ron.Sommeling@cwi.NL (Ron Sommeling)
Subject: bug in Integer.cc + fix
Organization: CWI, Amsterdam
Distribution: gnu
Date: Thu, 16 Apr 1992 11:18:55 GMT

There is a bug in the function
	istream& operator >> (istream& s, Integer& y)
of the GNU g++ library libg++-2.0.
The following program gives a segmentation fault when fed with the input
	0 0
(SPARCstation 1, SunOS 4.1.1, g++ 2.1, libg++-2.0)
	#include <iostream.h>
	#include <Integer.h>

	main() {
		Integer a, b;
		cin >> a >> b;
		cout << "a = " << a << ", b = " << b << endl;
	}
Below is a context diff to fix the bug.

Ron Sommeling <Ron.Sommeling@cwi.nl>

*** Integer.cc.orig	Fri Mar  6 08:57:52 1992
--- Integer.cc	Thu Apr 16 13:10:50 1992
***************
*** 2326,2335 ****
        else
          break;
      }
!     else if (!know_base & !got_one && ch == '0')
!       base = 8;
!     else if (!know_base & !got_one && base == 8 && (ch == 'X' || ch == 'x'))
!       base = 16;
      else if (base == 8)
      {
        if (ch >= '0' && ch <= '7')
--- 2326,2337 ----
        else
          break;
      }
!     else if (!know_base & !got_one && ch == '0') {
!       base = 8; got_one = 2;
!     }
!     else if (gotone == 2 && (ch == 'X' || ch == 'x')) {
!       base = 16; got_one = 0; know_base = 1;
!     }
      else if (base == 8)
      {
        if (ch >= '0' && ch <= '7')

Newsgroups: gnu.g++.lib.bug
From: burton@heurikon.UUCP (Kevin Burton)
Subject: libg++-2.0 linking problem (vt$filebuf)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 8 Apr 1992 18:34:12 GMT

Compiler: gcc/g++ 2.1 using gnu-coff patches for gas 1.38
OS: System Vr3
CPU: m68k

I successfully compiled libg++-2.0 after making bcopy.cc and the declaration
for libgxx_bcopy match. I now try to link test_h in the test directory and I
get:

undefined			first referenced
 symbol				    in file
__vt$filebuf			    ../libg++.a

I tracked it down to iostream in the file stdstrbufs.C and just to see if it
would make a difference I tried defining NO_DOLLAR_IN_LABEL. Then I get:

undefined			first referenced
 symbol				    in file
__vt.filebuf			    ../libg++.a

Does anyone know where this symbol is defined or should be defined ?

Thanks.


--
Kevin Burton                                mail: burton@inno.heurikon.com
Innovision Corporation                      uucp: heurikon!inno!burton
8000 Excelsior Drive Suite #304, Madison WI 53717 at&t: 608/831-4441

Newsgroups: gnu.g++.lib.bug
From: breure@iti.tno.NL (Frank Breure .)
Subject: core dump if writing more than 8192 bytes to cerr
Reply-To: breure@iti.tno.nl
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 16 Apr 1992 15:03:33 GMT

Hello,

I noticed the following bug:

If writing more than 8192 characters to cerr, doesn't matter in how
many different small chunks, you get a segmentation violation.
Gdb says it's in filebuf:overflow() or streambuf::pptr() this depends
whether it is compiled with -g.

I saw this problem on both installations I have:
using:

libg++ version 2.0
gcc 2.0

on:
Sun Sparc station with SunOs 4.1.1
DECstation 5000 with Ultrix 4.2

I made the following patch which works for me, but I don't think
I really fixed the bug. 
It is probably only a workaround.


------ begin of patch -----
*** libg++/iostream/stdstreams.C	Thu Apr 16 12:04:32 1992
--- libg++/iostream/stdstreams.C~	Thu Apr  2 16:02:12 1992
***************
*** 62,72 ****
   (streambuf*)&SBUF, TIE, 0, ios::dont_close|ios::skipws|EXTRA_FLAGS, ' ', 0, 6
  
  STR_NAME(_fake_ostream, cout)  = { STD_STR(_cout_sbuf, NULL, 0) };
- // changed by Frank Breure because of an annoying bug in writing to
- // cerr which made it impossible to write more than 8192 (== ios::unitbuf)
- // to cerr !!
  STR_NAME(_fake_ostream, cerr) =
!   { STD_STR(_cerr_sbuf, (ostream*)&cout, 0) };
  STR_NAME(_fake_istream, cin)  = { STD_STR(_cin_sbuf,  (ostream*)&cout, 0) };
  
  /* Only for (partial) compatibility with AT&T's library. */
--- 62,69 ----
   (streambuf*)&SBUF, TIE, 0, ios::dont_close|ios::skipws|EXTRA_FLAGS, ' ', 0, 6
  
  STR_NAME(_fake_ostream, cout)  = { STD_STR(_cout_sbuf, NULL, 0) };
  STR_NAME(_fake_ostream, cerr) =
!   { STD_STR(_cerr_sbuf, (ostream*)&cout, ios::unitbuf) };
  STR_NAME(_fake_istream, cin)  = { STD_STR(_cin_sbuf,  (ostream*)&cout, 0) };
  
  /* Only for (partial) compatibility with AT&T's library. */
---- end of patch ----

I hope this is of some help for you,

--
Frank Breure                                       (breure@iti.tno.nl)
TNO Institute of Applied Computer Science       Delft, The Netherlands
----------------------------------------------------------------------
My opinions may be subject to change without notice.

Newsgroups: gnu.g++.lib.bug
From: allan@mct.UUCP ( System Guru)
Subject: Re: Failed test-install in libg++-2.0 if compiled with gcc-2.1
Organization: MCT Ltd., Malvern, England
Distribution: gnu
Date: Wed, 8 Apr 1992 11:04:37 GMT

In article <9203312049.AA15699@ori.cadlab.de> joost@cadlab.uni-paderborn.de writes:
>Due to the fact that the creation of static (and some local) objects has
>changed greatly, the target 'install' fails in the directory 'test-install'.
>
>In gcc-2.0 (and cfront, I believe) the proper constructor (in this case
>Foo(char*)) was called with 'this' = <address of static object>. Now, the
>'proper' constructor is called for an local (stack) address *and* afterwards
>the real static object is created by calling the copy-constructor, taking
>'this' the real static address and as second arg the 'dummy' object created on
>the stack. Afterwards the destructor is called for the local object.
>
>So, it does not look wrong, but awkward. Is this intended?

I would echo the above and add the following wrt the rest of the
test-install process.  Two other progams are made, a and b, and both
run.  A produces the output "Hello world!"; b produces:

Hello  world!
Errno:  1

There is no indication of the expected value of errno - is 1 correct??
I would also add that the the current documentation with libg++-2.0
seems to be out of sync, ie. protions of it relate to earlier versions
of the library and as such can lead to confusion.  Having said this, I
now have what I believe to be an installed and working version of
libg++-2.0 installed - I will start using it in anger over the next
few days.  My machine specs are:

	Processor: sparc  Manfacturer: sun  OS: sunos4.1.1

Regards,
Allan Clearwaters
MCT Ltd., 62 Albert Rd. Nortn, Malvern, Worcs. WR14 2TL, England
allan@mct.uucp

Newsgroups: gnu.groff.bug
From: sjg@melb.bull.oz.AU (Simon J Gerraty)
Subject: Re: rename comment_info.proc to comment_info.pmf
Organization: Bull HN Information Systems Australia
Distribution: gnu
Date: Wed, 8 Apr 1992 00:20:11 GMT

In <199204070034.AA19054@taureau.melb.bull.oz.au> sjg@melb.bull.oz.AU (Simon J Gerraty) writes:

>DESCRIPTION OF INCORRECT BEHAVIOUR:
>This same compiler and library compile groff ok on sun386 and
>sun4c.  On the Bull DPX/2, then name proc in struct comment_info
>appears to conflict with _something_ in one of the system header
>files - though I was unable to track it down.  The compilation
>of ps/psrm.c fails with initialization between incompatible
>pointer types.


>SUGGESTED FIX:
>this patch changes the name from proc to pmf

Forget it.  It turns out the problem is that one of the system
headers  contains a struct declaration like:

struct foo
{
  struct proc *pfoo;
} ;

This seems to polute the name space, causing the struct
comment_info in ps/psrm.c to lose its proc member!
I don't know whether this is a gcc bug or a C++ feature, but if
it is a feature of C++ then it seems it would be nearly
impossible to write portable code.
-- 
Simon J. Gerraty		<sjg@melb.bull.oz.au> (Work)
				<sjg@zen.void.oz.au>  (Home)

#include <disclaimer,_witty_comment>

Newsgroups: gnu.groff.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: missing macros in groff tmac.an
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 13 Apr 1992 00:33:45 GMT

Tom Quinn (trq@dionysos.thphys.ox.ac.uk) proposes the following addition to
tmac.an:

	.ie n \{\
	.       ds lq \&"\"
	.       ds rq \&"\"
	.\}
	.el \{\
	.       ds rq ''
	.       ds lq ``
	.\}

Let me propose the following simpler addition instead.
This should generate better-looking output, too.

	.ds lq \(lq
	.ds rq \(rq

You might consider similar patches to the other groff macro packages
that define double-quote, e.g.:

diff old/macros/doc-ditroff new/macros/doc-ditroff
98,99c98,105
< .ds Lq \&``
< .ds Rq \&''
---
> .ie "\(lq"" \{\
> .	ds Lq \&``
> .	ds Rq \&''
> .\}
> .el \{\
> .	ds Lq \(lq
> .	ds Rq \(rq
> .\}
diff old/macros/tmac.s new/macros/tmac.s
1728,1729c1728,1729
< .ds Q \)``\)
< .ds U \)''\)
---
> .ds Q \(lq
> .ds U \(rq

Newsgroups: gnu.groff.bug
From: jjc@jclark.COM (James Clark)
Subject: .in has problems in the -mgs macros...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 10:17:17 GMT

   .in doesn't always indent with the -mgs macros...Here's a sample -- with
   fortran, .in doesn't do anything...

The -mgs macros take control of indentation.  When you're using a
macro package, you should always change indentation using the
mechanisms provided by that macro package.

James Clark
jjc@jclark.com

Newsgroups: gnu.groff.bug
From: sjg@melb.bull.oz.AU (Simon J Gerraty)
Subject: rename comment_info.proc to comment_info.pmf
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 7 Apr 1992 20:34:57 GMT

GROFF VERSION:
1.05

MACHINE:
Bull DPX/2 340

OS:
B.O.S. 2.00.45	(System V 3.1 + POSIX)

COMPILER:
gcc-2.1, libg++-2.0

INPUT FILES: ps/psrm.c

COMMAND LINE:
N/A

DESCRIPTION OF INCORRECT BEHAVIOUR:
This same compiler and library compile groff ok on sun386 and
sun4c.  On the Bull DPX/2, then name proc in struct comment_info
appears to conflict with _something_ in one of the system header
files - though I was unable to track it down.  The compilation
of ps/psrm.c fails with initialization between incompatible
pointer types.


SUGGESTED FIX:
this patch changes the name from proc to pmf

*** ps/psrm.c.~5~	Mon Apr  6 18:55:08 1992
--- ps/psrm.c	Tue Apr  7 10:16:48 1992
***************
*** 875,881 ****
  				/ sizeof(header_comment_table[0]));
    struct comment_info {
      const char *name;
!     int (resource_manager::*proc)(const char *, int, FILE *, FILE *);
    };
  
    static comment_info comment_table[] = {
--- 875,881 ----
  				/ sizeof(header_comment_table[0]));
    struct comment_info {
      const char *name;
!     int (resource_manager::*pmf)(const char *, int, FILE *, FILE *);
    };
  
    static comment_info comment_table[] = {
***************
*** 935,941 ****
  	  for (int i = 0; i < NCOMMENTS; i++)
  	    if (ptr = matches_comment(buf, comment_table[i].name)) {
  	      copy_this_line
! 		= (this->*(comment_table[i].proc))(ptr, rank, fp, outfp);
  	      break;
  	    }
  	  if (i >= NCOMMENTS && in_header) {
--- 935,941 ----
  	  for (int i = 0; i < NCOMMENTS; i++)
  	    if (ptr = matches_comment(buf, comment_table[i].name)) {
  	      copy_this_line
! 		= (this->*(comment_table[i].pmf))(ptr, rank, fp, outfp);
  	      break;
  	    }
  	  if (i >= NCOMMENTS && in_header) {

Newsgroups: gnu.groff.bug
From: volker@sfb256.iam.uni-bonn.de ( Volker A. Brandt )
Subject: Does anyone have a groff device description for NEC 24 dot printers?
Organization: Applied Math, University of Bonn, Germany
Distribution: gnu
Date: Wed, 8 Apr 1992 15:13:14 GMT

Hello all!

   I'm looking for a groff device description for a NEC P6+ (aka P5200) printer.
I'd like to be able to print *roff output on my P7+ in one of the proportional
fonts (Times or Helvetica).  I guess an Epson printer description would do as
well.

   I have the width tables and I could probably figure it out myself, but I don't
have the time to do it.

   Thanks in advance -- Volker

-- 
----------------------------------------------------------------------------
Bitnet:   UNM409@DBNRHRZ1                              Volker A. Brandt
UUCP:     ...!unido!DBNRHRZ1.bitnet!unm409             Angewandte Mathematik
Internet: volker@sfb256.iam.uni-bonn.de                (Bonn, Germany)

Newsgroups: gnu.groff.bug
From: trq@dionysos.thphys.ox.ac.uk
Subject: missing macros in groff tmac.an
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 09:29:16 GMT

GROFF VERSION:
1.05

MACHINE:
Decstation 2100

OS:
Ultrix 4.2

COMPILER:
g++ 2.1

INPUT FILES:
The following is the manual page for "yes" on Ultrix 4.2:
.\" SCCSID: @(#)yes.1   8.1     9/11/90
.TH yes 1 
.SH Name
yes \- be repetitively affirmative
.SH Syntax
.B yes
[\|\fIarg\fR\|]
.SH Description
.NXR "yes command"
The
.PN yes
command repeatedly outputs \*(lqy\*(rq.  If
.I arg
is given, that argument is output repeatedly.  
Terminate the 
.PN yes 
command with
.CT C .

COMMAND LINE:
groff -Tascii -man yes.1

DESCRIPTION OF INCORRECT BEHAVIOUR:
The tmac.an file does not define the .PN macro (for pathnames), the
.CT macro (for control characters) or the lq and rq characters (left
and right quotes) which are used in the Ultrix man pages.  The result
is the arguments of these macros don't get printed.

SUGGESTED FIX:
The following patch to macro/tmac.an defines the missing macros.
===================================================================
RCS file: RCS/tmac.an,v
retrieving revision 1.1
diff -c -r1.1 tmac.an
*** 1.1	1992/04/09 16:12:27
--- tmac.an	1992/04/09 16:21:51
***************
*** 315,320 ****
--- 315,334 ----
  .nr an-prevailing-indent \\n[an-saved-prevailing-indent\\n[an-level]]
  .in \\n[an-margin]u
  ..
+ .de PN
+ \fI\|\\$1\|\fP
+ ..
+ .de CT          \" Control character
+ \s-2<\|CTRL\|/\|\\$1\|>\s+2
+ ..
+ .ie n \{\
+ .       ds lq \&"\"
+ .       ds rq \&"\"
+ .\}
+ .el \{\
+ .       ds rq ''
+ .       ds lq ``
+ .\}
  .ds S \s[\\n[PS]]
  .ie c\[rg] .ds R \[rg]
  .el .ds R (Reg.)
------
Tom Quinn        Theoretical Physics, University of Oxford
Internet: 	 trq@dionysos.thphys.ox.ac.uk
JANET:    	 trq@uk.ac.ox.astro
Phone:		 44-865-273956

Newsgroups: gnu.ghostscript.bug
From: debra@wsinis07.info.win.tue.nl (Paul De Bra)
Subject: Re: Looking for driver....
Reply-To: debra@info.win.tue.nl
Organization: Eindhoven University of Technology, the Netherlands
Distribution: gnu
Date: Mon, 6 Apr 1992 10:07:12 GMT

In article <1992Mar31.202614.7059@unixg.ubc.ca> twong@civil.ubc.ca (Thomas Wong) writes:
>I'm looking for a driver for a friend who has an Okidata ML-390 and he
>wishes to print in 360x360 mode. He can emulate an Epson but the Epson
>driver doesn't have a 360x360 mode. Is there a place or a ftp site where
>ghostscript variations for msdos is stored where I can look for perhaps
>an executable with just such a driver? Has anyone created an executable
>for this printer already? Thank you.

I have a Nec P5 printer (24-pins) and an Epson MX100 (9-pins, very old).
The ghostscript epson driver cannot be used with either of these.

Which is why I added a 360x360 dpi driver for the Nec P5 (should also
work with P6, P7, P9 and compatibles) and a 120x216 dpi driver for the
Epson. (A 240x216 dpi mode is trivial to add but the MX100 doesn't have
240x216 dpi)

I have added these as 2 extra functions to the Epson driver and will
send my updates to the ghostscript authors.

Paul.

Newsgroups: gnu.ghostscript.bug
From: ghost@aladdin.COM (L. Peter Deutsch)
Subject: Re: More HP/UX 7.05 gs2.4 problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 08:35:54 GMT

Re <9204100452.AA06448@raisin-nut>
<9204091358.AA28371@hpwarga.wal.hp.com>:

> Subject: Re: More HP/UX 7.05 gs2.4 problems

> Here is a summary of the problems I encountered when compiling the
> GhostScript distribution on an HP 9000/720:

Which version?

> 1 - gdevx.c:
>    Problem: "attempt to redefine" error
>    Solution: stat() macro expansions must be expanded by hand

These macros do not appear in the 2.4 distribution.  You must have
somehow wound up with a pre-release version of 2.4.

> 4 - gdevmem1.c: 457
>    Problem: operands have incompatible types
>    Solution: cast both to int

As I noted in a previous message, I believe both K&R and the ANSI
standard allow what is in the code.

L. Peter Deutsch :: Aladdin Enterprises :: P.O. box 60264, Palo Alto, CA 94306
ghost@aladdin.com, ...decwrl!aladdin!ghost ; 415-322-0103 8-9 AM M-F/msg
	    "Implementation is the sincerest form of flattery."


Newsgroups: gnu.ghostscript.bug
From: ghost@aladdin.COM (L. Peter Deutsch)
Subject: \ vs. / in command line file names
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 10 Apr 1992 14:31:07 GMT

In a recent posting, Xiaofei Wang observed that Ghostscript didn't
properly handle file names on the command line containing \, such as

		gs c:\foo\bar\xyz.ps

Someone else pointed out that

		gs c:/foo/bar/xyz.ps

does work properly.  This is true.  However, not handling the former
properly is indeed a bug in Ghostscript.  I know what causes it, and
I'll fix it in 2.4.1.

L. Peter Deutsch :: Aladdin Enterprises :: P.O. box 60264, Palo Alto, CA 94306
ghost@aladdin.com, ...decwrl!aladdin!ghost ; 415-322-0103 8-9 AM M-F/msg
	    "Implementation is the sincerest form of flattery."


Newsgroups: gnu.ghostscript.bug
From: gilligan@bldrdoc.GOV (Jonathan M. Gilligan)
Subject: Dumb question: gs 2.4 chokes on .pfb's
Organization: National Institute of Standards and Technology
Distribution: gnu
Date: Thu, 9 Apr 1992 01:27:47 GMT

This is probably an RTFM, but I can't find anything in TFM that
addresses it. Please help. When I try to load a .pfb file (like
Adobe's por_____.pfb (palatino-roman)) gs complains with a screenfull
of numbers (0's and 3's) and a complaint beginning ``/undefined'' If
it would help, I can try to capture the output and post it, but this
must be a simple problem. I'm using the gs24 binary from
prep.ai.mit.edu on an MSDOS machine (ZEOS 386-25, MS-DOS 4, QEMM).  If
I use pfbtopfa to make the font a .pfa font, I get similar errors.
I also can't run pfbtogs.ps. What might I be doing wrong?

---Jon
-- 
------------------------------------------------------------------------------
Jonathan M. Gilligan            National Institute of Standards and Technology
				Boulder, Colorado, USA
Disclaimer --- The government probably disagrees with my opinions.

Newsgroups: gnu.ghostscript.bug