NetNews Usenet Archive 1992 #31/NN_1992_31.iso/spool/gnu/utils/bug/2284

Text File | 1992-12-31 | 5.2 KB | 210 lines

Newsgroups: gnu.utils.bug
Path: sparky!uunet!cis.ohio-state.edu!amsg.ARnet.COM!robertl
From: [e-mail] (Robert Lipe)
Subject: Screen 3.2b fixes for SCO and MIPS
Message-ID: <9212310327.AA06614@raisin-nut>
Sender: [e-mail]
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Dec 1992 03:29:46 GMT
Approved: [e-mail]
Lines: 197

Some notes and comments about screen 3.2b on SCO UNIX 3.2v4.0 and
on RISCOS 4.52b2.

...minor whining....

SCO Defines M_XENIX, but already has it's own typdefs for pid_t,
gid_t, and uid_t.  This means 166-169 screen.h fail becuase
they're re-typedeffing those values.  I just commented them out.

Something about the TIOCPKT handlers in RISC/OS 4.52b2 must not
be right.  If I turn that code off, screen works on it.  I just
added an #undef PIOCPKT at line 85 of screen.h  My days of 4.52b2
are numbered - MIPS has been promising me 5.0.1 "any day now"
since October (sigh).   Another screen user on 4.52b2 has seen
this same behaviour.

...and the biggie....

While I won't apologize or try to rationalize it, SCO UNIX 3.2v4
with SCO TCP/IP 1.2 installed throws screen 3.2-3.2b an
unexpected curve.

SCO includes one set of pseudo devices with the core OS for
things like their mscreen facility and the mouse driver (the vty
driver).  When you install TCP/IP 1.2, you get another set of
pseudo-devices for the networking facilities. (the mpt and spt
drivers).   While either of these devices both work with screen,
it by default will grab the ones from the vty driver.  This means
by default, screen can only control the 8 vty devices.  If you've
done a mkdev ptty after TCP/IP was installed, you raised the number
of devices in the mpt/spt pair.  What this means in my case was
that, while I had 40 pseudos (mpt/spt), screen complained that it couldn't
open them.

Since the naming of the devices differs (vty is ttyp0[1-8], mpt/spt
is ttyp[0-9] ttyp[1-9][0-9]) I wimped out and took the patch of
least resistance.  I convinced screen to use ttyp in the mask and
rip through the pseudo's 10 and up.

It works.  A better solution for SCO would be to sprintf the
decimal number with and without leading zero.    If you dudes
have beta sights running screen, I'll help you any way I can to
make these changes work with and without TCP/ip and  on the
various combinations of  OS versions and TCP/IP versions.

Thanx for an excellent product!
Robert Lipe,
Sr. Software Engr,
Arnet Corp.

--------------------- changes ---------------------------------------

Diffs to Makefile
    Turn on SCO specific code

28c28
< CFLAGS =  -DSCO=1
---
> CFLAGS =

Diffs to config.h
    SCO with TCP/IP installed uses names in the form ttyp[0-9][0-9]

335,339d333
<
< #ifdef SCO
< #define PTY_FIRST_CHARS "0123456789"
< #define PTY_SECOND_CHARS "0123456789"
< #endif

Diffs to screen.c
    SCO with TCP/IP installed uses names in the form ttyp[0-9][0-9]


230,233c229
< #if SCO
< static char PtyProto[] = "/dev/ptypXY";
< static char TtyProto[] = "/dev/ttypXY";
< #else
---
>
243d238
< #endif /* SCO */

From [e-mail] Wed Dec 30 10:42:21 1992
Return-Path: <[e-mail]>
Received: from daisy.ee.und.ac.za by life.ai.mit.edu (4.1/AI-4.10) id AA05145; Wed, 30 Dec 92 10:41:59 EST
Received: from proxima.Alt.ZA (nuustak.UUCP (user proxima)) by
    daisy.ee.und.ac.za (smail3.1.22+apb920812#178) with uucp-bsmtp id
    m0n75YJ-0000NSC; Wed, 30 Dec 1992 10:41:47 -0500 (EST)
Received: by proxima.ALT.ZA (Smail3.1.28.1 #3)
    id m0n75ly-0000D3C; Wed, 30 Dec 92 15:55 GMT
Message-Id: <[e-mail]>
From: [e-mail] (Lucio de Re)
Subject: G++ exception handling
To: [e-mail]
Date: Wed, 30 Dec 1992 15:55:46 +0000 (GMT)
Reply-To: [e-mail] (Lucio de Re)
X-Mailer: ELM [version 2.4 PL13]
Content-Type: text
Content-Length: 1461

Hi,

the following program:

>
> #include    <stdio.h>
>
> x()
> {
>     try
>     {
>         fprintf (stderr, "fred\n");
>         throw "haloo";
>     }
>     catch (char *p)
>     {
>         fprintf (stderr, p);
>     }
> }
>
> main ()
> {
>     x();
> }
>

when compiled as follows:

> g++ -fhandle-exceptions -c prog.C

or

> g++ -fansi-exceptions -c prog.C

produces the following:

> prog.C: In function `int  x ()':
> prog.C:6: Internal compiler error.
> prog.C:6: Please report this to `[e-mail]'.

I'm using the binary files for the AT&T 3B2 uploaded by Greg Gulik.

It is g++ version 2.3.2 and I'm not sure of the significance of the
specs file, so I include it below:

> *asm:
>
>
> *asm_final:
>
>
> *cpp:
>
>
> *cc1:
>
>
> *cc1plus:
>
>
> *endfile:
> crtn.o%s
>
> *link:
>
>
> *lib:
> %{g*:-lg} %{!p:%{!pg:-lc}}%{p:-lc_p}%{pg:-lc_p}
>
> *startfile:
> %{pg:gcrt1.o%s}%{!pg:%{p:mcrt1.o%s}%{!p:crt1.o%s}}
>
> *switches_need_spaces:
>
>
> *signed_char:
> %{!fsigned-char:-D__CHAR_UNSIGNED__}
>
> *predefines:
> -Dwe32000 -Du3b -Dunix
>
> *cross_compile:
> 0
>

We found remarkably little information regarding exception handling and it
is difficult for us to produce printable text from the TeX files.  Would
it be a great burden to provide us with a brief extract (?) in plain text
format of the pertinent documentation?

My congratulations on what is in all respects a marvellous product.

--
Lucio de Re ([e-mail]) - tab stops at four.