Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_FS_1_19910112
-
c/dist/info-kcc.reqmail
There are no other files named info-kcc.reqmail in the archive.
17-Mar-87 22:50:49-PST,1521;000000000000
Return-Path: <[email protected]>
Received: from Score.Stanford.EDU by SRI-NIC.ARPA with TCP; Tue 17 Mar 87 22:50:47-PST
Date: Tue 17 Mar 87 22:46:31-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 17-Mar-87 21:04:47
Message failed for the following:
[email protected].#Internet: 554 <[email protected]>... microsof ! dann : Unknown
------------
Received: from LEAR.STANFORD.EDU by SCORE.STANFORD.EDU with TCP; Tue 17 Mar 87 21:04:47-PST
Received: from Sierra.Stanford.EDU by LEAR.STANFORD.EDU with TCP; Tue 17 Mar 87 21:06:16-PST
Received: from SRI-NIC.ARPA by Sierra.Stanford.EDU with TCP; Tue 17 Mar 87 21:06:30-PST
Date: Tue 17 Mar 87 20:47:56-PST
From: Ken Harrenstien <[email protected]>
Subject: KCC 560 - new version with bugfixes
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
A new version of KCC has been installed as SYS:CC.EXE on SRI-NIC.ARPA.
This corrects all of the minor bugs that users have discovered in the
most recent distribution, including unnamed bitfield positioning,
"register allocation" warnings, and more peephole optimizer bulletproofing.
A few additional minor optimizations are now done, but otherwise there
are no changes.
A reminder: send bug reports to [email protected] (the maintainer/hacker
list), not to INFO-KCC (the global news list). Thanks for the reports
so far!
-------
-------
18-Mar-87 10:01:42-PST,615;000000000000
Date: Wed 18 Mar 87 09:59:18-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 17-Mar-87 08:58:54
Message undelivered after 1 day -- will try for another 2 days:
[email protected]: Cannot connect to host
------------
Received: from A20.CC.UTEXAS.EDU by SRI-NIC.ARPA with TCP; Tue 17 Mar 87 08:58:41-PST
Date: Tue 17 Mar 87 10:58:34-CST
From: Mic Kaczmarczik <[email protected]>
Subject: Internal register allocation errors
To: [email protected]
Message-ID: <[email protected]>
-------
18-Mar-87 21:31:42-PST,517;000000000000
Date: Wed 18 Mar 87 21:19:58-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 17-Mar-87 20:48:02
Message undelivered after 1 day -- will try for another 2 days:
[email protected]: Cannot connect to host
------------
Date: Tue 17 Mar 87 20:47:56-PST
From: Ken Harrenstien <[email protected]>
Subject: KCC 560 - new version with bugfixes
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
19-Mar-87 10:31:46-PST,615;000000000000
Date: Thu 19 Mar 87 10:26:48-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 17-Mar-87 08:58:54
Message undelivered after 2 days -- will try for another 1 day:
[email protected]: Cannot connect to host
------------
Received: from A20.CC.UTEXAS.EDU by SRI-NIC.ARPA with TCP; Tue 17 Mar 87 08:58:41-PST
Date: Tue 17 Mar 87 10:58:34-CST
From: Mic Kaczmarczik <[email protected]>
Subject: Internal register allocation errors
To: [email protected]
Message-ID: <[email protected]>
-------
19-Mar-87 15:31:57-PST,544;000000000000
Date: Thu 19 Mar 87 15:17:33-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Mar-87 14:22:05
Message undelivered after 1 day -- will try for another 2 days:
[email protected]: Cannot connect to host
------------
Date: Wed 18 Mar 87 14:17:46-PST
From: Ken Harrenstien <[email protected]>
Subject: [Ken Harrenstien <[email protected]>: New H&S edition of CARM!]
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
20-Mar-87 00:56:39-PST,517;000000000000
Date: Fri 20 Mar 87 00:47:17-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 17-Mar-87 20:48:02
Message undelivered after 2 days -- will try for another 1 day:
[email protected]: Cannot connect to host
------------
Date: Tue 17 Mar 87 20:47:56-PST
From: Ken Harrenstien <[email protected]>
Subject: KCC 560 - new version with bugfixes
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
21-Mar-87 00:56:21-PST,2064;000000000000
Date: Sat 21 Mar 87 00:44:36-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 17-Mar-87 08:58:54
Message undeliverable and dequeued after 4 days:
[email protected]: Cannot connect to host
------------
Received: from A20.CC.UTEXAS.EDU by SRI-NIC.ARPA with TCP; Tue 17 Mar 87 08:58:41-PST
Date: Tue 17 Mar 87 10:58:34-CST
From: Mic Kaczmarczik <[email protected]>
Subject: Internal register allocation errors
To: [email protected]
Message-ID: <[email protected]>
Last night I was using the new distribution of KCC (announced in early
March) to recompile some code that had compiled fine using the old
version (ca. a month ago). Can anybody give me a clue as to what's
going wrong here? Since the source is about 30K bytes in all, I'm not
including it in this message, but will send it to any wizard willing
to look into the problem.
Thanks,
Mic Kaczmarczik
User Services Digital Support Group
U.T. Austin Computation Center
[email protected]
----------------------------------------------------------------------
[PHOTO: Recording initiated Tue 17-Mar-87 10:50AM]
Link from CC.KACZMARCZIK, TTY 112]
2a20 @ sys:cc -c -Imgsrc: buffer.c
KCC: buffer
Warning at killbuffer+66, line 161 of buffer.c:
savebuffers(
Internal error - Register allocation: unreleased registers left over from previo
us code
Warning at killbuffer+66, line 161 of buffer.c:
savebuffers(
Internal error - Register allocation: release of a spilled register
Warning at killbuffer+66, line 161 of buffer.c:
savebuffers(
Internal error - Register allocation: release of a spilled register
Warning at showbuffer+45, line 469 of buffer.c:
WINDOW
Internal error - Register allocation: unreleased registers left over from previo
us code
<CC.KACZMARCZIK.MG>BUFFER.PRE.1
<CC.KACZMARCZIK.MG>BUFFER.FAI.1
FAIL: buffer
2a20 @ pop
[PHOTO: Recording terminated Tue 17-Mar-87 10:50AM]
-------
-------
21-Mar-87 00:56:25-PST,1047;000000000000
Date: Sat 21 Mar 87 00:49:45-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 17-Mar-87 20:48:02
Message undeliverable and dequeued after 3 days:
[email protected]: Cannot connect to host
------------
Date: Tue 17 Mar 87 20:47:56-PST
From: Ken Harrenstien <[email protected]>
Subject: KCC 560 - new version with bugfixes
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
A new version of KCC has been installed as SYS:CC.EXE on SRI-NIC.ARPA.
This corrects all of the minor bugs that users have discovered in the
most recent distribution, including unnamed bitfield positioning,
"register allocation" warnings, and more peephole optimizer bulletproofing.
A few additional minor optimizations are now done, but otherwise there
are no changes.
A reminder: send bug reports to [email protected] (the maintainer/hacker
list), not to INFO-KCC (the global news list). Thanks for the reports
so far!
-------
-------
21-Mar-87 00:56:28-PST,544;000000000000
Date: Sat 21 Mar 87 00:54:02-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Mar-87 14:22:05
Message undelivered after 2 days -- will try for another 1 day:
[email protected]: Cannot connect to host
------------
Date: Wed 18 Mar 87 14:17:46-PST
From: Ken Harrenstien <[email protected]>
Subject: [Ken Harrenstien <[email protected]>: New H&S edition of CARM!]
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
21-Mar-87 01:26:19-PST,506;000000000000
Date: Sat 21 Mar 87 01:19:02-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 19-Mar-87 23:38:32
Message undelivered after 1 day -- will try for another 2 days:
[email protected]: Cannot connect to host
------------
Date: Thu 19 Mar 87 23:38:28-PST
From: Ken Harrenstien <[email protected]>
Subject: Floating-point questions
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
21-Mar-87 14:55:52-PST,2106;000000000000
Date: Sat 21 Mar 87 14:52:45-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Mar-87 14:22:05
Message undeliverable and dequeued after 3 days:
[email protected]: Cannot connect to host
------------
Date: Wed 18 Mar 87 14:17:46-PST
From: Ken Harrenstien <[email protected]>
Subject: [Ken Harrenstien <[email protected]>: New H&S edition of CARM!]
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Here's a copy of a message I just sent elsewhere:
Date: Wed 18 Mar 87 14:09:07-PST
From: Ken Harrenstien <[email protected]>
Subject: New H&S edition of CARM!
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Haven't seen any other mention of this, so thought I'd spread the
word; I wish I had known about it earlier myself.
I just discovered by accident that the second edition of Harbison and
Steele's "C: A Reference Manual" is now out in the stands!
Unfortunately, it also seems to be out of stock -- the first 4
bookstores I tried had completely run out of their initial orders
(they seemed quite bemused by its popularity), and all had additional
shipments on the way. I did manage to find one place (would you
believe the Stanford campus bookstore??) that still had a handful
left, and grabbed one. It's much heftier, costs $25, and the back
cover blurb claims it includes a description of the draft ANSI C
language. I haven't looked at it yet, but am confident that it will
be the definitive reference for C until the ANSI draft becomes a
standard (which may not be for a while).
--Ken
-------
I mention this here because KCC is supposed to be a full
implementation of H&S CARM, and I want to continue keeping it that
way. A close perusal of the second edition will be needed before we
can say what (if any) changes might be necessary or advisable; if
there are changes they will be announced, of course. Feel free to
make suggestions if you have some (to [email protected]).
-------
-------
22-Mar-87 00:10:56-PST,506;000000000000
Date: Sun 22 Mar 87 00:07:19-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 19-Mar-87 23:38:32
Message undelivered after 2 days -- will try for another 1 day:
[email protected]: Cannot connect to host
------------
Date: Thu 19 Mar 87 23:38:28-PST
From: Ken Harrenstien <[email protected]>
Subject: Floating-point questions
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
22-Mar-87 20:25:43-PST,507;000000000000
Date: Sun 22 Mar 87 20:20:10-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 21-Mar-87 16:41:28
Message undelivered after 1 day -- will try for another 2 days:
[email protected]: Cannot connect to host
------------
Date: Sat 21 Mar 87 16:41:22-PST
From: Ken Harrenstien <[email protected]>
Subject: Addendum on "long double"
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
22-Mar-87 20:25:45-PST,509;000000000000
Date: Sun 22 Mar 87 20:20:49-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 21-Mar-87 16:59:18
Message undelivered after 1 day -- will try for another 2 days:
[email protected]: Cannot connect to host
------------
Date: Sat 21 Mar 87 16:59:14-PST
From: Ken Harrenstien <[email protected]>
Subject: Multi-char constant format?
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
22-Mar-87 23:55:39-PST,2694;000000000000
Date: Sun 22 Mar 87 23:50:40-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 19-Mar-87 23:38:32
Message undeliverable and dequeued after 3 days:
[email protected]: Cannot connect to host
------------
Date: Thu 19 Mar 87 23:38:28-PST
From: Ken Harrenstien <[email protected]>
Subject: Floating-point questions
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
ANSI EXTENSION - "long double" type
The ANSI draft standard (X3J11) proposes a new float data type
called "long double" which is expected to have precision/range at
least as great as "double": float <= double <= long double. The need
to assign some hardware format to this new type raises the issue of
the most suitable mapping for all three types, and I'd like some comments
on this.
The PDP-10 floating point formats are:
Words Precision (digits) Range
"F" Single-precision 1 8 1.5e-39 to 1.7e38
"D" Double-precision 2 18 1.5e-39 to 1.7e38
"G" format 2 17 2.8e-309 to 9.0e307
The single-precision "F" format has been around since day one on the
PDP-6. Hardware double-precision ("D") was introduced on the KI-10
(the KA-10 uses a different software format for double precision). G
format is a new one only available in KL10s with microcode version 271
or up; KS10s (DEC-2020) don't have this. Note the loss of
significance is exchanged for a gain in range.
The plausible mappings appear to be:
Float Double Long Double
A. F F D Fast arith, all CPUs (or non-KL)
B. F F G Fast arith, KL only
C. F D D All CPUs (or non-KL)
D. F D G KL only
E. F G G KL only
C considerations:
C according to H&S requires that all operands of type "float"
be converted to "double". ANSI C will permit them to remain "float",
however. All C library routines, both now and in the future, require
"double" arguments and return "double" results.
Timing considerations:
I ran some timing tests on SRI-NIC (a DEC-2065) and have summarized
the results in this table (times are in usec):
ADD SUB MUL DIV
Single 1.9 2.2 2.5 4.6
Double 2.5 3.2 4.2 8.7
G-fmt 7.5 8.2 5.8 9.8
Exact times will depend on the operands used; the values chosen were
picked to give a reasonable number of bit transitions. Note the much
larger times for G format arithmetic.
I would like to hear any comments about the most suitable mapping to
use. If no one says anything, I will probably decide to simply keep
the current setup ("float" is F, "double" is D), and make "long
double" correspond to G format on KLs, D format otherwise.
-------
-------
23-Mar-87 16:08:41-PST,1269;000000000000
Date: Mon 23 Mar 87 15:59:51-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 23-Mar-87 15:43:53
Message failed for the following:
MAIL:[email protected]: No such mailbox
------------
Date: Mon 23 Mar 87 15:43:43-PST
From: Ian Macky <[email protected]>
Subject: Re: Problem with strncpy()
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
strncpy() does not terminate the target string with a null.
According to CARM I, section 11.2.9:
"strncpy copies exactly n characters to s1. It copies up to n
characters from s2. If there are fewer than n characters in
s2 before the terminating null character, then null characters
are written into s1 as padding until exactly n characters have
been written. If there are n or more characters in s2, then
only n characters are copied, and so only a truncated copy of
s2 is transferred to s1. IT FOLLOWS THAT THE COPY IN S1 IS
TERMINATED WITH A NULL BY STRNCPY ONLY IF THE LENGTH OF S2
(NOT COUNTING THE TERMINATING NULL) IS LESS THAN N."
CARM II says the same thing.
--ian
-------
-------
28-Mar-87 01:01:52-PST,452;000000000000
Return-Path: <[email protected]>
Received: from BIONET-20.ARPA by SRI-NIC.ARPA with TCP; Sat 28 Mar 87 01:01:39-PST
Date: Sat 28 Mar 87 00:59:20-PST
From: David Roode <[email protected]>
Subject: address change
To: [email protected]
Phone: (415) 962-7322
Message-ID: <[email protected]>
Please change the mailing entries for this machine to refer
to BIONET-20.ARPA rather than %BIONET@SUMEX-AIM
-------
3-Apr-87 14:22:15-PST,413;000000000000
Return-Path: <[email protected]>
Received: from USC-ECL.ARPA by SRI-NIC.ARPA with TCP; Fri 3 Apr 87 14:22:07-PST
Date: Fri 3 Apr 87 14:21:59-PST
From: Bruce Tanner <[email protected]>
Subject: Add me...
To: [email protected]
Message-ID: <[email protected]>
... to the list.
The top line of my news file says 12/07/86 KCC 537, LIBC 93.
Thanks,
-Bruce
-------
3-Apr-87 14:27:40-PST,462;000000000000
Mail-From: KLH created at 3-Apr-87 14:27:37
Date: Fri 3 Apr 87 14:27:37-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: Add me...
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
OK, you're on. You should get the latest stuff, which is KCC 560.
The file KCCDIST:INSTAL.DOC has the directions as usual.
-------
6-Apr-87 02:55:33-PDT,622;000000000000
Mail-From: MKL created at 6-Apr-87 02:54:12
Date: Mon 6 Apr 87 02:54:12-PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 4-Apr-87 11:23:13
Message undelivered after 2 days -- will try for another 1 day:
[email protected]: Cannot connect to host
------------
Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Sat 4 Apr 87 11:23:06-PST
Date: Sat, 4 Apr 1987 14:19 EST
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected]
cc: [email protected]
Subject: realloc() bug
-------
7-Apr-87 01:55:33-PDT,626;000000000000
Mail-From: VIVIAN created at 7-Apr-87 01:55:17
Date: Tue 7 Apr 87 01:55:17-PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 4-Apr-87 11:23:13
Message undelivered after 3 days -- will try for another 0 days:
[email protected]: Cannot connect to host
------------
Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Sat 4 Apr 87 11:23:06-PST
Date: Sat, 4 Apr 1987 14:19 EST
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected]
cc: [email protected]
Subject: realloc() bug
-------
7-Apr-87 23:10:33-PDT,1506;000000000000
Mail-From: VIVIAN created at 7-Apr-87 23:02:16
Date: Tue 7 Apr 87 23:02:16-PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 4-Apr-87 11:23:13
Message undeliverable and dequeued after 3 days:
[email protected]: Cannot connect to host
------------
Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Sat 4 Apr 87 11:23:06-PST
Date: Sat, 4 Apr 1987 14:19 EST
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected]
cc: [email protected]
Subject: realloc() bug
Symptom:
Using realloc() to shrink the size of a block returns garbage.
Diagnosis:
The code did the split() correctly but forgot to put the old
pointer where it would be passed back to the user.
Fix:
;COMPARISON OF SRC:<KCC.LIB>MALLOC.C.185 AND SRC:<KCC.LIB>MALLOC.C.186
;OPTIONS ARE /3
**** FILE SRC:<KCC.LIB>MALLOC.C.185, 8-47 (14868)
else if (old->size > need) /* if reducing, free the tail */
split(old, need);
**** FILE SRC:<KCC.LIB>MALLOC.C.186, 8-47 (14868)
else if (old->size > need) { /* if reducing, free the tail */
split(old, need);
return ptr;
}
***************
**** FILE SRC:<KCC.LIB>MALLOC.C.185, 8-56 (15211)
}
return new; /* return updated char pointer */
**** FILE SRC:<KCC.LIB>MALLOC.C.186, 8-58 (15233)
return new; /* return updated char pointer */
} /* never get here */
***************
--Rob
-------
14-Apr-87 02:57:41-PDT,1118;000000000000
Return-Path: <[email protected]>
Received: from bass.nosc.mil by SRI-NIC.ARPA with TCP; Tue 14 Apr 87 02:57:35-PDT
Received: by bass.nosc.mil (5.31/4.7)
id AA03658; Tue, 14 Apr 87 01:59:00 PST
Received: by humu.ARPA (5.31/4.7)
id AA10920; Mon, 13 Apr 87 23:58:02-1000
Received: by uhmanoa.ICS.HAWAII.EDU (5.51/UUCP-Project/rel-1.0/11-09-86)
id AA01138; Mon, 13 Apr 87 16:11:40-1000
Message-Id: <[email protected]>
Date: Mon, 13 Apr 87 09:59:20-1000
From: [email protected] (Jeffrey Blomberg)
To: [email protected]
Subject: KCC C compiler
Cc: jeff%[email protected]
I am interested in knowing the specifics on how to obtain the KCC C compiler
for our DEC-2065. Our -20 is used as a purely academic machine and the KCC
C compiler would be a useful addition to the system. In case it is an issue,
the -20 has been added to our UNIX license with AT&T.
Thank you.
Jeffrey Blomberg
University of Hawaii
Computing Center
2565 The Mall, Keller Hall
Honolulu, HI 96822
(808) 948-7351
14-Apr-87 11:00:09-PDT,6999;000000000000
Mail-From: KLH created at 14-Apr-87 11:00:04
Date: Tue 14 Apr 87 11:00:04-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC C compiler
To: [email protected],
[email protected]
cc: jeff%[email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Hi. Do you have any way to access the ARPANET or MILNET? If so, you
can retrieve the KCC compiler sources and binary directly over the net.
I know there are a few network sites there, but they keep changing, with
funny access rules. If you can't see any way to do it, then I guess
we'd have to make a distribution tape. This is a bit of a pain,
though, so I'll wait to hear from you. No UNIX license is needed, by
the way; we do not use or distribute any AT&T software.
Here is the INSTAL.DOC file, for additional info:
---------------------------------------------------------------------
INSTALLING KCC ON A TOPS-20 SYSTEM
KCC is normally distributed over the Internet via FTP from
SRI-NIC.ARPA, but can also be obtained on tape. This file describes
the basics of installing KCC for each, but you should read everything
regardless of which medium you are using.
TAPE INSTALLATION:
The TOPS-20 tape consists of a single DUMPER saveset with
several directories. They are organized into a single tree with the
top-level directory named "KCCDIST" or "KCC-n" or whatever; for
purposes of discussion we'll assume the fictitious name "KCC-n". You
can either retrieve all files at once, or extract only those necessary
to install a working copy of KCC.
Retrieving all files:
Create a directory, such as KCCDIST, to hold the distribution.
This will contain the following:
<KCC-n> General information files, in particular:
CC.EXE The KCC compiler.
AGREE.TXT Ethical issues.
INSTAL.DOC Installation info; what you are reading now.
NEWS.TXT News about this version.
C: => <KCC-n.INCLUDE> Runtime library and include files.
CC.DOC KCC user documentation.
<KCC-n.INCLUDE.SYS> More include files, Un*x oriented.
<KCC-n.FAIL> FAIL assembler source, binary, and manual.
<KCC-n.KCC> KCC compiler sources and auxiliary files.
<KCC-n.LIB*> Runtime library sources:
<KCC-n.LIB> General-purpose library routines.
<KCC-n.LIB.STDIO> Standard I/O package routines.
<KCC-n.LIB.MATH> Math library routines.
<KCC-n.LIB.USYS> Unix simulation routines.
<KCC-n.LIB.NETWORK> A stab at a couple BSD net routines.
<KCC-n.LIB.PML> Unused "portable math library" routines.
<KCC-n.LIB.TEST> Unused testing routines.
Installing a working KCC:
To install a working copy of KCC, you should create a
directory to hold the runtime library and include files, and define
the logical name C: to point to it. This may be the same directory as
the one you restored the tape to (i.e. <KCC-n.INCLUDE>), or it may be
a different place. This directory should also have a subdirectory
called SYS to hold certain other include files.
Read the NEWS.TXT file for any special news about this version
of the distribution. Then define C:, copy CC.EXE to your site's SYS:
directory, and you're all set.
To summarize, these are the files you need:
<KCC-n>CC.EXE
C: => <KCC-n.INCLUDE>*.*.0 Runtime library and include files.
<KCC-n.INCLUDE.SYS>*.*.0 More include files, Un*x oriented.
Be sure to read the General Notes farther on in this file.
FTP transfer notes:
If you are fortunate enough to have Internet access, I
recommend that you use FTP (File Transfer Protocol) to get copies of
any KCC files that you need.
Connect to SRI-NIC.ARPA, and use the FTP anonymous login
convention (username "anonymous", password your real name) to log in.
The complete distribution is available in the directory tree defined
by the logical name KCCDIST:, which is organized exactly as described
in the previous (tape installation) section. You can retrieve any of
the files or directories mentioned as needed.
NOTE: the exact directory name which KCCDIST: points to will
vary! It may be <KCCDIST>, or <KCC-n>, or something else, so be
prepared to modify the given filenames appropriately.
BETA-TEST Versions:
For those interested in serving as "beta test" sites and
living dangerously, it is possible to acquire the very latest binaries
by transferring the following files:
SYS:CC.EXE Latest KCC.
C:*.*.0 Latest runtime library and include files.
C:<KCC.SYS>*.*.0 Latest Un*x-emulation include files.
Since KCC and the library are still evolving steadily, you will almost
certainly get something newer and better. Just be aware that you also
have the following risks:
(1) The binaries may contain new bugs.
(2) The new versions may be incompatible (this will cause linker
error messages to alert you, however).
(3) The new sources will not be available until things stabilize
enough for a new distribution to be made.
General Notes:
It is wise to retain the file version numbers during
installation, since that is how KCC versions are numbered; a higher
file version number means a more recent version of KCC.
C:CC.DOC contains user documentation. More internal details
may be available at various places in the directory tree, in files
named *.DOC.
KCC as distributed will invoke the FAIL assembler by
default, rather than MACRO, because FAIL is much faster. If you do
not have FAIL, you may wish to install it also. The .EXE binary,
.FAI source, and line-printer style manual (FAIL.MANUAL) are included.
If you don't want to try this, or for other reasons prefer to use
MACRO, then you will want to either recompile KCC with the CCSITE.H
file changed to reflect your preferences, or you can patch the "tgasm"
variable in CC.EXE to have the value 1.
MONITOR/EXEC Modifications:
There are certain modifications to the TOPS-20 Monitor and Exec
which KCC can make use of, if they are available. They are:
(1) Monitor: the PIP: device, to support pipes.
(2) Exec: PRARG% protocol to support "&" background processing.
(3) Exec: COMPIL-class command support.
Many sites already have these modifications, but if you don't, you
should be able to obtain them from their origin at Stanford; contact
Stu Grossman <[email protected]>. Note that they are not
necessary, either to use KCC or run the C programs it compiles.
The COMPIL-class command change is simple enough to be described here:
The EXEC modifications to make its COMPILE/LOAD/etc commands
work with KCC can be found in the Stanford version of the EXEC
in the EXECCS module:
In the LANGUAGE macro definition, add:
L (DDT,C,CC,KCC) ;KCC
Immediately after the instruction at BSRC1, add:
CAIN P4,LT.C
RET
Immediately after the instruction at PUTDF, add:
CAIN P4,LT.C
SKIPA ; If KCC, always use native mode.
-------
27-May-87 01:01:41-PDT,331;000000000000
Date: Wed 27 May 87 00:58:27-PDT
From: The Mail System <[email protected]>
To: List Maintainer <[email protected]>
Subject: Error in mailing list
There is an unknown hostname in the "INFO-KCC-RELAY" mailing list.
The incorrect entry is for: "[email protected]"
Please fix it,
Thanks.
-------
27-May-87 08:48:20-PDT,331;000000000000
Date: Wed 27 May 87 08:48:13-PDT
From: The Mail System <[email protected]>
To: List Maintainer <[email protected]>
Subject: Error in mailing list
There is an unknown hostname in the "INFO-KCC-RELAY" mailing list.
The incorrect entry is for: "[email protected]"
Please fix it,
Thanks.
-------
8-Jun-87 18:23:00-PDT,423;000000000000
Return-Path: <[email protected]>
Received: from C.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Mon 8 Jun 87 18:22:58-PDT
Received: ID <[email protected]>; Mon 8 Jun 87 21:22:49-EDT
Date: Mon 8 Jun 87 21:22:48-EDT
From: [email protected]
Subject: Please add...
To: [email protected]
Message-ID: <[email protected]>
..."[email protected]" to INFO-KCC.
Thanks,
--Vince
-------
9-Jun-87 18:01:20-PDT,488;000000000000
Return-Path: <[email protected]>
Received: from venera.isi.edu by SRI-NIC.ARPA with TCP; Tue 9 Jun 87 18:01:14-PDT
Posted-Date: Tue, 09 Jun 87 18:01:40 PDT
Message-Id: <[email protected]>
Received: from LOCALHOST by venera.isi.edu (5.54/5.51)
id AA16241; Tue, 9 Jun 87 18:01:41 PDT
To: [email protected]
Subject: Add to kcc mailing list
Date: Tue, 09 Jun 87 18:01:40 PDT
From: [email protected]
Please add me. Thanks. Good day!
/Koji
16-Jun-87 22:30:19-PDT,794;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Tue 16 Jun 87 22:30:06-PDT
Received: by decwrl.dec.com (5.54.3/4.7.34)
id AA16110; Tue, 16 Jun 87 16:39:32 PDT
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA22924; Tue, 16 Jun 87 16:34:41 PDT
Date: Tue, 16 Jun 87 16:34:41 PDT
From: [email protected] (Kok Chen)
Message-Id: <[email protected]>
To: "[email protected]"@decwrl.dec.com
Subject: info-kcc
Please add me to the mailing list. I have no intention
of running it here, since there is no DECsystem-20 around. Just
curious... :-)
The following should get to me from the Arpanet:
kchen%[email protected]
Thanks in advance,
Kok S. Chen
Imagen Corporation
8-Jul-87 11:29:50-PDT,457;000000000000
Return-Path: <[email protected]>
Received: from MATHOM.CISCO.COM by SRI-NIC.ARPA with TCP; Wed 8 Jul 87 11:29:28-PDT
Date: Wed 8 Jul 87 11:35:21-PDT
From: Kirk Lougheed <[email protected]>
Subject: change of address
To: [email protected]
Message-ID: <[email protected]>
Please change the mailing address "[email protected]"
to "[email protected]".
thank you,
Kirk
-------
8-Jul-87 11:31:28-PDT,362;000000000000
Mail-From: KLH created at 8-Jul-87 11:31:22
Date: Wed 8 Jul 87 11:31:22-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: change of address
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
OK, done.
-------
8-Jul-87 11:42:20-PDT,1477;000000000000
Date: Wed 8 Jul 87 11:31:23-PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 8-Jul-87 11:09:23
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Received: from BIONET-20.ARPA by SRI-NIC.ARPA with TCP; Wed 8 Jul 87 11:08:38-PDT
Date: Wed 8 Jul 87 11:07:44-PDT
From: ELLIS E. GOLUB <[email protected]>
Subject: TERMINAL PAUSE and printf
To: [email protected]
cc: [email protected], [email protected]
Message-ID: <[email protected]>
I have experienced strange behavior by a program which outputs to the
terminal, when TERMINAL NO PAUSE END-OF-PAGE is in effect. Under
these conditions, some output is lost, while output from later
sections of the program begins inappropriately early. The same program
and data produce perfect output when the TERMINAL PAUSE option is
used. Initially, the output was generated by printf("\n.....
statements. When these gave poor results, I tried the \n at the end
of the line. When this failed, I tried fprintf(stdout,"...., and when
that failed, I tried sprintf(buffer,".... followed by
printf("%s\n",buffer). All of these attempts gave similar results.
Has anyone experienced similar problems, or does anyone have a fix
that eliminates this annoying bug?
Ellis Golub
U. Penn.
(215) 661-3269
-------
-------
8-Jul-87 13:09:06-PDT,1194;000000000000
Date: Wed 8 Jul 87 12:57:30-PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 8-Jul-87 11:31:13
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Received: from BIONET-20.ARPA by SRI-NIC.ARPA with TCP; Wed 8 Jul 87 11:30:53-PDT
Received: from SRI-NIC.ARPA by BIONET-20.ARPA with TCP; Wed 8 Jul 87 11:30:35-PDT
Date: Wed 8 Jul 87 11:29:36-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: TERMINAL PAUSE and printf
To: [email protected], [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Please send bug reports to [email protected]. INFO-KCC is not a
bug reporting list and reaches many people who are not interested in
those reports. For this case, I suggest you also contact Rusch,
Relph, and Dautricourt at BIONET. Last I heard they were still using
a fairly old release of KCC, although it's hard to see how program
behavior could change just due to the TER PAUSE setting.
-------
-------
15-Jul-87 07:44:14-PDT,1149;000000000000
Return-Path: <enea!FREJA.QZ.SE!ATHENA.SUNET.SE!AIDA.UU.SE!P-E-MARTIN@uunet.uu.net>
Received: from seismo.CSS.GOV by SRI-NIC.ARPA with TCP; Wed 15 Jul 87 07:44:01-PDT
Received: from uunet.UU.NET by seismo.CSS.GOV (5.54/1.14)
id AA01753; Wed, 15 Jul 87 09:45:53 EDT
Received: from enea.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA15946; Wed, 15 Jul 87 09:45:46 EDT
Received: by enea.se (5.57/1.38)
id AA07128; Wed, 15 Jul 87 15:00:30 +0200 (MET)
Received: from LISBET (lisbet.liu.se) by majestix.liu.se; Wed, 15 Jul 87 14:50:00 +0200
Received: from FREJA (not validated) by LISBET; Wed 15 Jul 87 14:48:17
Received: from ATHENA (not validated) by FREJA; Wed 15 Jul 87 14:47:56
Received: from AIDA by ATHENA with Cafard; Wed 15 Jul 87 14:46:04
Date: Wed 15 Jul 87 14:38:10
From: Per-Erik Martin <[email protected]>
Subject: Info-KCC
To: [email protected]
Message-Id: <870715143810.6.P-E-MARTIN@AIDA>
Please add me to the KCC lists.
Thank you!
Per-Erik Martin
Computing Science Dept.,
Uppsala University
Box 520
S-721 20 Uppsala
Sweden
(Email: [email protected])
-------
17-Aug-87 11:44:43-PDT,439;000000000000
Return-Path: <[email protected]>
Received: from AI.AI.MIT.EDU by SRI-NIC.ARPA with TCP; Mon 17 Aug 87 11:44:34-PDT
Date: Mon, 17 Aug 87 14:44:39 EDT
From: Alan Bawden <[email protected]>
Subject: KCC meets ITS
To: [email protected]
Message-ID: <[email protected]>
I'm seriously thinking of finishing the port of KCC to ITS, so perhaps I
should be added to the Info-KCC and Bug-KCC mailing lists.
17-Aug-87 12:02:15-PDT,629;000000000000
Mail-From: KLH created at 17-Aug-87 12:02:10
Date: Mon 17 Aug 87 12:02:10-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC meets ITS
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
OK, you're on both lists now. Have you reached any conclusion as to the
best overall scheme for assembling and linking the compilation results?
Perhaps you, I, SRA, and anyone else that you know to be interested should
start a small offshoot mailing list to hammer out ITS-specific issues.
-------
21-Aug-87 15:46:40-PDT,3102;000000000000
Return-Path: <[email protected]>
Received: from XX.LCS.MIT.EDU by SRI-NIC.ARPA with TCP; Fri 21 Aug 87 15:46:27-PDT
Date: Fri, 21 Aug 1987 18:43 EDT
Message-ID: <[email protected]>
From: Rob Austein <[email protected]>
To: [email protected]
Reply-To: [email protected]
cc: [email protected], [email protected]
Subject: Welcome to the INFO-CHIVES list (TOPS-20 domain resolver)
[Bug-COMSAT and INFO-KCC-REQUEST are receiving this because there's
some overlap of interests here. The ITS version isn't done yet, but
we're working on it....]
If you're receiving this message, it's because at one point you
expressed an interest in the domain resolver code I've been
developing. It's finally ready for people other than me to look at.
CHIVES.EXE (the UDP resolver process) and the GTDOM% JSYS (the normal
user interface) are finished, or at least functional enough to
release. ZT (the zone transfer client) was written a long time ago
and a lot of things have happened to the code since then, so it
probably won't compile. I'll be fixing this Real Soon Now (I doubt
it's a major job).
For those who have had experience with the ISI GTDOM%, you can relax,
the MIT GTDOM% is much lower profile, you don't have to hack PAGEM or
anything hairy like that. The only non-trivial changes to existing
monitor code is the addition of a few short accessor routines to
IPCF.MAC and, if you're running under 5.4, retrofitting support for
paged IPCF from monitor context (DEC supports this as of rel 6).
All the stuff lives in XX:<CHIVES> and child directories thereof,
accessible via ANONYMOUS FTP. Documentation is a little scanty at the
moment, there are -READ-.-THIS- and .DOC files scattered around hither
and yon.
GTDOM% has been tested somewhat under an MIT 5.4 monitor. It hasn't
been used as the system resolver yet. It should be possible to bring
GTDOM% up under 6.1 without too much trouble, but it hasn't been done
yet because XX still runs 5.4 (this week).
Please send mail to [email protected] if you want to be on
the alpha test mailing list (CHIVES-ALPHA@XX...). Also send mail if
you no longer care about resolvers or 20s and want to be taken off all
the lists, etcetera. I'm not sure if there will ever be a formal beta
test version, not that many people seem to care. We'll see how it
goes.
Two things you should note before trying to obtain the code:
(1) You need a current distribution of KCC (from SRI-NIC.ARPA).
Contact [email protected] for information about KCC.
(2) Please note that the code IS copyrighted and has absolutely NO
WARRANTY. This is to avoid having somebody try to sell the code
back to me in a year or so and to avoid lawsuits. The copyright
policy is spelled out in the file XX:<CHIVES>COPYRIGHT.NOTICE; if
you have problems with this, please get in touch with me about it
and we'll see if we can work something out.
Welcome to the future, TOPS-20 isn't quite dead yet....
27-Aug-87 08:18:33-PDT,650;000000000000
Return-Path: <DUNLAP%[email protected]>
Received: from ohio-state.ARPA by SRI-NIC.ARPA with TCP; Thu 27 Aug 87 08:18:21-PDT
Return-Path: <DUNLAP%[email protected]>
Received: from OSU-20 (osu-20.ARPA) by ohio-state.ARPA (4.12/6.1.OSU-CIS)
id AA10796; Thu, 27 Aug 87 11:18:37 edt
Message-Id: <[email protected]>
Date: Thu 27 Aug 87 11:17:24-EDT
From: Bryan Dunlap <DUNLAP%[email protected]>
Subject: acquiring KCC
To: [email protected]
What does it take to get a copy of KCC? We are running Stanford's 6.1
monitor. I can ftp it if that's an option.
==BD
Ohio State University
-------
27-Aug-87 10:38:34-PDT,6713;000000000000
Mail-From: KLH created at 27-Aug-87 10:38:28
Date: Thu 27 Aug 87 10:38:28-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: acquiring KCC
To: DUNLAP%[email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Hi, here's a copy of the INSTAL.DOC file for KCC, which I hope will answer
some of your questions. A new release (KCC-4) should be coming out quite soon,
and I would suggest waiting for that as far as sources are concerned; why
don't I add your name to the INFO-KCC mailing list, so you'll receive word
when it's ready?
------------------------------------------------------
INSTALLING KCC ON A TOPS-20 SYSTEM
KCC is normally distributed over the Internet via FTP from
SRI-NIC.ARPA, but can also be obtained on tape. This file describes
the basics of installing KCC for each, but you should read everything
regardless of which medium you are using.
TAPE INSTALLATION:
The TOPS-20 tape consists of a single DUMPER saveset with
several directories. They are organized into a single tree with the
top-level directory named "KCCDIST" or "KCC-n" or whatever; for
purposes of discussion we'll assume the fictitious name "KCC-n". You
can either retrieve all files at once, or extract only those necessary
to install a working copy of KCC.
Retrieving all files:
Create a directory, such as KCCDIST, to hold the distribution.
This will contain the following:
<KCC-n> General information files, in particular:
CC.EXE The KCC compiler.
AGREE.TXT Ethical issues.
INSTAL.DOC Installation info; what you are reading now.
NEWS.TXT News about this version.
C: => <KCC-n.INCLUDE> Runtime library and include files.
CC.DOC KCC user documentation.
<KCC-n.INCLUDE.SYS> More include files, Un*x oriented.
<KCC-n.FAIL> FAIL assembler source, binary, and manual.
<KCC-n.KCC> KCC compiler sources and auxiliary files.
<KCC-n.LIB*> Runtime library sources:
<KCC-n.LIB> General-purpose library routines.
<KCC-n.LIB.STDIO> Standard I/O package routines.
<KCC-n.LIB.MATH> Math library routines.
<KCC-n.LIB.USYS> Unix simulation routines.
<KCC-n.LIB.NETWORK> A stab at a couple BSD net routines.
<KCC-n.LIB.PML> Unused "portable math library" routines.
<KCC-n.LIB.TEST> Unused testing routines.
Installing a working KCC:
To install a working copy of KCC, you should create a
directory to hold the runtime library and include files, and define
the logical name C: to point to it. This may be the same directory as
the one you restored the tape to (i.e. <KCC-n.INCLUDE>), or it may be
a different place. This directory should also have a subdirectory
called SYS to hold certain other include files.
Read the NEWS.TXT file for any special news about this version
of the distribution. Then define C:, copy CC.EXE to your site's SYS:
directory, and you're all set.
To summarize, these are the files you need:
<KCC-n>CC.EXE
C: => <KCC-n.INCLUDE>*.*.0 Runtime library and include files.
<KCC-n.INCLUDE.SYS>*.*.0 More include files, Un*x oriented.
Be sure to read the General Notes farther on in this file.
FTP transfer notes:
If you are fortunate enough to have Internet access, I
recommend that you use FTP (File Transfer Protocol) to get copies of
any KCC files that you need.
Connect to SRI-NIC.ARPA, and use the FTP anonymous login
convention (username "anonymous", password your real name) to log in.
The complete distribution is available in the directory tree defined
by the logical name KCCDIST:, which is organized exactly as described
in the previous (tape installation) section. You can retrieve any of
the files or directories mentioned as needed.
NOTE: the exact directory name which KCCDIST: points to will
vary! It may be <KCCDIST>, or <KCC-n>, or something else, so be
prepared to modify the given filenames appropriately.
BETA-TEST Versions:
For those interested in serving as "beta test" sites and
living dangerously, it is possible to acquire the very latest binaries
by transferring the following files:
SYS:CC.EXE Latest KCC.
C:*.*.0 Latest runtime library and include files.
C:<KCC.SYS>*.*.0 Latest Un*x-emulation include files.
Since KCC and the library are still evolving steadily, you will almost
certainly get something newer and better. Just be aware that you also
have the following risks:
(1) The binaries may contain new bugs.
(2) The new versions may be incompatible (this will cause linker
error messages to alert you, however).
(3) The new sources will not be available until things stabilize
enough for a new distribution to be made.
General Notes:
It is wise to retain the file version numbers during
installation, since that is how KCC versions are numbered; a higher
file version number means a more recent version of KCC.
C:CC.DOC contains user documentation. More internal details
may be available at various places in the directory tree, in files
named *.DOC.
KCC as distributed will invoke the FAIL assembler by
default, rather than MACRO, because FAIL is much faster. If you do
not have FAIL, you may wish to install it also. The .EXE binary,
.FAI source, and line-printer style manual (FAIL.MANUAL) are included.
If you don't want to try this, or for other reasons prefer to use
MACRO, then you will want to either recompile KCC with the CCSITE.H
file changed to reflect your preferences, or you can patch the "tgasm"
variable in CC.EXE to have the value 1.
MONITOR/EXEC Modifications:
There are certain modifications to the TOPS-20 Monitor and Exec
which KCC can make use of, if they are available. They are:
(1) Monitor: the PIP: device, to support pipes.
(2) Exec: PRARG% protocol to support "&" background processing.
(3) Exec: COMPIL-class command support.
Many sites already have these modifications, but if you don't, you
should be able to obtain them from their origin at Stanford; contact
Stu Grossman <[email protected]>. Note that they are not
necessary, either to use KCC or run the C programs it compiles.
The COMPIL-class command change is simple enough to be described here:
The EXEC modifications to make its COMPILE/LOAD/etc commands
work with KCC can be found in the Stanford version of the EXEC
in the EXECCS module:
In the LANGUAGE macro definition, add:
L (DDT,C,CC,KCC) ;KCC
Immediately after the instruction at BSRC1, add:
CAIN P4,LT.C
RET
Immediately after the instruction at PUTDF, add:
CAIN P4,LT.C
SKIPA ; If KCC, always use native mode.
-------
27-Aug-87 13:25:26-PDT,387;000000000000
Return-Path: <@wiscvm.wisc.edu:[email protected]>
Received: from wiscvm.wisc.edu by SRI-NIC.ARPA with TCP; Thu 27 Aug 87 13:25:12-PDT
Received: from DBNRHRZ1.BITNET by wiscvm.wisc.edu ; Thu, 27 Aug 87 15:25:05 CDT
Date: Thu, 27 Aug 87 17:00:37 MEZ
To: [email protected]
From: UZR50D%[email protected]
Subject: Help to get the KCC C Compiler
HELP
27-Aug-87 13:30:54-PDT,548;000000000000
Mail-From: KLH created at 27-Aug-87 13:30:45
Date: Thu 27 Aug 87 13:30:45-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: Help to get the KCC C Compiler
To: UZR50D%[email protected], [email protected]
cc: [email protected]
In-Reply-To: Message from "UZR50D%[email protected]" of Thu 27 Aug 87 13:25:24-PDT
Message-ID: <[email protected]>
I agree, anybody forced to use names like UZR50D%DBNRHRZ1.BITNET is obviously
in need of help. But what do you want exactly?
-------
9-Sep-87 10:48:39-PDT,495;000000000000
Return-Path: <[email protected]>
Received: from ORNL-MSR.ARPA by SRI-NIC.ARPA with TCP; Wed 9 Sep 87 10:48:26-PDT
Received: by ORNL-MSR.ARPA (5.51/4.9)
id AA19154; Wed, 9 Sep 87 13:48:18 EDT
Date: Wed, 9 Sep 87 13:48:18 EDT
From: [email protected] (Jeff Jones)
Message-Id: <[email protected]>
To: [email protected]
Subject: Please add me to your KCC mailing list
Please add me to your KCC C compiler mailing list.
Thank You,
Jeff Jones
(615)576-2335
9-Sep-87 11:05:47-PDT,495;000000000000
Mail-From: KLH created at 9-Sep-87 11:05:38
Date: Wed 9 Sep 87 11:05:38-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: Please add me to your KCC mailing list
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
OK, you're on the INFO-KCC list now. Traffic tends to be sporadic, but
there should be an announcement coming along in a week or so...
-------
15-Sep-87 15:59:04-PDT,4108;000000000000
Date: Tue, 15 Sep 87 15:57:37 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 15-Sep-87 15:47:30
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Date: Tue, 15 Sep 87 15:47:22 PDT
From: Ken Harrenstien <[email protected]>
Subject: New KCC and LIBC binaries available
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
The new version of KCC (and its runtime library, LIBC) is now
available for people who want to try it out in binary form. After
waiting a while longer to see what bugs get shaken out, we'll put
together another snapshot of the sources and call that the KCC-4
distribution. Please send all bug reports to [email protected].
To get the new stuff, FTP these files from SRI-NIC.ARPA:
SYS:CC.EXE.0 (SYS:CCX.EXE if you want the extended-addr version)
C:*.*.0
PS:<KCC.SYS>*.*.0
You cannot simply get LIBC.REL from C: because many of the existing .H
files have been changed, and there are new additional files. So you will
have to copy everything.
Here is an extract from NEWS.TXT that describes what's new about this version:
---------------------
The bad news is that this release is incompatible enough with
the previous versions that you will have to recompile everything you
want to link together. This is mainly because the format of jmp_buf
(used by setjmp and longjmp) had to be expanded. As long as this had
to happen, a few other structures were expanded too. The $$CVER symbol
was updated to force LINK errors on any attempts to load incompatibly
compiled code.
The good news is that this version should completely implement all
facilities described by the new 2nd edition of Harbison and Steele's "C: A
Reference Manual". Some new system calls are also included.
KCC:
Few changes, mostly bug fixes. The __DATE__ and __TIME__ macros
have been implemented, which expand into the date and time of compilation.
LIBC:
Major changes. Many new functions were added. In particular,
signals now work, which required some revamping of the Un*x system
call (USYS) simulation routines. The following are the additions of
note:
longjmp/setjmp now act like CARM/4.3BSD and can restore context
properly even from within a signal handler.
The signal mechanism is intended to fully simulate 4.3BSD
sigvec, including the functions sigvec, sigblock, sigsetmask,
sigpause, sigreturn. All TOPS-20 PSIs are provided for. USYS calls
are handled atomically except when doing monitor calls; those which
are allowed to be interrupted will return EINTR errors.
Some new ANSI functions were added to STDIO. These include
setvbuf, remove, rename, tmpfile, tmpnam, v[fs]printf.
Some new general ANSI utilities were added, including bsearch,
div, ldiv, strtod, strol, strtoul, onexit, strerror, clock, mktime.
The time functions were completed and made portable.
Several miscellaneous functions described in CARM (most from
SYSV) were added, including ctermid, cuserid, getcwd, getenv, putenv,
getlogin, getopt.
A new "system call" was provided: forkexec(), which combines
the functions of fork() and exec() in a way which is extremely efficient
for TOPS-20 (and still portable to Un*x systems). The system() routine
now uses this, as does the runtime when forking pipes.
The jsys() routine was redone to provide a consistent interface
regardless of how the actual jsys returns success or failure. It also
provides an indication of whether the jsys was interrupted, if this
was permitted for the call.
Most important TTY ioctl() functions are now supported.
This includes the ability to set the SIGINT and SIGQUIT interrupt
characters. RAW and CBREAK mode are implemented.
There are some new documentation files. LIBC.DOC and USYS.DOC
summarize the library routines in general and the USYS calls in
particular; SIGNAL.DOC provides more details on the KCC implementation
of signals.
-------
-------
15-Sep-87 17:30:51-PDT,4491;000000000000
Return-Path: <@SUMEX-AIM.STANFORD.EDU:[email protected]>
Received: from SUMEX-AIM.STANFORD.EDU by SRI-NIC.ARPA with TCP; Tue 15 Sep 87 17:30:45-PDT
Received: from PANDA.COM by SUMEX-AIM.STANFORD.EDU with Cafard; Tue, 15 Sep 87 17:29:26 PDT
Date: Tue, 15 Sep 87 16:27:11 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 15-Sep-87 16:25:36
Message failed for the following:
[email protected].#Special: No such mailbox
------------
Received: from SUMEX-AIM.Stanford.EDU by PANDA.COM with Cafard; Tue, 15 Sep 87 16:25:37 PDT
Received: from SRI-NIC.ARPA by SUMEX-AIM.STANFORD.EDU with TCP; Tue, 15 Sep 87 15:53:01 PDT
Date: Tue, 15 Sep 87 15:47:22 PDT
From: Ken Harrenstien <[email protected]>
Subject: New KCC and LIBC binaries available
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
The new version of KCC (and its runtime library, LIBC) is now
available for people who want to try it out in binary form. After
waiting a while longer to see what bugs get shaken out, we'll put
together another snapshot of the sources and call that the KCC-4
distribution. Please send all bug reports to [email protected].
To get the new stuff, FTP these files from SRI-NIC.ARPA:
SYS:CC.EXE.0 (SYS:CCX.EXE if you want the extended-addr version)
C:*.*.0
PS:<KCC.SYS>*.*.0
You cannot simply get LIBC.REL from C: because many of the existing .H
files have been changed, and there are new additional files. So you will
have to copy everything.
Here is an extract from NEWS.TXT that describes what's new about this version:
---------------------
The bad news is that this release is incompatible enough with
the previous versions that you will have to recompile everything you
want to link together. This is mainly because the format of jmp_buf
(used by setjmp and longjmp) had to be expanded. As long as this had
to happen, a few other structures were expanded too. The $$CVER symbol
was updated to force LINK errors on any attempts to load incompatibly
compiled code.
The good news is that this version should completely implement all
facilities described by the new 2nd edition of Harbison and Steele's "C: A
Reference Manual". Some new system calls are also included.
KCC:
Few changes, mostly bug fixes. The __DATE__ and __TIME__ macros
have been implemented, which expand into the date and time of compilation.
LIBC:
Major changes. Many new functions were added. In particular,
signals now work, which required some revamping of the Un*x system
call (USYS) simulation routines. The following are the additions of
note:
longjmp/setjmp now act like CARM/4.3BSD and can restore context
properly even from within a signal handler.
The signal mechanism is intended to fully simulate 4.3BSD
sigvec, including the functions sigvec, sigblock, sigsetmask,
sigpause, sigreturn. All TOPS-20 PSIs are provided for. USYS calls
are handled atomically except when doing monitor calls; those which
are allowed to be interrupted will return EINTR errors.
Some new ANSI functions were added to STDIO. These include
setvbuf, remove, rename, tmpfile, tmpnam, v[fs]printf.
Some new general ANSI utilities were added, including bsearch,
div, ldiv, strtod, strol, strtoul, onexit, strerror, clock, mktime.
The time functions were completed and made portable.
Several miscellaneous functions described in CARM (most from
SYSV) were added, including ctermid, cuserid, getcwd, getenv, putenv,
getlogin, getopt.
A new "system call" was provided: forkexec(), which combines
the functions of fork() and exec() in a way which is extremely efficient
for TOPS-20 (and still portable to Un*x systems). The system() routine
now uses this, as does the runtime when forking pipes.
The jsys() routine was redone to provide a consistent interface
regardless of how the actual jsys returns success or failure. It also
provides an indication of whether the jsys was interrupted, if this
was permitted for the call.
Most important TTY ioctl() functions are now supported.
This includes the ability to set the SIGINT and SIGQUIT interrupt
characters. RAW and CBREAK mode are implemented.
There are some new documentation files. LIBC.DOC and USYS.DOC
summarize the library routines in general and the USYS calls in
particular; SIGNAL.DOC provides more details on the KCC implementation
of signals.
-------
-------
5-Nov-87 13:32:33-PST,616;000000000000
Return-Path: <[email protected]>
Received: from ECLA.USC.EDU by SRI-NIC.ARPA with TCP; Thu 5 Nov 87 13:32:29-PST
Date: Thu 5 Nov 87 13:32:03-PST
From: Ted Shapin <[email protected]>
Subject: KCC sources
To: [email protected]
Phone: (714)961-3393; Mail:Beckman Instruments, Inc.
Mail-addr: 2500 Harbor Blvd., X-11, Fullerton CA 92634
Message-ID: <[email protected]>
We are thinking of taking the KCC sources and porting the
compiler to our VAX. (We don't have DEC's C.)
Where are the sources?
Has anyone done this already?
Thanks.
Ted
-------
5-Nov-87 14:08:51-PST,1509;000000000000
Mail-From: KLH created at 5-Nov-87 14:08:40
Date: Thu, 5 Nov 87 14:08:40 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC sources
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Urgh. No, no one has done this. I'm not even sure if I would
recommend it. The preprocessing and parse tree generation is
fairly portable, but the code generation deals with PDP-10 pseudo-code
and outputs an assembler text file. You would also have to recode
the OS-dependent portions of the C library.
It might be more feasible to start with the GNU C compiler, which I
believe currently produces 68000 code; someone might even be modifying
it for the VAX. That would be useful since the GNU people
specifically want the result to be free, and from what I hear of the
compiler, it is quite good. If I were to try bringing up a non-BSD,
non-DEC compiler on the VAX, this is where I would start.
You could find out by sending a message to [email protected]
(there is a more direct address but I forget what it is at the moment).
The KCC distribution sources live in the KCCDIST: directory on SRI-NIC.
There is a new distribution that is almost ready to supersede the old
one, so if you decide you want to try hacking it, you should check with
me to make sure you have the right stuff. Let me know what you decide
to do...
-------
20-Nov-87 03:25:04-PST,1570;000000000000
Date: Fri, 20 Nov 87 03:21:42 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 19-Nov-87 21:38:27
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Received: from CU20B.COLUMBIA.EDU by SRI-NIC.ARPA with TCP; Thu 19 Nov 87 21:38:12-PST
Date: Fri 20 Nov 87 00:37:31-EST
From: Ken Rossman <[email protected]>
Subject: Linking assembler subroutines with KCC programs
To: [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>
I'd like to be able to write an entirely separate assembler subroutine (in
MACRO) to be linked in with some KCC modules, and not have to use asm() if
possible. I have been fairly successful at getting this to work, except
that I would like to force the code to be placed in the TEXT segment. Is
there a way to do this? /Ken
P.S. -- If I let LINK put my MACRO module wherever it wants to, it will
stick it in the low segment (start address 140), which apparently blows
away some data that printf wants -- anyway, printf acts strangely. I've
forced the module to live at some hard address with LOC, but there must be
a better way.
P.P.S. -- Using the #asm/#endasm constructs, the right thing almost
happens. If I try to force the data storage in the MACRO source into the
DATA segment with %%DATA, the unpredictable printf behavior occurs again.
-------
-------
20-Nov-87 03:30:03-PST,794;000000000000
Date: Fri, 20 Nov 87 03:27:28 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Nov-87 02:33:35
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Date: Fri, 20 Nov 87 02:33:28 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: Linking assembler subroutines with KCC programs
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
You should be addressing [email protected], not INFO-KCC (which is mainly
for news dissemination). I will respond to your question in a separate message.
-------
-------
21-Nov-87 09:44:51-PST,1043;000000000000
Return-Path: <[email protected]>
Received: from LEAR.STANFORD.EDU ([36.48.0.1]) by SRI-NIC.ARPA with TCP; Sat 21 Nov 87 09:44:42-PST
Date: Sat 21 Nov 87 09:44:19-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Nov-87 03:02:02
Message undelivered after 1 day -- will try for another 2 days:
*PS:<D.DAGONE>[email protected].#Internet: Disk quota exceeded
------------
Received: from Sierra.Stanford.EDU by LEAR.STANFORD.EDU with TCP; Fri 20 Nov 87 03:02:02-PST
Received: from SRI-NIC.ARPA by Sierra.Stanford.EDU with TCP; Fri 20 Nov 87 03:15:35-PST
Received: from CU20B.COLUMBIA.EDU by SRI-NIC.ARPA with TCP; Thu 19 Nov 87 21:38:12-PST
Date: Fri 20 Nov 87 00:37:31-EST
From: Ken Rossman <[email protected]>
Subject: Linking assembler subroutines with KCC programs
To: [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>
-------
22-Nov-87 03:14:01-PST,1043;000000000000
Return-Path: <[email protected]>
Received: from LEAR.STANFORD.EDU ([36.48.0.1]) by SRI-NIC.ARPA with TCP; Sun 22 Nov 87 03:13:54-PST
Date: Sun 22 Nov 87 03:13:03-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Nov-87 03:02:02
Message undelivered after 2 days -- will try for another 1 day:
*PS:<D.DAGONE>[email protected].#Internet: Disk quota exceeded
------------
Received: from Sierra.Stanford.EDU by LEAR.STANFORD.EDU with TCP; Fri 20 Nov 87 03:02:02-PST
Received: from SRI-NIC.ARPA by Sierra.Stanford.EDU with TCP; Fri 20 Nov 87 03:15:35-PST
Received: from CU20B.COLUMBIA.EDU by SRI-NIC.ARPA with TCP; Thu 19 Nov 87 21:38:12-PST
Date: Fri 20 Nov 87 00:37:31-EST
From: Ken Rossman <[email protected]>
Subject: Linking assembler subroutines with KCC programs
To: [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>
-------
23-Nov-87 03:12:15-PST,1903;000000000000
Return-Path: <[email protected]>
Received: from LEAR.STANFORD.EDU ([36.48.0.1]) by SRI-NIC.ARPA with TCP; Mon 23 Nov 87 03:12:09-PST
Date: Mon 23 Nov 87 03:12:24-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Nov-87 03:02:02
Message undeliverable and dequeued after 3 days:
*PS:<D.DAGONE>[email protected].#Internet: Disk quota exceeded
------------
Received: from Sierra.Stanford.EDU by LEAR.STANFORD.EDU with TCP; Fri 20 Nov 87 03:02:02-PST
Received: from SRI-NIC.ARPA by Sierra.Stanford.EDU with TCP; Fri 20 Nov 87 03:15:35-PST
Received: from CU20B.COLUMBIA.EDU by SRI-NIC.ARPA with TCP; Thu 19 Nov 87 21:38:12-PST
Date: Fri 20 Nov 87 00:37:31-EST
From: Ken Rossman <[email protected]>
Subject: Linking assembler subroutines with KCC programs
To: [email protected]
Address: 715 Watson Labs, 612 W. 115th St, NY NY 10025
Phone: (212) 280-4876
Message-ID: <[email protected]>
I'd like to be able to write an entirely separate assembler subroutine (in
MACRO) to be linked in with some KCC modules, and not have to use asm() if
possible. I have been fairly successful at getting this to work, except
that I would like to force the code to be placed in the TEXT segment. Is
there a way to do this? /Ken
P.S. -- If I let LINK put my MACRO module wherever it wants to, it will
stick it in the low segment (start address 140), which apparently blows
away some data that printf wants -- anyway, printf acts strangely. I've
forced the module to live at some hard address with LOC, but there must be
a better way.
P.P.S. -- Using the #asm/#endasm constructs, the right thing almost
happens. If I try to force the data storage in the MACRO source into the
DATA segment with %%DATA, the unpredictable printf behavior occurs again.
-------
-------
6-Jan-88 12:43:55-PST,2931;000000000000
Date: Wed, 6 Jan 88 12:43:44 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: PS:<MAIL.BULK>[--QUEUED-BULK-MAIL--].NEW-EXPLODE-134076672111.1
No such host as "BIONET-20.IG.COM",
bad queue file follows:
-------
=DELIVERY-OPTIONS:MAIL
=NOTIFY: 13-Jan-88 12:41
=DEQUEUE: 11-Jan-88 12:41
_SRI-NIC.ARPA
Bug-KCC-RELAY
SRI-NIC.ARPA
IAN
*SS:<C.DIST>BUG-KCC.MAIL
CS.COLUMBIA.EDU
Eppstein
Sierra.Stanford.EDU
WHP4
Grossman
AI.AI.MIT.EDU
ALAN
BIONET-20.IG.COM
Dautricourt
Relph
Will
SUN.COM
Gingell
SCIENCE.UTAH.EDU
Beebe
DECWRL.DEC.COM
kchen%imagen.uucp
XX.LCS.MIT.EDU
SRA
Date: Wed 6 Jan 88 12:41:47-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: PSECT support for KCC
To: mrc%[email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I don't know when the KCC-4 version will be absolutely complete. What
is holding things up is a minor problem with the C preprocessor. If I
had a few uninterrupted days I could fix it, but things will continue
to be VERY bad here until the end of January (official work takes
priority). The library is fine, and the binary compiler is fine, the
only issue is that of making the compiler source consistent with the
working binary. If you want to use it anyway (after all, that's what
we're doing here) you can get everything from SS:<KCC-4> plus
SYS:CC.EXE.0.
I like the idea of producing .REL files, but doubt it will happen
soon, unless someone wants to specifically pay for it. There are more
important problems like adding function prototypes. The 6 char
external limitation keeps coming up, but none of the other facts
change -- to ensure your code is portable you MUST make externals
unique in the first 6 monocase chars. Whether your own system, or
TOPS-20, supports longer names is irrelevant; you can't know what
other systems are out there that might depend on this. If you want
to import outside software that isn't as portable as it should be, or
want to use long identifiers for your own pleasure, you can #define
them to something short and unique (standard method). If you want to
use longer names for debugging, well, you'll have to upgrade IDDT (or
something) to understand the new symbol table format.
As for the choice of assembler, our own default is FAIL, and we don't
waste our time trying to make the distribution different from what we
actually run. Other sites are free to use a switch, or recompile, or
patch tgasm (it's documented).
As you might guess, there is no time to look at other programs such as
C Logo (however, if you have money... :-) I do think, though, that the
KCC-4 library will solve just about all of the problems you were
previously having.
--Ken
-------
-------
8-Feb-88 17:40:48-PST,811;000000000000
Return-Path: <[email protected]>
Received: from Sierra.Stanford.EDU by SRI-NIC.ARPA with TCP; Mon 8 Feb 88 17:40:46-PST
Date: Mon 8 Feb 88 17:34:56-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 7-Feb-88 17:10:29
Message undelivered after 1 day -- will try for another 2 days:
[email protected].#Internet: Cannot connect to host
------------
Received: from SRI-NIC.ARPA by Sierra.Stanford.EDU with TCP; Sun 7 Feb 88 17:10:31-PST
Date: Sun, 7 Feb 88 13:41:57 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: Bug with CC(583)
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
-------
16-Feb-88 05:46:11-PST,531;000000000000
Return-Path: <[email protected]>
Received: from ifi.UIO.NO by SRI-NIC.ARPA with TCP; Tue 16 Feb 88 05:46:01-PST
From: Rein Tollevik <[email protected]>
Date: Tue, 16 Feb 88 14:02:48 +0100
Message-Id: <[email protected]>
To: [email protected]
Subject: Please add me to the list
I am putting up KCC on our two -20's, and would like to be
added to the info-kcc mailing list. My email address is
[email protected]. Thanks.
Rein Tollevik
Institute of Informatics
University in Oslo
Norway
16-Feb-88 05:57:55-PST,579;000000000000
Mail-From: KLH created at 16-Feb-88 05:57:54
Date: Tue, 16 Feb 88 05:57:53 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: Please add me to the list
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
OK, you're now on INFO-KCC. Nothing much has happened lately, although
I am still hoping to get the 4th source distribution done soon (being
held up by lack of time). There will be a note on INFO-KCC when I
finally succeed...
--Ken
-------
29-Feb-88 02:34:09-PST,2388;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Mon 29 Feb 88 02:34:03-PST
Received: by Sun.COM (4.0/SMI-4.0)
id AB07894; Mon, 29 Feb 88 02:32:50 PST
Date: Mon, 29 Feb 88 02:32:50 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 Host mailhost not found for mailer sales.
550 gingell@opus... Host unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.0/SMI-4.0)
id AA06985; Sun, 28 Feb 88 21:48:38 PST
Date: Sun, 28 Feb 88 18:55:21 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: redirected stdout destroys existing files on "quota exceeded"
To: [email protected], [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Well, what SHOULD happen? "flame and abort" is imprecise. ITS does
this much better -- it generates an interrupt which DDT knows about,
and you can proceed once you have freed up enough stuff. This removes
the need for every program in the world to have its own
"check-for-overquota-error-and-tell-user-and-wait" routines.
In other words, this seems like a TOPS-20 problem to me. How could
OPENF and CLOSF destroy a file, anyway? If you have your gen-ret-count
set to 1, that's your mistake.
I agree the stdio functions should return an error if the output write()
fails, and the write() should fail if the SOUT%/BOUT% fails. That,
I can look into later. Note that most programs, however, never bother
to check the return value of putc or printf or any other output function.
Usual Unix brain damage.
Note that .ICQTA is bound to SIGXFSZ. It isn't being triggered presumably
because an ERJMP turns the error condition into a simple error return.
I could, however, cause it to be invoked, and this could either
(1) call a user-defined signal handler, if one was specified by signal(),
or (2) as a default action, "flame and abort" (whatever you want that to be).
It could presumably ask the user whether to continue or not, although it
may be hard to know whether that makes sense (there may not be a "user" and
the channel to use may not be obvious either).
-------
8-Mar-88 06:32:20-PST,808;000000000000
Return-Path: <[email protected]>
Received: from msr.epm.ornl.gov (ORNL-MSR.ARPA) by SRI-NIC.ARPA with TCP; Tue 8 Mar 88 06:32:14-PST
Received: by msr.epm.ornl.gov (5.51/4.9)
id AA12250; Tue, 8 Mar 88 09:31:57 EST
Date: Tue, 8 Mar 88 09:31:57 EST
From: [email protected] (Jeff Jones)
Message-Id: <[email protected]>
To: [email protected]
Subject: Change of mailing address
Please change the following address in your mailing list.
Old Address: [email protected]
New Address: [email protected] Numerical Address: 128.219.8.1
If possible, please confirm this message. It still can be confirmed to the
old address for a short period of time.
Thank You,
Jeff Jones
Martin Marietta Energy Systems, Inc.
Oak Ridge, Tn
(615)576-2335
14-Mar-88 03:31:24-PST,2215;000000000000
Date: Mon, 14 Mar 88 03:29:03 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 14-Mar-88 03:16:31
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Date: Mon, 14 Mar 88 03:16:22 PST
From: Ken Harrenstien <[email protected]>
Subject: New KCC binary available
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
My workload has eased up a bit and I'm now able to give a little more
attention to KCC. A new KCC binary (version 586) is available for
FTPing from SRI-NIC.ARPA. (Filename "SYS:CC.EXE", or "SYS:CCX.EXE"
for the extended version.) This primarily fixes a number of bugs that
have been reported recently, including:
(Bowman) sizeof of an array within a structure was wrong.
(KLH) Null statement in switch() was interpreted as break.
(Wancho) Yet another peephole optimizer bug.
(Beebe) Macro definition mistakenly collapsed blanks
within a string literal.
(Beebe) Macro invocations now treat newline as ordinary
whitespace (H&S was unclear on this).
(Wancho) Undefined identifiers in #if and #elif now have the value 0,
(as per ANSI) with a warning.
(KLH) Constant expression optimization was improved.
There are no currently outstanding bugs with the KCC compiler that I
am aware of. There are a few requested features that I will add in the
future as time permits, such as version numbering, PSECT support, and
the like.
The current C library (C:LIBC.REL) also has a couple of minor fixes,
notably a bugfix to system(). There are a few pending possible bugs
that I have yet to look into (mostly from Frank Wancho!) Once I have
done this and made any necessary changes to the documentation files, I
will finally put together the source release. This will include a new
library, LIBTMX, that provides portable date and time parsing routines
(no more IDTNC% needed). I have not been very successful with my time
estimates in the past, but I'll try again: if no new problems turn up
then things should be ready before the end of March.
--Ken
-------
-------
15-Mar-88 03:51:58-PST,864;000000000000
Return-Path: <[email protected]>
Received: from LEAR.STANFORD.EDU ([36.21.0.101]) by SRI-NIC.ARPA with TCP; Tue 15 Mar 88 03:51:53-PST
Date: Tue 15 Mar 88 03:49:01-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 14-Mar-88 03:20:20
Message undelivered after 1 day -- will try for another 2 days:
*PS:<D.DAGONE>[email protected].#Internet: Disk quota exceeded
------------
Received: from Sierra.Stanford.EDU by LEAR.STANFORD.EDU with TCP; Mon 14 Mar 88 03:20:21-PST
Received: from SRI-NIC.ARPA by Sierra.Stanford.EDU with TCP; Mon 14 Mar 88 03:20:49-PST
Date: Mon, 14 Mar 88 03:16:22 PST
From: Ken Harrenstien <[email protected]>
Subject: New KCC binary available
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
16-Mar-88 03:55:01-PST,864;000000000000
Return-Path: <[email protected]>
Received: from LEAR.STANFORD.EDU ([36.21.0.101]) by SRI-NIC.ARPA with TCP; Wed 16 Mar 88 03:54:58-PST
Date: Wed 16 Mar 88 03:47:31-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 14-Mar-88 03:20:20
Message undelivered after 2 days -- will try for another 1 day:
*PS:<D.DAGONE>[email protected].#Internet: Disk quota exceeded
------------
Received: from Sierra.Stanford.EDU by LEAR.STANFORD.EDU with TCP; Mon 14 Mar 88 03:20:21-PST
Received: from SRI-NIC.ARPA by Sierra.Stanford.EDU with TCP; Mon 14 Mar 88 03:20:49-PST
Date: Mon, 14 Mar 88 03:16:22 PST
From: Ken Harrenstien <[email protected]>
Subject: New KCC binary available
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
17-Mar-88 03:31:56-PST,2550;000000000000
Return-Path: <[email protected]>
Received: from LEAR.STANFORD.EDU ([36.21.0.101]) by SRI-NIC.ARPA with TCP; Thu 17 Mar 88 03:31:47-PST
Date: Thu 17 Mar 88 03:28:22-PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 14-Mar-88 03:20:20
Message undeliverable and dequeued after 3 days:
*PS:<D.DAGONE>[email protected].#Internet: Disk quota exceeded
------------
Received: from Sierra.Stanford.EDU by LEAR.STANFORD.EDU with TCP; Mon 14 Mar 88 03:20:21-PST
Received: from SRI-NIC.ARPA by Sierra.Stanford.EDU with TCP; Mon 14 Mar 88 03:20:49-PST
Date: Mon, 14 Mar 88 03:16:22 PST
From: Ken Harrenstien <[email protected]>
Subject: New KCC binary available
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
My workload has eased up a bit and I'm now able to give a little more
attention to KCC. A new KCC binary (version 586) is available for
FTPing from SRI-NIC.ARPA. (Filename "SYS:CC.EXE", or "SYS:CCX.EXE"
for the extended version.) This primarily fixes a number of bugs that
have been reported recently, including:
(Bowman) sizeof of an array within a structure was wrong.
(KLH) Null statement in switch() was interpreted as break.
(Wancho) Yet another peephole optimizer bug.
(Beebe) Macro definition mistakenly collapsed blanks
within a string literal.
(Beebe) Macro invocations now treat newline as ordinary
whitespace (H&S was unclear on this).
(Wancho) Undefined identifiers in #if and #elif now have the value 0,
(as per ANSI) with a warning.
(KLH) Constant expression optimization was improved.
There are no currently outstanding bugs with the KCC compiler that I
am aware of. There are a few requested features that I will add in the
future as time permits, such as version numbering, PSECT support, and
the like.
The current C library (C:LIBC.REL) also has a couple of minor fixes,
notably a bugfix to system(). There are a few pending possible bugs
that I have yet to look into (mostly from Frank Wancho!) Once I have
done this and made any necessary changes to the documentation files, I
will finally put together the source release. This will include a new
library, LIBTMX, that provides portable date and time parsing routines
(no more IDTNC% needed). I have not been very successful with my time
estimates in the past, but I'll try again: if no new problems turn up
then things should be ready before the end of March.
--Ken
-------
-------
24-Mar-88 16:59:14-PST,801;000000000000
Date: Thu, 24 Mar 88 16:55:56 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 24-Mar-88 12:30:45
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Received: from TOPS20.DEC.COM by SRI-NIC.ARPA with TCP; Thu 24 Mar 88 12:30:34-PST
Date: 24 Mar 1988 1530-EST
From: "Andy Puchrik" <[email protected]>
To: [email protected]
DTN: "297-7157 (617-467-7157)"
Loc/MS: "MRO1-2/L14 (Pole M13)"
Subject: monsym_*.h
Message-ID: <"MS11(6040)+GLXLIB6(0)" 12384955091.24.321.180267 at TOPS20.DEC.COM>
Where does one find the files monsym_[c,f,g,m,p,r,s].h? I'm trying to
compile system.c of the make utility.
Thanks,
asp
--------
-------
24-Mar-88 17:04:16-PST,789;000000000000
Date: Thu, 24 Mar 88 17:01:13 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 24-Mar-88 12:36:27
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Date: Thu, 24 Mar 88 12:36:13 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: monsym_*.h
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <"MS11(6040)+GLXLIB6(0)" 12384955091.24.321.180267 at TOPS20.DEC.COM>
Message-ID: <[email protected]>
Check with the author, Nelson H.F. Beebe ([email protected]).
Bug reports and the like should be addressed to BUG-KCC@SRI-NIC rather
than INFO-KCC, by the way.
-------
-------
4-Apr-88 14:16:33-PDT,332;000000000000
Date: Mon, 4 Apr 88 14:16:21 PDT
From: The Mail System <[email protected]>
To: List Maintainer <[email protected]>
Subject: Error in mailing list
There is an unknown hostname in the "bug-kcc-RELAY" mailing list.
The incorrect entry is for: "kchen%[email protected]"
Please fix it,
Thanks.
-------
4-Apr-88 19:07:48-PDT,332;000000000000
Date: Mon, 4 Apr 88 19:07:31 PDT
From: The Mail System <[email protected]>
To: List Maintainer <[email protected]>
Subject: Error in mailing list
There is an unknown hostname in the "bug-kcc-RELAY" mailing list.
The incorrect entry is for: "kchen%[email protected]"
Please fix it,
Thanks.
-------
9-Apr-88 07:57:07-PDT,755;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Sat 9 Apr 88 07:57:03-PDT
Received: from snail.sun.com by Sun.COM (4.0/SMI-4.0)
id AA06566; Sat, 9 Apr 88 07:57:03 PDT
Received: from opus.sun.com by snail.sun.com (4.0/SMI-3.2)
id AA13756; Sat, 9 Apr 88 07:56:38 PDT
Received: by opus.sun.com (4.0/SMI-4.0Beta)
id AA02123; Sat, 9 Apr 88 07:58:03 PDT
Date: Sat, 9 Apr 88 07:58:03 PDT
From: [email protected] (Rob Gingell)
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: Remove from aliases
Please remove me from the BUG-KCC and INFO-KCC lists. Over the years
my use of KCC has dropped to nil. Good luck for continued success with
it!
11-Apr-88 13:57:07-PDT,415;000000000000
Mail-From: KLH created at 11-Apr-88 13:55:50
Date: Mon, 11 Apr 88 13:55:49 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: Remove from aliases
To: [email protected], [email protected],
[email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
OK, I'll take you off. See you around...
-------
11-Apr-88 15:20:08-PDT,502;000000000000
Mail-From: KLH created at 11-Apr-88 15:20:05
Date: Mon, 11 Apr 88 15:20:05 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: Change of mailing address
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I had some problems changing your address (came at a time when the
hostname info was in transition, I think). Anyway, here's your
confirmation...
-------
20-Apr-88 07:50:19-PDT,330;000000000000
Date: Wed, 20 Apr 88 07:50:14 PDT
From: The Mail System <[email protected]>
To: List Maintainer <[email protected]>
Subject: Error in mailing list
There is an unknown hostname in the "info-kcc-RELAY" mailing list.
The incorrect entry is for: "[email protected]"
Please fix it,
Thanks.
-------
20-Apr-88 08:02:12-PDT,4405;000000000000
Date: Wed, 20 Apr 88 08:01:17 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Apr-88 07:50:15
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Date: Wed, 20 Apr 88 07:50:05 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC-5 now available!
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
The latest KCC sources are now (finally -- gasp) available in a new
distribution, KCC-5. People with FTP access to SRI-NIC.ARPA should, as
usual, retrieve everything in the directory that KCCDIST: points to,
which is now <KCC-5>. If you need help, first try retrieving the files
KCCDIST:OBTAIN.DOC and KCCDIST:INSTAL.DOC.
People without FTP access should contact me directly about getting a new
tape sent. They can also get a little more information by sending a message
to [email protected] with the string "SEND KCCDIST:OBTAIN.DOC" in the
subject field.
Here is a summary of what's new, taken from the NEWS.TXT file. Note
that if you never got a binary version of the KCC-4 distribution (it was
never released in source form) then there are a great many more
improvements you are missing.
Enjoy!
--Ken
---------------------------
04/20/88 KCC 599, LIBC 219: <2,,2> Fifth formal distribution snapshot
General:
Several new routines, features, and packages have been added.
The various *.DOC files have been improved somewhat, and as usual there
have been some bug fixes both to KCC (primarily the optimizer) and the
library.
KCC:
As KCC sees wider and heavier use, progressively more obscure
over-optimization bugs get shaken out. The arcane details are
unsuitable for listing here, but many thanks are due to those people who
found and reported them!
In addition to bug fixes, some internal cleanup was done to
improve constant folding, regain more stack space, and remove the
previously fixed limitation on parse tree size. Most of these changes are
not externally visible, but some that are:
Error message output has been improved. Although little mousy
errors still tend to panic KCC into a long series of hysterical
screams, the messages themselves are more compact, more informative, and
more well-structured.
__COMPILER_KCC__ now exists as the sole KCC-dependent predefined
macro, so that portable programs can readily determine whether
KCC's <c-env.h> file, in particular, is available or not.
The entry vector is now 3 words to allow for a binary
version number to be put in the 3rd word.
Of great interest to systems programmers will be two new
built-in functions, _KCCsymfnd and _KCCsymval, which can obtain constant
symbol values from .UNV files at compile time. <monsym.h> uses them to
provide a macro which gives very efficient access to all monitor
symbols.
KCC now has an "-i=psect" switch to provide rudimentary support
for loading PSECT code.
LIBC:
The C startup code now recognizes arguments of the form "@file" as
being indirect file specifications; the file is read and parsed into further
arguments. This applies to all C programs including KCC, and provides a way
of getting around RSCAN buffer size limitations.
modf() was changed to conform to the description in V7, ANSI,
and BSD; the description in H&S (CARM) appears to be wrong.
The O_SYSFD flag was added to open(), to allow opening a FD with
an existing JFN.
open() has been changed so that when opening a new file for
writing, it actually does an immediate CLOSF% and another OPENF%. This
ensures that the file immediately exists and is visible, thus avoiding
a number of problems (invalid simultaneous access, file busy, etc) that
are hard to deal with otherwise. The side effect of this is that if
the process is killed before it finishes, its output files will exist
with zero length, whereas before they would not exist at all.
printf(), fprintf() and sprintf() now finally return the number
of characters they output; this will be -1 if an error occurred.
The Un*x functions isatty() and ttyname() are provided.
The TERMCAP functions now exist as LIBTRM.
Fully portable time parsing and manipulation routines are
provided in LIBTMX; see LIBTMX.DOC.
---------------------------
-------
-------
26-Apr-88 08:08:10-PDT,498;000000000000
Return-Path: <[email protected]>
Received: from csli.stanford.edu by SRI-NIC.ARPA with TCP; Tue 26 Apr 88 08:07:23-PDT
Received: from localhost by csli.stanford.edu (3.2/4.7); Tue, 26 Apr 88 08:11:23 PDT
To: [email protected]
Subject: address change
Date: Tue, 26 Apr 88 08:11:20 PDT
From: Bill Palmer <[email protected]>
Please change any lists relating to kcc so that my address is
[email protected], not [email protected].
thanks,
Bill
26-Apr-88 13:49:30-PDT,445;000000000000
Mail-From: KLH created at 26-Apr-88 13:49:08
Date: Tue, 26 Apr 88 13:49:07 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: address change
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: Message from "Bill Palmer <[email protected]>" of Tue, 26 Apr 88 08:08:07 PDT
Message-ID: <[email protected]>
OK, I've made the change (on both INFO-KCC and BUG-KCC).
-------
27-Apr-88 11:29:28-PDT,988;000000000000
Date: Wed, 27 Apr 88 11:27:26 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 26-Apr-88 18:42:47
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Date: Tue, 26 Apr 88 18:42:40 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 601 available
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Just a minor optimization bug fix. Since this came up so soon after
putting together the KCC-5 release, I took the time to retrofit the
changes into the source distribution.
I also added one new file, "KCCDIST:-FTP-.MIC", which is intended to
make it easier for people to FTP things. Get that file first, edit it
as necessary, and execute it to get the rest.
If you don't want sources, all you need to update from version 599 is
SYS:CC.EXE (and/or CCX.EXE).
-------
-------
27-Apr-88 11:47:39-PDT,5966;000000000000
Return-Path: <[email protected]>
Received: from uunet.UU.NET by SRI-NIC.ARPA with TCP; Wed 27 Apr 88 11:47:24-PDT
Received: from enea.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA11346; Wed, 27 Apr 88 14:47:21 EDT
Received: by enea.se (5.57++/1.21)
id AA19575; Wed, 27 Apr 88 19:47:09 +0200 (MET)
Received: by zyx.SE (13.1/smail2.2/02-27-88)
id AA17935; Wed, 27 Apr 88 18:17:14 met
Date: Wed, 20 Apr 88 07:50:05 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 PEM... User unknown
----- Unsent message follows -----
Received: by zyx.SE (13.1/smail2.2/02-27-88)
id AA17921; Wed, 27 Apr 88 18:17:14 met
Received: by enea.se (5.57++/1.21)
id AA24374; Wed, 27 Apr 88 00:49:47 +0200 (MET)
Received: from kth.se by ttds.tds.kth.se (4.40/kth-1.65)
id AA01609; Tue, 26 Apr 88 22:38:53 -0100 (MET)
Received: from rtr59b.kth.se by kth.se (5.57+IDA+KTH/SiteCap-3.0)
id AA02677; Tue, 26 Apr 88 23:35:38 +0200
Received: from BMC1.#DECnet by rtr59b.kth.se; Tue, 26 Apr 88 23:34 MED
Received: from TCP-DAEMON by bmc1.UU.SE; Tue, 26 Apr 88 23:34 MET
Received: from bmc1.UU.SE by AIDA with TCP; Tue 26 Apr 88 23:30:23
Received: from RTR59B.#DECnet by bmc1.UU.SE; Tue, 26 Apr 88 15:18 MET
Received: from TCP-DAEMON by rtr59b.kth.se; Sun, 24 Apr 88 21:01 MED
Received: from ttds.tds.kth.se by kth.se (5.57+IDA+KTH/SiteCap-3.0) id AA11431;
Sun, 24 Apr 88 20:35:39 +0200
Received: by ttds.tds.kth.se (4.40/kth-1.65) id AA28858; Sun, 24 Apr 88
19:38:27 -0100 (MET)
Received: by enea.se (5.57++/1.21) id AA21298; Sun, 24 Apr 88 18:57:43 +0200
(MET)
Received: from SRI-NIC.ARPA by uunet.UU.NET (5.54/1.14) id AA16562; Wed, 20 Apr
88 17:32:32 EDT
Date: Wed, 20 Apr 88 07:50:05 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC-5 now available!
To: [email protected]
Cc: [email protected]
Message-Id: <[email protected]>
The latest KCC sources are now (finally -- gasp) available in a new
distribution, KCC-5. People with FTP access to SRI-NIC.ARPA should, as
usual, retrieve everything in the directory that KCCDIST: points to,
which is now <KCC-5>. If you need help, first try retrieving the files
KCCDIST:OBTAIN.DOC and KCCDIST:INSTAL.DOC.
People without FTP access should contact me directly about getting a new
tape sent. They can also get a little more information by sending a message
to [email protected] with the string "SEND KCCDIST:OBTAIN.DOC" in the
subject field.
Here is a summary of what's new, taken from the NEWS.TXT file. Note
that if you never got a binary version of the KCC-4 distribution (it was
never released in source form) then there are a great many more
improvements you are missing.
Enjoy!
--Ken
---------------------------
04/20/88 KCC 599, LIBC 219: <2,,2> Fifth formal distribution snapshot
General:
Several new routines, features, and packages have been added.
The various *.DOC files have been improved somewhat, and as usual there
have been some bug fixes both to KCC (primarily the optimizer) and the
library.
KCC:
As KCC sees wider and heavier use, progressively more obscure
over-optimization bugs get shaken out. The arcane details are
unsuitable for listing here, but many thanks are due to those people who
found and reported them!
In addition to bug fixes, some internal cleanup was done to
improve constant folding, regain more stack space, and remove the
previously fixed limitation on parse tree size. Most of these changes are
not externally visible, but some that are:
Error message output has been improved. Although little mousy
errors still tend to panic KCC into a long series of hysterical
screams, the messages themselves are more compact, more informative, and
more well-structured.
__COMPILER_KCC__ now exists as the sole KCC-dependent predefined
macro, so that portable programs can readily determine whether
KCC's <c-env.h> file, in particular, is available or not.
The entry vector is now 3 words to allow for a binary
version number to be put in the 3rd word.
Of great interest to systems programmers will be two new
built-in functions, _KCCsymfnd and _KCCsymval, which can obtain constant
symbol values from .UNV files at compile time. <monsym.h> uses them to
provide a macro which gives very efficient access to all monitor
symbols.
KCC now has an "-i=psect" switch to provide rudimentary support
for loading PSECT code.
LIBC:
The C startup code now recognizes arguments of the form "@file" as
being indirect file specifications; the file is read and parsed into further
arguments. This applies to all C programs including KCC, and provides a way
of getting around RSCAN buffer size limitations.
modf() was changed to conform to the description in V7, ANSI,
and BSD; the description in H&S (CARM) appears to be wrong.
The O_SYSFD flag was added to open(), to allow opening a FD with
an existing JFN.
open() has been changed so that when opening a new file for
writing, it actually does an immediate CLOSF% and another OPENF%. This
ensures that the file immediately exists and is visible, thus avoiding
a number of problems (invalid simultaneous access, file busy, etc) that
are hard to deal with otherwise. The side effect of this is that if
the process is killed before it finishes, its output files will exist
with zero length, whereas before they would not exist at all.
printf(), fprintf() and sprintf() now finally return the number
of characters they output; this will be -1 if an error occurred.
The Un*x functions isatty() and ttyname() are provided.
The TERMCAP functions now exist as LIBTRM.
Fully portable time parsing and manipulation routines are
provided in LIBTMX; see LIBTMX.DOC.
---------------------------
-------
28-Apr-88 02:49:46-PDT,2549;000000000000
Return-Path: <[email protected]>
Received: from uunet.UU.NET by SRI-NIC.ARPA with TCP; Thu 28 Apr 88 02:49:41-PDT
Received: from enea.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA20053; Thu, 28 Apr 88 05:49:41 EDT
Received: by enea.se (5.57++/1.21)
id AA08125; Thu, 28 Apr 88 11:23:10 +0200 (MET)
Received: by zyx.SE (13.1/smail2.2/02-27-88)
id AA29681; Thu, 28 Apr 88 11:05:57 met
Date: Tue, 26 Apr 88 18:42:40 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 PEM... User unknown
----- Unsent message follows -----
Received: by zyx.SE (13.1/smail2.2/02-27-88)
id AA29677; Thu, 28 Apr 88 11:05:57 met
Received: by enea.se (5.57++/1.21)
id AA01867; Thu, 28 Apr 88 07:12:36 +0200 (MET)
Received: from kth.se by ttds.tds.kth.se (4.40/kth-1.65)
id AA04010; Wed, 27 Apr 88 21:25:37 -0100 (MET)
Received: from rtr59b.kth.se by kth.se (5.57+IDA+KTH/SiteCap-3.0)
id AA07818; Wed, 27 Apr 88 22:22:21 +0200
Received: from BMC1.#DECnet by rtr59b.kth.se; Wed, 27 Apr 88 22:21 MED
Received: from TCP-DAEMON by bmc1.UU.SE; Wed, 27 Apr 88 22:20 MET
Received: from bmc1.UU.SE by AIDA with TCP; Wed 27 Apr 88 22:20:02
Received: from RTR59B.#DECnet by bmc1.UU.SE; Wed, 27 Apr 88 22:19 MET
Received: from TCP-DAEMON by rtr59b.kth.se; Wed, 27 Apr 88 22:17 MED
Received: from ttds.tds.kth.se by kth.se (5.57+IDA+KTH/SiteCap-3.0) id AA07758;
Wed, 27 Apr 88 22:17:25 +0200
Received: by ttds.tds.kth.se (4.40/kth-1.65) id AA03817; Wed, 27 Apr 88
21:20:19 -0100 (MET)
Received: by enea.se (5.57++/1.21) id AA20833; Wed, 27 Apr 88 20:58:14 +0200
(MET)
Received: from SRI-NIC.ARPA by uunet.UU.NET (5.54/1.14) id AA10344; Wed, 27 Apr
88 14:25:29 EDT
Date: Tue, 26 Apr 88 18:42:40 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 601 available
To: [email protected]
Cc: [email protected]
Message-Id: <[email protected]>
Just a minor optimization bug fix. Since this came up so soon after
putting together the KCC-5 release, I took the time to retrofit the
changes into the source distribution.
I also added one new file, "KCCDIST:-FTP-.MIC", which is intended to
make it easier for people to FTP things. Get that file first, edit it
as necessary, and execute it to get the rest.
If you don't want sources, all you need to update from version 599 is
SYS:CC.EXE (and/or CCX.EXE).
-------
30-Apr-88 03:59:43-PDT,1445;000000000000
Date: Sat, 30 Apr 88 03:57:08 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 29-Apr-88 17:47:09
Message failed for the following:
[email protected]: 550 No such local mailbox as "G.PRS", recipient rejected
------------
Date: Fri, 29 Apr 88 17:21:43 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 602
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Another optimization bugfix (glitch when optimizing some exprs of the form
array[0][x]). Since the source change is trivial I'm including it to
reduce overhead for people who maintain sources. Binaries available as
usual.
;COMPARISON OF PS:<C.KCC.CC>CCFOLD.C.115 AND PS:<C.KCC.CC>CCFOLD.C.116
;OPTIONS ARE /3
**** FILE PS:<C.KCC.CC>CCFOLD.C.115, 7-209 (19134)
&& e->Nright->Niconst == 0) /* (because 0+e already commuted) */
return e->Nleft; /* Won, e+0 or e-0 !! */
**** FILE PS:<C.KCC.CC>CCFOLD.C.116, 7-209 (19134)
&& e->Nright->Niconst == 0) { /* (because 0+e already commuted) */
/* Won, e+0 or e-0 !! But beware of funny array type conversion
** sometimes applied to plus/minus pointer arithmetic; result type
** may not be same as operand type. Keep result type.
*/
e->Nleft->Ntype = e->Ntype; /* Propagate result type */
return e->Nleft;
}
***************
-------
-------
3-May-88 19:28:36-PDT,2127;000000000000
Return-Path: <[email protected]>
Received: from oldsierra.STANFORD.EDU by SRI-NIC.ARPA with TCP; Tue, 3 May 88 19:27:41 PDT
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Tue, 3 May 88 19:17:55 PDT
Date: Tue, 3 May 88 19:17:55 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To: <[email protected]>
----- Transcript of session follows -----
>>> RCPT To:<Grossman@SIERRA>
<<< 550 <Grossman@SIERRA>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Tue, 3 May 88 19:17:55 PDT
Received: from MCC.COM by SRI-NIC.ARPA with TCP; Sun 1 May 88 07:29:03-PDT
Date: Sun 1 May 88 09:29:14-CDT
From: Clive Dawson <[email protected]>
Subject: KCC Logical name bug
To: [email protected]
Cc: [email protected]
Message-Id: <[email protected]>
Ken-
I've started playing with KCC in order to get SRA's domain
resolver running.
I ran into an interesting problem which took a bit of digging to
track down. As a newcomer, I don't know if this has been covered
on this list before, but in any case it's probably worth a bug-fix,
or at the very least a warning in the INSTAL.DOC file.
I had C: defined to be <KCC.INCLUDE>. Attempts to compile
anything with an Include statement of the form
#include <sys/filename>
failed. I took a look at the GTJFN and noticed it was using a
filespec of the form
<KCC.INCLUDE>:<KCC.INCLUDE.sys>types.h
which indicated that the logical name expansion was getting screwed
up. Sometime later in the depths of OPEN, _GET_TRICKY, etc., I
discovered that the logical definition of C: had better have
an explicit device.
I changed C: to be PS:<KCC.INCLUDE> and all works fine now.
Hmmmm...A warning in INSTAL.DOC would help make sure that the
system-wide definition is right, but it wouldn't protect users who get
"sloppy" with job-wide definitions of C:, etc.
Cheers,
Clive Dawson
-------
3-May-88 22:58:18-PDT,3027;000000000000
Return-Path: <[email protected]>
Received: from uunet.UU.NET by SRI-NIC.ARPA with TCP; Tue, 3 May 88 22:57:56 PDT
Received: from enea.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA07723; Wed, 4 May 88 01:58:06 EDT
Received: by enea.se (5.57++/1.23)
id AA14334; Wed, 4 May 88 05:20:19 +0200 (MET)
Received: by zyx.SE (13.1/smail2.2/02-27-88)
id AA28748; Wed, 4 May 88 05:12:42 met
Date: Fri, 29 Apr 88 17:21:43 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 PEM... User unknown
----- Unsent message follows -----
Received: by zyx.SE (13.1/smail2.2/02-27-88)
id AA28742; Wed, 4 May 88 05:12:42 met
Received: by enea.se (5.57++/1.23)
id AA14677; Tue, 3 May 88 20:17:36 +0200 (MET)
Received: from kth.se by ttds.tds.kth.se (4.40/kth-1.65)
id AA09174; Tue, 3 May 88 19:00:13 -0100 (MET)
Received: from rtr59b.kth.se by kth.se (5.57+IDA+KTH/SiteCap-3.0)
id AA01188; Tue, 3 May 88 19:56:55 +0200
Received: from BMC1.#DECnet by rtr59b.kth.se; Tue, 3 May 88 19:54 MED
Received: from TCP-DAEMON by bmc1.BMC.UU.SE; Tue, 3 May 88 19:56 MET
Received: from bmc1.BMC.UU.SE (BMC1.#Internet) by AIDA with TCP; Tue 3 May 88
19:55:14
Received: from RTR59B.#DECnet by bmc1.BMC.UU.SE; Sat, 30 Apr 88 17:17 MET
Received: from TCP-DAEMON by rtr59b.kth.se; Sat, 30 Apr 88 17:14 MED
Received: from ttds.tds.kth.se by kth.se (5.57+IDA+KTH/SiteCap-3.0) id AA13582;
Sat, 30 Apr 88 17:16:06 +0200
Received: by ttds.tds.kth.se (4.40/kth-1.65) id AA14886; Sat, 30 Apr 88
16:19:07 -0100 (MET)
Received: by enea.se (5.57++/1.22) id AA00770; Sat, 30 Apr 88 15:50:29 +0200
(MET)
Received: from SRI-NIC.ARPA by uunet.UU.NET (5.54/1.14) id AA21819; Sat, 30 Apr
88 06:56:36 EDT
Date: Fri, 29 Apr 88 17:21:43 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 602
To: [email protected]
Cc: [email protected]
Message-Id: <[email protected]>
Another optimization bugfix (glitch when optimizing some exprs of the form
array[0][x]). Since the source change is trivial I'm including it to
reduce overhead for people who maintain sources. Binaries available as
usual.
;COMPARISON OF PS:<C.KCC.CC>CCFOLD.C.115 AND PS:<C.KCC.CC>CCFOLD.C.116
;OPTIONS ARE /3
**** FILE PS:<C.KCC.CC>CCFOLD.C.115, 7-209 (19134)
&& e->Nright->Niconst == 0) /* (because 0+e already commuted) */
return e->Nleft; /* Won, e+0 or e-0 !! */
**** FILE PS:<C.KCC.CC>CCFOLD.C.116, 7-209 (19134)
&& e->Nright->Niconst == 0) { /* (because 0+e already commuted) */
/* Won, e+0 or e-0 !! But beware of funny array type conversion
** sometimes applied to plus/minus pointer arithmetic; result type
** may not be same as operand type. Keep result type.
*/
e->Nleft->Ntype = e->Ntype; /* Propagate result type */
return e->Nleft;
}
***************
-------
5-May-88 12:15:39-PDT,5371;000000000000
Return-Path: <[email protected]>
Received: from oldsierra.STANFORD.EDU by SRI-NIC.ARPA with TCP; Thu, 5 May 88 12:15:14 PDT
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:04:58 PDT
Date: Thu, 5 May 88 12:04:58 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To: <[email protected]>
----- Transcript of session follows -----
>>> RCPT To:<Grossman@SIERRA>
<<< 550 <Grossman@SIERRA>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:04:58 PDT
Received: from SCIENCE.UTAH.EDU by SRI-NIC.ARPA with TCP; Thu, 5 May 88 09:35:29 PDT
Date: Wed 4 May 88 19:30:01-MDT
From: "Nelson H.F. Beebe" <[email protected]>
Subject: ungetc() doesn't backup file pointer for ftell()
To: [email protected]
Cc: [email protected]
X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-Id: <[email protected]>
In KCC 4 and 5, ungetc() doesn't backup the file pointer for
ftell(); it did so correctly in KCC 3. This prevents my TeX
DVI drivers from running with KCC 4 or 5.
Here is a PHOTO log with a simple test program; the file it
reads can be any 8-bit file you like.
[PHOTO: Recording initiated Wed 4-May-88 7:22PM]
TOPS-20 Command processor 5(712)
@type bug2.c
-------------------
APS:<BEEBE>BUG2.C.2
-------------------
#include <stdio.h>
int
main(argc,argv)
int argc;
char* argv[];
{
FILE* fp;
long k;
long p;
int c;
fp = fopen("APS:<TEX.CM>CMBX12.300PK","rb8");
for (k = 0; k < 256; k += 15)
{
fseek(fp,k,0);
c = getc(fp);
ungetc(c,fp);
p = ftell(fp);
if (p != k)
printf("ungetc() failure: fseek to %ld, ftell says %ld, byte = 0
%o\n",
k,p,c);
}
fclose(fp);
return (0);
}
@v c:kcc.exe
FES:<KCC-5>
KCC.EXE.602;P777752 170 87040(36) 29-Apr-88 18:09:17 BEEBE
@bug2
ungetc() failure: fseek to 0, ftell says 1, byte = 0367
ungetc() failure: fseek to 15, ftell says 16, byte = 0165
ungetc() failure: fseek to 30, ftell says 31, byte = 046
ungetc() failure: fseek to 45, ftell says 46, byte = 0376
ungetc() failure: fseek to 60, ftell says 61, byte = 047
ungetc() failure: fseek to 75, ftell says 76, byte = 0362
ungetc() failure: fseek to 90, ftell says 91, byte = 0174
ungetc() failure: fseek to 105, ftell says 106, byte = 0102
ungetc() failure: fseek to 120, ftell says 121, byte = 0151
ungetc() failure: fseek to 135, ftell says 136, byte = 0172
ungetc() failure: fseek to 150, ftell says 151, byte = 0345
ungetc() failure: fseek to 165, ftell says 166, byte = 0300
ungetc() failure: fseek to 180, ftell says 181, byte = 0142
ungetc() failure: fseek to 195, ftell says 196, byte = 0327
ungetc() failure: fseek to 210, ftell says 211, byte = 041
ungetc() failure: fseek to 225, ftell says 226, byte = 050
ungetc() failure: fseek to 240, ftell says 241, byte = 015
ungetc() failure: fseek to 255, ftell says 256, byte = 0153
@
@def c: cold:
@v cold:kcc
PS:<SUBSYS.KCC3>
KCC.EXE.561;P777752 147 75264(36) 11-May-87 17:55:00 KLH@SRI-NIC
.INFO.4;P777752 39 98567(7) 16-May-87 10:52:57 BEEBE
.TECO.1;P777752 1 165(7) 12-Feb-87 12:35:41 BEEBE
.VMSHELP.6;P777752 36 90179(7) 16-May-87 10:52:22 BEEBE
Total of 223 pages in 4 files
@del bug2.rel
BUG2.REL.1 [OK]
@kcc bug2
KCC: bug2
<BEEBE>BUG2.PRE.1
<BEEBE>BUG2.FAI.1
FAIL: bug2
LINK: Loading
@bug2
@! That was KCC version 3
@
@def c:
@v c:kcc.exe
PS:<SUBSYS.KCC>
KCC.EXE.586;P777752 158 80896(36) 9-Mar-88 19:03:02 KLH
.590;P777752 160 81920(36) 8-Apr-88 05:18:30 BEEBE
.593;P777752 165 84480(36) 15-Apr-88 03:33:14 BEEBE
Total of 483 pages in 3 files
@kcc bug2
KCC: bug2
<BEEBE>BUG2.PRE.1
<BEEBE>BUG2.FAI.1
FAIL: bug2
LINK: Loading
@bug2
ungetc() failure: fseek to 0, ftell says 1, byte = 0367
ungetc() failure: fseek to 15, ftell says 16, byte = 0165
ungetc() failure: fseek to 30, ftell says 31, byte = 046
ungetc() failure: fseek to 45, ftell says 46, byte = 0376
ungetc() failure: fseek to 60, ftell says 61, byte = 047
ungetc() failure: fseek to 75, ftell says 76, byte = 0362
ungetc() failure: fseek to 90, ftell says 91, byte = 0174
ungetc() failure: fseek to 105, ftell says 106, byte = 0102
ungetc() failure: fseek to 120, ftell says 121, byte = 0151
ungetc() failure: fseek to 135, ftell says 136, byte = 0172
ungetc() failure: fseek to 150, ftell says 151, byte = 0345
ungetc() failure: fseek to 165, ftell says 166, byte = 0300
ungetc() failure: fseek to 180, ftell says 181, byte = 0142
ungetc() failure: fseek to 195, ftell says 196, byte = 0327
ungetc() failure: fseek to 210, ftell says 211, byte = 041
ungetc() failure: fseek to 225, ftell says 226, byte = 050
ungetc() failure: fseek to 240, ftell says 241, byte = 015
ungetc() failure: fseek to 255, ftell says 256, byte = 0153
@! That was KCC version 4
@pop
[PHOTO: Recording terminated Wed 4-May-88 7:25PM]
-------
5-May-88 12:17:24-PDT,1951;000000000000
Return-Path: <[email protected]>
Received: from oldsierra.STANFORD.EDU by SRI-NIC.ARPA with TCP; Thu, 5 May 88 12:17:15 PDT
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:07:05 PDT
Date: Thu, 5 May 88 12:07:05 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To: <[email protected]>
----- Transcript of session follows -----
>>> RCPT To:<Grossman@SIERRA>
<<< 550 <Grossman@SIERRA>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:07:05 PDT
Date: Thu, 5 May 88 09:50:20 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: ungetc() doesn't backup file pointer for ftell()
To: [email protected], [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
The value of ftell() when there are ungetc'd chars to be read is
unspecified in H&S and previous versions of the ANSI draft. The latest
draft has this to say:
"For a text stream, the value of its file position indicator after a successful
call to the ungetc function is unspecified until all pushed-back characters are
read or discarded. For a binary stream, its file position indicator is
decremented by each successful call to the ungetc function; if its value was
zero before a call, it is indeterminate after the call."
We haven't gotten around to doing much about ANSI, really; I don't think it
is wise to rely on anything in that draft until they really pass it as a
standard. (For example, I heartily hope that they come to their senses and
flush the "noalias" abomination.)
But since you already depended on something that the draft now supports, I will
take a look at it.
-------
5-May-88 12:19:31-PDT,2187;000000000000
Return-Path: <[email protected]>
Received: from oldsierra.STANFORD.EDU by SRI-NIC.ARPA with TCP; Thu, 5 May 88 12:19:17 PDT
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:09:09 PDT
Date: Thu, 5 May 88 12:09:09 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To: <[email protected]>
----- Transcript of session follows -----
>>> RCPT To:<Grossman@SIERRA>
<<< 550 <Grossman@SIERRA>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:09:09 PDT
Received: from SCIENCE.UTAH.EDU by SRI-NIC.ARPA with TCP; Thu, 5 May 88 10:23:23 PDT
Date: Thu 5 May 88 11:22:46-MDT
From: "Nelson H.F. Beebe" <[email protected]>
Subject: Re: ungetc() doesn't backup file pointer for ftell()
To: [email protected], [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
X-Us-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-Id: <[email protected]>
>> "For a binary stream, its file position indicator is
>> decremented by each successful call to the ungetc function;
>> if its value was zero before a call, it is indeterminate
>> after the call."
This implies in my case that ftell() must work. Without
this feature, it is absolutely impossible to process TeX DVI
and font files, because reading of unbounded sequences is
necessary; the input determines when you have read too far,
and then you have to do an ungetc() so that a subsequent
ftell() tells you where you are. Because ftell() is
permitted to return a magic cookie that is not the byte
position, you cannot add -1 to the ftell() value to get the
real pointer if ungetc() fails to reset it. Actually, any
system that returns a magic cookie instead of a byte
position will be unusable for TeX DVI and font files, too,
because they both contain byte pointers into themselves.
-------
5-May-88 12:21:20-PDT,1472;000000000000
Return-Path: <[email protected]>
Received: from oldsierra.STANFORD.EDU by SRI-NIC.ARPA with TCP; Thu, 5 May 88 12:21:10 PDT
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:10:45 PDT
Date: Thu, 5 May 88 12:10:45 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To: <[email protected]>
----- Transcript of session follows -----
>>> RCPT To:<Grossman@SIERRA>
<<< 550 <Grossman@SIERRA>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:10:45 PDT
Received: from THOR.HPL.HP.COM by SRI-NIC.ARPA with TCP; Thu, 5 May 88 10:31:38 PDT
Mail-From: WHITE created at 5-May-88 10:00:51
Date: Thu 5 May 88 10:00:51-PDT
From: Vic White <[email protected]>
Subject: LIBTRM and LIBTMX
To: Bug-KCC@SRI-NIC
Cc: [email protected]
Message-Id: <[email protected]>
Resent-Date: Thu 5 May 88 10:29:16-PDT
Resent-From: Vic White <[email protected]>
Resent-To: Bug-KCC@SRI-NIC
Resent-Message-Id: <[email protected]>
Are there any sources for DB:<KCC-5.INCLUDE>LIBTRM and LIBTMX?
We run KCC with logical name 'KCC:' (rather than 'C:') as the default
for include and library files. I need to do the same for these.
Thanks.
Vic White
-------
5-May-88 12:23:28-PDT,1928;000000000000
Return-Path: <[email protected]>
Received: from oldsierra.STANFORD.EDU by SRI-NIC.ARPA with TCP; Thu, 5 May 88 12:23:17 PDT
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:13:01 PDT
Date: Thu, 5 May 88 12:13:01 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To: <[email protected]>
----- Transcript of session follows -----
>>> RCPT To:<Grossman@SIERRA>
<<< 550 <Grossman@SIERRA>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:13:01 PDT
Date: Thu, 5 May 88 10:45:25 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: ungetc() doesn't backup file pointer for ftell()
To: [email protected], [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
Here is the fix (reflected in our C:LIBC.REL, but not in the distribution):
;COMPARISON OF PS:<C.LIB.STDIO>FTELL.C.22 AND PS:<C.LIB.STDIO>FTELL.C.23
;OPTIONS ARE /3
**** FILE PS:<C.LIB.STDIO>FTELL.C.22, 1-40 (1276)
* ungetc. We ignore all pushed-back chars in calculating the pointer.
*/
cur_cnt = (f->sioflgs & _SIOF_PBC) ? f->sio2cnt : f->siocnt;
**** FILE PS:<C.LIB.STDIO>FTELL.C.23, 1-40 (1276)
* ungetc. ANSI says pushed-back chars should be included for binary
* streams, though the pointer value is unspecified if you ungetc
* at position 0. For text streams the behavior is unspecified; we
* try to do the same thing as for binary (because that's simplest) but
* the results will probably not be useful.
*/
cur_cnt = (f->sioflgs & _SIOF_PBC)
? f->sio2cnt + f->siocnt /* Include pushback */
: f->siocnt;
***************
-------
5-May-88 12:24:59-PDT,1089;000000000000
Return-Path: <[email protected]>
Received: from oldsierra.STANFORD.EDU by SRI-NIC.ARPA with TCP; Thu, 5 May 88 12:24:41 PDT
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:14:22 PDT
Date: Thu, 5 May 88 12:14:22 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
To: <[email protected]>
----- Transcript of session follows -----
>>> RCPT To:<Grossman@SIERRA>
<<< 550 <Grossman@SIERRA>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by oldsierra.STANFORD.EDU (5.54/4.7); Thu, 5 May 88 12:14:22 PDT
Date: Thu, 5 May 88 10:48:00 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: LIBTRM and LIBTMX
To: [email protected], [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
They are in <KCC-5.LIB> and both have .MIC files there, just as for LIBC.
-------
9-May-88 09:04:20-PDT,1244;000000000015
Return-Path: <[email protected]>
Received: from uunet.UU.NET by SRI-NIC.ARPA with TCP; Mon, 9 May 88 09:04:15 PDT
Received: from enea.UUCP by uunet.UU.NET (5.54/1.14) with UUCP
id AA07763; Mon, 9 May 88 12:03:37 EDT
Received: by enea.se (5.57++/1.34)
id AA15231; Mon, 9 May 88 17:36:34 +0200 (MET)
Received: from emil.UU.SE (emil) by kuling.UU.SE (4.40/SMI-3.0DEV3)
id AA24416; Mon, 9 May 88 15:30:30 -0100
Received: by emil.UU.SE (3.2/SMI-3.0DEV3)
id AA00007; Mon, 9 May 88 16:30:24 +0200
Date: Mon, 9 May 88 16:30:24 +0200
From: [email protected] (Christer Johansson)
Message-Id: <[email protected]>
To: [email protected]
Subject: KCC
Dear sir,
We're running an old version of KCC-20 at the university, and would like to
get the newest version. Are you the right person to contact about this?
Is there a mailing list on KCC? Whom do I ask to be added to it?
Manny thanks, Christer.
--
SMail: Christer Johansson Email: [email protected] OR:
Dept. of Computing Science UUCP: back_bone!enea!emil!christer
Uppsala University
P.O. Box 520 Phone: Int. +46 - 18 18 10 44
S-751 20 Uppsala Nat. 018 - 18 20 44
SWEDEN
9-May-88 14:42:39-PDT,18350;000000000001
Mail-From: KLH created at 9-May-88 14:33:00
Date: Mon, 9 May 88 14:32:59 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Hi!
Yes, I'm the right person, and we have just now released a new version
of KCC. I've added you to the INFO-KCC mailing list, which is primarily
for announcing new features (it is not a discussion group, but one could
be started if there is enough interest).
Someone at Uppsala named Per-Erik Martin was already on the list, but
I think he left; his address ("enea!AIDA.UU.SE!P-E-MARTIN"@UUNET.UU.NET)
no longer seems to work. Do you know anything about that?
And incidentally, do you know anything about the group there that is (or was)
trying to run the MIT ITS system? With some luck, KCC may be running on ITS
soon...
I will include two files here. The first is "NEWS.TXT" which
describes some of the changes thus far. The second is "OBTAIN.DOC"
which explains how to get a copy of KCC. Since you probably do not
have FTP access you would have to order a tape. However, there may be
an alternative. There is someone named Rein Tollevik at the
Institute of Informatics in Oslo ([email protected]) who was able to get
a copy of KCC recently via FTP, and who may be able to continue doing
so. If you can get in touch, that may be faster and more convenient for
you.
Good luck!
--Ken
--------------------------- NEWS.TXT ----------------------------------------
04/20/88 KCC 599, LIBC 219: <2,,2> Fifth formal distribution snapshot
General:
Several new routines, features, and packages have been added.
The various *.DOC files have been improved somewhat, and as usual there
have been some bug fixes both to KCC (primarily the optimizer) and the
library.
KCC:
As KCC sees wider and heavier use, progressively more obscure
over-optimization bugs get shaken out. The arcane details are
unsuitable for listing here, but many thanks are due to those people who
found and reported them!
In addition to bug fixes, some internal cleanup was done to
improve constant folding, regain more stack space, and remove the
previously fixed limitation on parse tree size. Most of these changes are
not externally visible, but some that are:
Error message output has been improved. Although little mousy
errors still tend to panic KCC into a long series of hysterical
screams, the messages themselves are more compact, more informative, and
more well-structured.
__COMPILER_KCC__ now exists as the sole KCC-dependent predefined
macro, so that portable programs can readily determine whether
KCC's <c-env.h> file, in particular, is available or not.
The entry vector is now 3 words to allow for a binary
version number to be put in the 3rd word.
Of great interest to systems programmers will be two new
built-in functions, _KCCsymfnd and _KCCsymval, which can obtain constant
symbol values from .UNV files at compile time. <monsym.h> uses them to
provide a macro which gives very efficient access to all monitor
symbols.
KCC now has an "-i=psect" switch to provide rudimentary support
for loading PSECT code.
LIBC:
The C startup code now recognizes arguments of the form "@file" as
being indirect file specifications; the file is read and parsed into further
arguments. This applies to all C programs including KCC, and provides a way
of getting around RSCAN buffer size limitations.
modf() was changed to conform to the description in V7, ANSI,
and BSD; the description in H&S (CARM) appears to be wrong.
The O_SYSFD flag was added to open(), to allow opening a FD with
an existing JFN.
open() has been changed so that when opening a new file for
writing, it actually does an immediate CLOSF% and another OPENF%. This
ensures that the file immediately exists and is visible, thus avoiding
a number of problems (invalid simultaneous access, file busy, etc) that
are hard to deal with otherwise. The side effect of this is that if
the process is killed before it finishes, its output files will exist
with zero length, whereas before they would not exist at all.
printf(), fprintf() and sprintf() now finally return the number
of characters they output; this will be -1 if an error occurred.
The Un*x functions isatty() and ttyname() are provided.
The TERMCAP functions now exist as LIBTRM.
Fully portable time parsing and manipulation routines are
provided in LIBTMX; see LIBTMX.DOC.
09/11/87 KCC 575, LIBC 202: <2,,2> "KCC-4" (fourth, never really released)
The bad news is that this release is incompatible enough with
the previous versions that you will have to recompile everything you
want to link together. This is mainly because the format of jmp_buf
(used by setjmp and longjmp) had to be expanded. As long as this had
to happen, a few other structures were expanded too. The $$CVER symbol
was updated to force LINK errors on any attempts to load incompatibly
compiled code.
The good news is that this version should completely implement all
facilities described by the new 2nd edition of Harbison and Steele's "C: A
Reference Manual". Some new system calls are also included.
KCC:
Few changes, mostly bug fixes. The __DATE__ and __TIME__ macros
have been implemented, which expand into the date and time of compilation.
LIBC:
Major changes. Many new functions were added. In particular,
signals now work, which required some revamping of the Un*x system
call (USYS) simulation routines. The following are the additions of
note:
longjmp/setjmp now act like CARM/4.3BSD and can restore context
properly even from within a signal handler.
The signal mechanism is intended to fully simulate 4.3BSD
sigvec, including the functions sigvec, sigblock, sigsetmask,
sigpause, sigreturn. All TOPS-20 PSIs are provided for. USYS calls
are handled atomically except when doing monitor calls; those which
are allowed to be interrupted will return EINTR errors.
Some new ANSI functions were added to STDIO. These include
setvbuf, remove, rename, tmpfile, tmpnam, v[fs]printf.
Some new general ANSI utilities were added, including bsearch,
div, ldiv, strtod, strol, strtoul, onexit, strerror, clock, mktime.
The time functions were completed and made portable.
Several miscellaneous functions described in CARM (most from
SYSV) were added, including ctermid, cuserid, getcwd, getenv, putenv,
getlogin, getopt.
A new "system call" was provided: forkexec(), which combines
the functions of fork() and exec() in a way which is extremely efficient
for TOPS-20 (and still portable to Un*x systems). The system() routine
now uses this, as does the runtime when forking pipes.
The jsys() routine was redone to provide a consistent interface
regardless of how the actual jsys returns success or failure. It also
provides an indication of whether the jsys was interrupted, if this
was permitted for the call.
Most important TTY ioctl() functions are now supported.
This includes the ability to set the SIGINT and SIGQUIT interrupt
characters. RAW and CBREAK mode are implemented.
There are some new documentation files. LIBC.DOC and USYS.DOC
summarize the library routines in general and the USYS calls in
particular; SIGNAL.DOC provides more details on the KCC implementation
of signals.
03/17/87 KCC 560, LIBC 124: <2,,1> Binary KCC update
A copy of CC.EXE.560 is included which fixes a number of
annoying bugs that users encountered with KCC 557. The sources are
still those for 557, however. The library is unchanged.
03/06/87 KCC 557, LIBC 124: <2,,1> Third formal distribution snapshot
IMPORTANT: this version of KCC is incompatible with previous
versions! The way that structures are returned from functions has
changed, and the layout of "char" and "short" objects in structures has
also changed. In order to enforce this, the symbol $$CVER has been
updated, and any attempt to load .REL modules which have been produced
by incompatible versions of KCC will cause LINK to complain with an
error message similar to this:
%LNKMDS Multiply-defined global symbol $$CVER
Detected in module PRINTF from file C:LIBC.REL
Defined value = 1000001, this value = 2000001
This is easily remedied by re-compiling old modules. Fortunately, no
further incompatible changes are expected to be necessary.
Nothing has really changed from the user's viewpoint. However,
there are several new features available, and some inefficiencies
corrected. The noteworthy changes are listed below, very briefly;
as usual, CC.DOC should be consulted for more complete and informative
details.
KCC: ---------------------------------------------------------------
KCC - Bug fixes:
A multitude of minor bug fixes too trivial to mention, almost
all having to do with incorrectly optimized code. One that wasn't
trivial was that {char c, *cp = &c;} used to produce an (int *)!
KCC - Incompatible changes:
* "shorts" are now 18 bits long (halfwords), with sizeof(short) == 2.
* The mechanism for returning structure values from functions
is different. This is an internal change, invisible to the user, which
is much more efficient than the previous method.
* Structure members of type "char" and "short" are now packed
differently (more compactly). Any structure using these types will be
laid out differently in storage.
* Integer narrowing and widening is now done properly in all
situations. This may cause incorrectly written code to behave
differently.
* Implicit arithmetic conversions now follow the ANSI
value-preserving rules rather than the old K&R and H&S
unsigned-preserving rules. Ambiguous code may behave differently.
* "float" values are no longer automatically converted to "double",
except for function arguments. This conforms to the ANSI draft.
* The "signed" keyword (introduced by ANSI) has been implemented.
* "volatile" and "const" (also new from ANSI) are now reserved
words (but unimplemented).
KCC - Extension: New data types:
5 new data types have been introduced, which act like "char"
but with different byte sizes. You can now manipulate signed or
unsigned bytes of 6, 7, 8, 9, or 18 bits. This is non-portable and
intended strictly for PDP-10 machine-dependent code where efficiency
is desirable.
KCC - Efficiency improvements:
The change to the structure handling mechanism falls in this
category. Structure copies used to always take two subroutine calls
and two copies; they now use a single in-line BLT (or a series of
single-word moves, whichever is best), and are much faster than
element-by-element copying.
KCC's constant initialization code has been improved to the point
where almost all constants are now initialized at load time rather than
at run time; a similar mechanism eliminates the code that used to generate
string constant pointers. You will see a significant difference with code
that uses many string literals; both startup time and program size are
reduced.
KCC's pointer arithmetic for byte pointers is MUCH better.
Pointer comparison and subtraction formerly used subroutine calls and
many, many instructions; both now use a handful of in-line
instructions and some magic numbers.
There are no more calls to internal run-time subroutines.
All of the operations which used to require this are now compiled
in-line, including double-int and int-double conversion, pointer
operations, and structure copying.
KCC - unsigned and signed data:
KCC now fully supports "unsigned int" operations. Some code
that uses unsigned integers will now compile differently. Division in
particular needs many more instructions. Any integer type, "char" in
particular, may be declared as "signed" and will behave accordingly.
KCC - Switch changes:
-L=<str> Passes <str> in the command string to the linking loader.
-v=<fs> (Verbosity) has been expanded; see CC.DOC. -v alone prints out
everything, including the loader command string.
-l Libraries loaded with the -l switch are now loaded in /SEARCH
mode (they evidently weren't before).
KCC - Miscellaneous
-d=sym now produces a *.CYM file instead of *.SYM, to avoid
conflicts with LINK output files.
-P=ansi+kcc is now the default. The effects are minor and documented
in CC.DOC. The three new ANSI keywords of "signed", "const", and "volatile"
are recognized, although only the first has any real effect.
LIBC: ---------------------------------------------------------------
More minor bug fixes to the LIBC stdio routines.
open() now attempts to track down and expand logical device
names completely (thus performing what the monitor should be doing but
isn't). Thus, open("X:subdir/filename.ext",0) will work even if X is
a search path. Previously only the first device/directory could be tried.
This permits KCC #includes to work with C: defined as a search path.
malloc() no longer allocates pages 770-777 (non-extended) or
37770-37777 (extended), so that obsolete forms of DDT can be mapped therein.
12/07/86 KCC 537, LIBC 93: <1,,1> Informal distribution snapshot
Various additional bug fixes.
There may be some stray files and other cruft as this was made just
so that Systems Concepts could get the latest stuff; some things haven't
been checked out.
10/21/86 KCC 534
Fixed a register allocation bug which got tickled by very large
floating-point expressions.
LIBC: fixed a minor scanf bug. Fixed system/vfork/exit to work properly.
09/28/86 KCC 533, LIBC 14: <1,,1> Second formal distribution snapshot
This is called a "snapshot" to emphasize that while the sources
in this distribution should be consistent and working, the compiler and
library are still under active development to remove known quirks and
deficiencies, and have already changed.
As before, all .REL files must be recompiled; the STDIO
structures are different and there are new C runtime hooks. Most
importantly, the symbol $$CVER is now defined in every module
(currently it is <1,,1>) so as to detect any future conflicts when
loading modules that were incompatibly compiled.
Various change notes follow. For all of them, see the CC.DOC
file for more details.
KCC: ---------------------------------------------------------------
KCC - Command line
There are several new switches, and the way KCC interprets
filenames is slightly different. A file with a .REL extension is
always ignored, but is passed on to the loader. A file without any
extension is special if the -q switch is given; it is only compiled if
the .C source is more recent than the .REL binary.
New switches:
-A Specify nonstandard assembler header file (old meaning of -H)
-H Specify nonstandard path for #include <> files.
-i Loader: load program to run with extended addressing.
-L Loader: nonstandard path for library files.
-l Loader: search specified library
-o Loader: specify .EXE filename.
-P Set portability level.
-q Compile extension-less files conditionally.
KCC - General
There are no real changes in code generation. A couple of
over-optimization bugs were fixed, and a couple of other optimizations
added.
KCC now generates its own assembler header based on the target
CPU, assembler, and system; the file C-HDR.FAI no longer exists.
Two more KCC extensions were added: the `ident` quoting syntax,
and the asm() in-line code mechanism. #asm and #endasm must now appear
only within a function body.
KCC identifiers are now unique up to 31 characters, as per the
ANSI draft (external symbols are still only unique up to 6).
The runtime variable $EXADF no longer exists. The decision on
whether to run extended is now made at load time, either with the -i switch
or by loading C:LIBCKX as the first module.
LIBC: --------------------------------------------------------------
LIBC - CHAR
ispunct() was "fixed" to exclude space. CARM claims space is
included, but neither ANSI nor BSD does so. We assume this is a mistake
in CARM.
LIBC - STRING
The routines memchr, memcmp, memcpy, memset were added from ANSI.
LIBC - STORAGE
free(), malloc(), and realloc() now behave as per ANSI when given
NULL or zero as arguments.
LIBC - STDIO
The "update" mode is now supported for streams. In addition
to this, the library implements the ANSI concept of text vs binary
streams. The 'R' specification was flushed; 'b', '7', '8', '9', 'C',
and "C-" were added.
LIBC - other
system() was added.
07/26/86 KCC 512, CLIB 225: First formal distribution version.
If you already had a version of KCC on your system, you will need
to recompile any .REL modules generated by the old version, because the
new KCC uses a different STDIO package. .EXE files do not need to be
recompiled.
--------------------------- OBTAIN.DOC ----------------------------------------
HOW TO OBTAIN KCC
There are two ways to get a copy of the KCC PDP-10 C compiler: FTP and tape.
FTP:
If you are fortunate enough to be able to make an Internet
TCP/IP connection to SRI-NIC.ARPA, you can transfer the distribution
files directly. Establish a FTP connection to SRI-NIC, log in as
"anonymous" with a random password, and then retrieve the file
KCCDIST:INSTAL.DOC. This will explain the rest of what you need to
know. If you have problems, send electronic mail to
<[email protected]>.
Tape:
If you do not have access to SRI-NIC via TCP/IP then the
alternative is to ask for a magnetic tape. A distribution tape
normally consists of a 9-track 1600 bpi tape with a single saveset
written by TOPS-20 DUMPER, and includes all of the sources and
documentation. A charge is necessary to cover the cost of the
materials, postage, and time. Mail your request, with a check for
US $100 payable to "SRI International", to:
Network Information Center, Room EJ291
SRI International
333 Ravenswood Avenue
Menlo Park, California 94025
If you have further questions or encounter problems, you can contact:
Ken Harrenstien <[email protected]>
Phone: 415/859-6552
(postal address same as above)
-------
9-May-88 18:36:14-PDT,737;000000000000
Date: Mon, 9 May 88 18:31:32 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 9-May-88 13:03:33
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from THOR.HPL.HP.COM by SRI-NIC.ARPA with TCP; Mon, 9 May 88 11:10:37 PDT
Date: Mon 9 May 88 11:09:04-PDT
From: Vic White <[email protected]>
Subject: KCC-5: LIBTRM and LIBTMX
To: Bug-KCC@SRI-NIC
cc: [email protected]
Message-ID: <[email protected]>
I went back to the <KCC-5> tree and can only find .DOC and .REL
files ... nothing that looks like to stuff to rebuild them.
Vic
-------
-------
9-May-88 19:54:34-PDT,996;000000000000
Date: Mon, 9 May 88 19:52:40 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 9-May-88 14:03:33
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Date: Mon, 9 May 88 14:02:57 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: KCC-5: LIBTRM and LIBTMX
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
*Sigh* You're right, the .MIC files were missing. I distinctly remembered
putting in a special line in the .MIC file that generates the distribution
to make sure that those .MIC files were included; however, I forgot that I
did this AFTER creating the initial distribution. Another reason I try
to avoid incremental updates... anyway, I put them there.
<KCC-5.LIB>LIBTMX.MIC and LIBTRM.MIC.
-------
-------
30-May-88 14:06:59-PDT,832;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SRI-NIC.ARPA with TCP; Mon, 30 May 88 14:06:55 PDT
Date: Mon 30 May 88 15:02:23-MDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 29-May-88 14:43:06
Message undelivered after 1 day -- will try for another 2 days:
[email protected].#Internet: Cannot connect to host
------------
Received: from SRI-NIC.ARPA by SCIENCE.UTAH.EDU with TCP; Sun 29 May 88 14:43:08-MDT
Received: from SIMTEL20.ARPA by SRI-NIC.ARPA with TCP; Sun, 29 May 88 13:42:06 PDT
Date: Sun, 29 May 1988 14:40 MDT
Message-ID: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To: [email protected]
cc: [email protected]
Subject: Captive user program
-------
2-Jun-88 09:07:12-PDT,618;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 09:05:30 PDT
Date: Thu 2 Jun 88 10:02:49-MDT
From: "Nelson H.F. Beebe" <[email protected]>
Subject: Mailing list change
To: [email protected]
cc: [email protected]
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>
Please replace [email protected] with [email protected].
I'll be out of the country 9-Jun -- 5-Aug.
-------
2-Jun-88 16:35:37-PDT,475;000000000000
Mail-From: KLH created at 2-Jun-88 16:35:30
Date: Thu, 2 Jun 88 16:35:30 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: Mailing list change
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I'm sorry that your advice and comments won't be available, but hope you
enjoy your travel -- let me know when you get back!
-------
2-Jun-88 16:38:31-PDT,476;000000000000
Mail-From: KLH created at 2-Jun-88 16:36:47
Date: Thu, 2 Jun 88 16:36:46 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: Mailing list change
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
p.s. perhaps that address should be BUG-KCC-INCOMING just to avoid confusion,
especially if someone at UTAH decides to reply?
-------
2-Jun-88 19:36:45-PDT,695;000000000000
Return-Path: <[email protected]>
Received: from SCIENCE.UTAH.EDU by SRI-NIC.ARPA with TCP; Thu, 2 Jun 88 19:36:19 PDT
Date: Thu 2 Jun 88 20:34:18-MDT
From: "Nelson H.F. Beebe" <[email protected]>
Subject: Re: Mailing list change
To: [email protected], [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>
Fine, I've changed it to BUG-KCC-INCOMING, and am testing it
with a cc on this reply.
-------
13-Jun-88 10:20:45-PDT,1395;000000000000
Date: Mon, 13 Jun 88 10:19:58 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Jun-88 10:11:29
Message failed for the following:
[email protected].#Internet: 550 No such local mailbox as "Incoming-bug-kcc", recipient rejected
------------
Date: Mon, 13 Jun 88 10:11:24 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: kcc bug (p++->)
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: Message from "Bill Palmer <[email protected]>" of Sat, 11 Jun 88 15:52:28 PDT
Message-ID: <[email protected]>
I'm not too happy about p++-> either, since it might tempt people to
think that ++p-> similarly increments p (it doesn't) rather than the
thing p points to. When I checked the references, I found that both
K&R and H&S v1 prohibit that sort of syntax; the left-hand side of a
-> must be a "primary" expression. However, both H&R v2 and the X3J11
DPANS document now say that it can be a "postfix" expression, which
includes p++.
I'm surprised this change wasn't flagged more explicitly; the rationale
doesn't mention it at all. But anyway, I guess I'll change KCC. I may
make it dependent on the portability level. Needless to say, anyone who
actually uses such code is probably asking for trouble when porting.
-------
-------
13-Jun-88 10:25:51-PDT,762;000000000000
Date: Mon, 13 Jun 88 10:22:21 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Jun-88 10:15:44
Message failed for the following:
[email protected].#Internet: 550 No such local mailbox as "Incoming-bug-kcc", recipient rejected
------------
Date: Mon, 13 Jun 88 10:15:35 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: scanf bug
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: Message from "Bill Palmer <[email protected]>" of Sat, 11 Jun 88 15:52:05 PDT
Message-ID: <[email protected]>
Thanks for the bug report. Thanks even more for the bug fix!!
I've incorporated it in our source.
-------
-------
17-Jun-88 14:28:27-PDT,1172;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Fri, 17 Jun 88 14:28:18 PDT
Received: by decwrl.dec.com (5.54.4/4.7.34)
id AA05569; Fri, 17 Jun 88 14:26:58 PDT
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA01175; Fri, 17 Jun 88 08:41:24 PDT
Date: Fri, 17 Jun 88 08:41:24 PDT
From: [email protected] (Kok Chen)
Message-Id: <[email protected]>
To: "[email protected]"@decwrl.dec.com
Subject: Change of address.
Ken,
Could you please delete me from the mailing list of INFO-KCC and
INFO-KCC-BUGS for the time being? From June 20 onwards, I will be at
Apple Computer. I will again resubscribe once I get net access (I PRESUME
it is possible, even for a non-software type like me).
In the meantime, it has been very interesting reading. Amazing what
kind of bugs creep up :-) Of course, I no longer understand most of the bug
reports even, being away from a DEC-20 for this long. (Extended addressing
barely appeared when I stopped using -20's.)
Will keep in touch...
Kok Chen
Imagen Corporation (until the end of the day...)
13-Jul-88 09:20:48-PDT,3117;000000000005
Return-Path: <[email protected]>
Received: from uunet.UU.NET by SRI-NIC.ARPA with TCP; Wed, 13 Jul 88 09:19:45 PDT
Received: from enea.UUCP by uunet.UU.NET (5.59/1.14) with UUCP
id AA01818; Wed, 13 Jul 88 10:47:57 EDT
Received: from kth.se (kthvax.kth.se) by enea.se (5.57++/1.79)
id AA27925; Wed, 13 Jul 88 15:45:19 +0200 (MET)
Received: from VERA.NADA.KTH.SE by kth.se (5.57+IDA+KTH/3.0)
id AA25123; Wed, 13 Jul 88 15:44:06 +0200
Date: Wed 13 Jul 88 15:45:49
From: Jan Michael Rynning <[email protected]>
Subject: INFO-KCC and Swedish KA's/KI's/...
To: [email protected]
Cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Organization: Royal Institute of Technology, Stockholm, Sweden.
Address: NADA, KTH, S-100 44 Stockholm, Sweden.
Telephone: +46-8-7906288
Message-Id: <[email protected]>
> Date: Tue, 5 Jul 88 15:32:56 PDT
> From: Ken Harrenstien <[email protected]>
> This seems like a good opportunity to find out whether you should be
> added to the INFO-KCC mailing list, which is used to announce new
> releases, bug fixes, and so on.
Please add me ([email protected]) to the list. Our CC.EXE is written by
SRA on 10 March, 1987, so if you have any back messages from around or
after that date, could you please send them to me?
> So what's the story?
Once upon a time in a small kingdom far north (you knew it would start
that way, didn't you? :-), there was a university of technology, and at
this institute there was a students' hobby computer club by the name
of Stacken (which is Swedish for ``the stack''). One day our friendly
DEC Sales Fairy asked the Stacken Computer Club if it wanted a DEC-1040
(KA10), which was to be scrapped unless the club accepted it.
Since then, Stacken's computer installation has grown larger and LARGER.
It now consists of:
Katia: The original KA10, which was running a slightly modified TOPS-10
6.03A until the cooling system broke down. There is a BBN Paging
Box standing next to it, and as soon as someone gets the time to
rewire the CPU and fix the cooling, it will run TENEX. (``tia''
is Swedish for ``ten'', so ``Katia'' is both a girl's name and
``KA10'' in Swedish :-)
Kicki: A 3 CPU KI10 running a slightly modified TOPS-10 7.02 (TCP/IP,
DECnet Phase IV, some non-standard I/O devices, and using the
KI10 D/A converter to play music and for a cuckoo clock, that
calls once an hour.) Stacken's main system. That's where mail
to STACKEN.KTH.SE and SESTAK.BITNET ends up.
Xerxes: A KS10 running MRC's slightly modified TOPS-20.
SI: Stacken's ITS system, also a KS10.
2 KL10 systems, not yet up and running due to lack of space, a problem
that will hopefully be solved before the end of the summer, and a number
of small machines.
The institute has a 2065 running TOPS-20, 2 2020's with TOPS-10, and a
number of other machines.
There's no decent C compiler for TOPS-10, so I started looking at porting
KCC. I'll let you know if I finish it.
-------
13-Jul-88 14:45:51-PDT,1542;000000000000
Mail-From: KLH created at 13-Jul-88 14:45:16
Date: Wed, 13 Jul 88 14:45:16 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: INFO-KCC and Swedish KA's/KI's/...
To: [email protected]
cc: [email protected], [email protected], [email protected],
[email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Thanks, pretty interesting story! But do all those machines live happily
ever after??
I added [email protected] to INFO-KCC. If there's anyone else, or if
you'd rather do your own internal redistribution (e.g. a local
"incoming-info-kcc" list), just let me know -- send a note to
[email protected].
10 March 1987 is quite a long ways back. Are you sure you didn't mean
1988? I'll wait for confirmation before I send you a very long
message that you might not want.
About porting KCC to TOPS-10: this is quite feasible, and has been considered
by at least three other people, but so far no one has actually started on
it. I have put in a few TOPS-10 conditionals where it was trivial to do
so, but the I/O is such a pain... well, if you are seriously planning to do
this, I suggest that you make sure you have the latest sources before you
start modifying anything. I can also send you some advice on porting
which I put together for Alan Bawden when he started working on the ITS
version (hmm, he must be almost done now, I'll have to check up on it).
--Ken
-------
29-Jul-88 17:54:02-PDT,1091;000000000000
Date: Fri, 29 Jul 88 17:53:57 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 29-Jul-88 17:49:34
Message failed for the following:
*PS:<HSS>[email protected].#Internet: No such mailbox
------------
Date: Fri, 29 Jul 88 17:49:27 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 605 - bug fix
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
A minor optimization bug fix. New binaries in SYS:CC.EXE and SYS:CCX.EXE
on SRI-NIC. A diff follows for those with sources (foldjump() in CCJSKP.C):
;COMPARISON OF PS:<C.KCC.CC>CCJSKP.C.99 AND PS:<C.KCC.CC>CCJSKP.C.101
;OPTIONS ARE /E /3
**** FILE PS:<C.KCC.CC>CCJSKP.C.99, 9-50 (18281)
} else if (isskip (q->Pop) && b->Pop == P_JRST && b->Pptr == lab &&
invskip (before (b))) {
/*
**** FILE PS:<C.KCC.CC>CCJSKP.C.101, 9-50 (18281)
} else if (isskip(q->Pop) && oneinstr(q)
&& b->Pop == P_JRST && b->Pptr == lab
&& invskip(before(b))) {
/*
***************
-------
-------
29-Jul-88 21:06:57-PDT,1266;000000000000
Date: Fri, 29 Jul 88 21:05:01 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 29-Jul-88 17:49:34
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Date: Fri, 29 Jul 88 17:49:27 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 605 - bug fix
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
A minor optimization bug fix. New binaries in SYS:CC.EXE and SYS:CCX.EXE
on SRI-NIC. A diff follows for those with sources (foldjump() in CCJSKP.C):
;COMPARISON OF PS:<C.KCC.CC>CCJSKP.C.99 AND PS:<C.KCC.CC>CCJSKP.C.101
;OPTIONS ARE /E /3
**** FILE PS:<C.KCC.CC>CCJSKP.C.99, 9-50 (18281)
} else if (isskip (q->Pop) && b->Pop == P_JRST && b->Pptr == lab &&
invskip (before (b))) {
/*
**** FILE PS:<C.KCC.CC>CCJSKP.C.101, 9-50 (18281)
} else if (isskip(q->Pop) && oneinstr(q)
&& b->Pop == P_JRST && b->Pptr == lab
&& invskip(before(b))) {
/*
***************
-------
-------
29-Jul-88 22:18:17-PDT,1920;000000000000
Return-Path: <[email protected]>
Received: from trout.nosc.mil by SRI-NIC.ARPA with TCP; Fri, 29 Jul 88 22:18:09 PDT
Received: from uunet.UU.NET by trout.nosc.mil (5.59/1.27)
id AA07783; Fri, 29 Jul 88 22:17:56 PDT
Received: from [128.171.1.101] by uunet.UU.NET (5.59/1.14)
id AA29533; Sat, 30 Jul 88 01:16:36 EDT
Date: Sat, 30 Jul 88 01:16:36 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
bad system name: edu
uux failed. code 68
550 <EDU!jeff>... Host unknown
----- Unsent message follows -----
Received: from [128.171.1.101] by uunet.UU.NET (5.59/1.14)
id AA29417; Sat, 30 Jul 88 01:16:36 EDT
Received: by uhccux.uhcc.hawaii.edu (1.2/Ultrix2.2)
id AA21791; Fri, 29 Jul 88 19:16:19-1000
Received: by humu.nosc.mil (5.59/1.27)
id AA03001; Fri, 29 Jul 88 18:01:44 HST
Received: from SRI-NIC.ARPA by trout.nosc.mil (5.59/1.27)
id AA07159; Fri, 29 Jul 88 21:02:52 PDT
Date: Fri, 29 Jul 88 17:49:27 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 605 - bug fix
To: [email protected]
Cc: [email protected]
Message-Id: <[email protected]>
A minor optimization bug fix. New binaries in SYS:CC.EXE and SYS:CCX.EXE
on SRI-NIC. A diff follows for those with sources (foldjump() in CCJSKP.C):
;COMPARISON OF PS:<C.KCC.CC>CCJSKP.C.99 AND PS:<C.KCC.CC>CCJSKP.C.101
;OPTIONS ARE /E /3
**** FILE PS:<C.KCC.CC>CCJSKP.C.99, 9-50 (18281)
} else if (isskip (q->Pop) && b->Pop == P_JRST && b->Pptr == lab &&
invskip (before (b))) {
/*
**** FILE PS:<C.KCC.CC>CCJSKP.C.101, 9-50 (18281)
} else if (isskip(q->Pop) && oneinstr(q)
&& b->Pop == P_JRST && b->Pptr == lab
&& invskip(before(b))) {
/*
***************
-------
4-Aug-88 01:15:34-PDT,1717;000000000000
Date: Thu, 4 Aug 88 01:11:23 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 3-Aug-88 17:40:21
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Date: Wed, 3 Aug 88 17:40:14 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 606 - bug fix
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Another minor optimization bug fix. New binaries in SYS:CC.EXE and
SYS:CCX.EXE on SRI-NIC. A srccom follows for those with sources:
(Function hackstack() in CCOPT.C, with cosmetic-only changes removed)
;COMPARISON OF PS:<C.KCC.CC>CCOPT.C.324 AND PS:<C.KCC.CC>CCOPT.C.325
;OPTIONS ARE /3
**** FILE PS:<C.KCC.CC>CCOPT.C.324, 13-161 (58074)
/* Instruction's E uses stack reg as index. Check the reference. */
**** FILE PS:<C.KCC.CC>CCOPT.C.325, 13-176 (58991)
/* Check for generating an auto variable address. Of the ops
** we recognize, only three things (XMOVEI, MOVE, ADJBP) should
** be able to generate such addresses.
*/
if (stackrefs) {
if ((p->Pop&POF_OPCODE) == P_MOVE
&& ((p->Ptype&PTF_IMM) /* XMOVEI */
|| ((p->Ptype&PTF_ADRMODE)==PTA_BYTEPOINT))) /* MOVE R,[bp] */
return 0;
if ((p->Pop&POF_OPCODE) == P_ADJBP
&& (p->Ptype&PTF_ADRMODE)==PTA_BYTEPOINT) /* ADJBP R,[bp] */
return 0;
}
/* Instruction's E uses stack reg as index. Check the reference. */
***************
-------
-------
4-Aug-88 02:08:40-PDT,2365;000000000000
Return-Path: <[email protected]>
Received: from trout.nosc.mil by SRI-NIC.ARPA with TCP; Thu, 4 Aug 88 02:08:33 PDT
Received: from uunet.UU.NET by trout.nosc.mil (5.59/1.27)
id AA24400; Thu, 4 Aug 88 02:04:52 PDT
Received: from [128.171.1.101] by uunet.UU.NET (5.59/1.14)
id AA19986; Thu, 4 Aug 88 05:02:10 EDT
Date: Thu, 4 Aug 88 05:02:10 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
bad system name: edu
uux failed. code 68
550 <EDU!jeff>... Host unknown
----- Unsent message follows -----
Received: from [128.171.1.101] by uunet.UU.NET (5.59/1.14)
id AA19923; Thu, 4 Aug 88 05:02:10 EDT
Received: by uhccux.uhcc.hawaii.edu (1.2/Ultrix2.2)
id AA03723; Wed, 3 Aug 88 23:02:03-1000
Received: by humu.nosc.mil (5.59/1.27)
id AA17319; Wed, 3 Aug 88 21:59:47 HST
Received: from SRI-NIC.ARPA by trout.nosc.mil (5.59/1.27)
id AA23274; Thu, 4 Aug 88 01:01:06 PDT
Date: Wed, 3 Aug 88 17:40:14 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 606 - bug fix
To: [email protected]
Cc: [email protected]
Message-Id: <[email protected]>
Another minor optimization bug fix. New binaries in SYS:CC.EXE and
SYS:CCX.EXE on SRI-NIC. A srccom follows for those with sources:
(Function hackstack() in CCOPT.C, with cosmetic-only changes removed)
;COMPARISON OF PS:<C.KCC.CC>CCOPT.C.324 AND PS:<C.KCC.CC>CCOPT.C.325
;OPTIONS ARE /3
**** FILE PS:<C.KCC.CC>CCOPT.C.324, 13-161 (58074)
/* Instruction's E uses stack reg as index. Check the reference. */
**** FILE PS:<C.KCC.CC>CCOPT.C.325, 13-176 (58991)
/* Check for generating an auto variable address. Of the ops
** we recognize, only three things (XMOVEI, MOVE, ADJBP) should
** be able to generate such addresses.
*/
if (stackrefs) {
if ((p->Pop&POF_OPCODE) == P_MOVE
&& ((p->Ptype&PTF_IMM) /* XMOVEI */
|| ((p->Ptype&PTF_ADRMODE)==PTA_BYTEPOINT))) /* MOVE R,[bp] */
return 0;
if ((p->Pop&POF_OPCODE) == P_ADJBP
&& (p->Ptype&PTF_ADRMODE)==PTA_BYTEPOINT) /* ADJBP R,[bp] */
return 0;
}
/* Instruction's E uses stack reg as index. Check the reference. */
***************
-------
5-Aug-88 01:04:49-PDT,1263;000000000000
Date: Fri, 5 Aug 88 00:48:55 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 4-Aug-88 19:35:23
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Date: Thu, 4 Aug 88 19:35:15 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 607 - type check bugfix
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Funny how they come all at once. This one fixes a bug where KCC complained
about "foo->a" when foo was declared as an array of structures. New binaries
as usual in SYS:CC.EXE and SYS:CCX.EXE, source change below:
;COMPARISON OF PS:<C.KCC.CC>CCSTMT.C.339 AND PS:<C.KCC.CC>CCSTMT.C.340
**** FILE PS:<C.KCC.CC>CCSTMT.C.339, 20-293 (55397)
/* Check that type of preceding expr is correct */
**** FILE PS:<C.KCC.CC>CCSTMT.C.340, 20-293 (55397)
/* Check that type of preceding expr is correct */
n = convarrfn(n); /* Apply array/funct convs */
***************
-------
-------
5-Aug-88 16:16:17-PDT,1911;000000000000
Return-Path: <[email protected]>
Received: from trout.nosc.mil by SRI-NIC.ARPA with TCP; Fri, 5 Aug 88 16:15:38 PDT
Received: from uunet.UU.NET by trout.nosc.mil (5.59/1.27)
id AA08616; Fri, 5 Aug 88 16:08:34 PDT
Received: from [128.171.1.101] by uunet.UU.NET (5.59/1.14)
id AA29513; Fri, 5 Aug 88 19:05:59 EDT
Date: Fri, 5 Aug 88 19:05:59 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
bad system name: edu
uux failed. code 68
550 <EDU!jeff>... Host unknown
----- Unsent message follows -----
Received: from [128.171.1.101] by uunet.UU.NET (5.59/1.14)
id AA29453; Fri, 5 Aug 88 19:05:59 EDT
Received: by uhccux.uhcc.hawaii.edu (1.2/Ultrix2.2)
id AA19120; Fri, 5 Aug 88 13:05:52-1000
Received: by humu.nosc.mil (5.59/1.27)
id AA06926; Fri, 5 Aug 88 12:38:25 HST
Received: from SRI-NIC.ARPA by trout.nosc.mil (5.59/1.27)
id AA08256; Fri, 5 Aug 88 15:39:49 PDT
Date: Thu, 4 Aug 88 19:35:15 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 607 - type check bugfix
To: [email protected]
Cc: [email protected]
Message-Id: <[email protected]>
Funny how they come all at once. This one fixes a bug where KCC complained
about "foo->a" when foo was declared as an array of structures. New binaries
as usual in SYS:CC.EXE and SYS:CCX.EXE, source change below:
;COMPARISON OF PS:<C.KCC.CC>CCSTMT.C.339 AND PS:<C.KCC.CC>CCSTMT.C.340
**** FILE PS:<C.KCC.CC>CCSTMT.C.339, 20-293 (55397)
/* Check that type of preceding expr is correct */
**** FILE PS:<C.KCC.CC>CCSTMT.C.340, 20-293 (55397)
/* Check that type of preceding expr is correct */
n = convarrfn(n); /* Apply array/funct convs */
***************
-------
6-Aug-88 09:01:47-PDT,427;000000000000
Return-Path: <[email protected]>
Received: from helens.STANFORD.EDU by SRI-NIC.ARPA with TCP; Sat, 6 Aug 88 09:01:42 PDT
Received: by helens.STANFORD.EDU (3.2/4.7); Sat, 6 Aug 88 09:03:33 PDT
Date: Sat, 6 Aug 88 09:03:33 PDT
From: [email protected]
To: [email protected]
Subject: info-kcc mailing list
please remove [email protected] from the info-kcc mailing list.
thanks
-frank
8-Aug-88 19:09:30-PDT,706;000000000000
Return-Path: <[email protected]>
Received: from C.CS.CMU.EDU by SRI-NIC.ARPA with TCP; Mon, 8 Aug 88 19:09:20 PDT
Date: Mon 8 Aug 88 21:36:02-EDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 7-Aug-88 21:13:56
Message undelivered after 1 day -- will try for another 2 days:
[email protected].#Internet: Cannot connect to host
------------
Received: from SRI-NIC.ARPA by C.CS.CMU.EDU with TCP; Sun 7 Aug 88 21:13:58-EDT
Date: Wed, 3 Aug 88 17:40:14 PDT
From: Ken Harrenstien <[email protected]>
Subject: KCC 606 - bug fix
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
-------
15-Aug-88 15:55:34-PDT,435;000000000000
Mail-From: KLH created at 15-Aug-88 15:55:29
Date: Mon, 15 Aug 88 15:55:29 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: info-kcc mailing list
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: Message from "[email protected]" of Sat, 6 Aug 88 09:01:46 PDT
Message-ID: <[email protected]>
OK, as of now you're off the INFO-KCC list. Bye...
-------
15-Aug-88 21:44:56-PDT,1775;000000000000
Date: Mon, 15 Aug 88 21:43:00 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 15-Aug-88 18:10:37
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from MACBETH.STANFORD.EDU by SRI-NIC.ARPA with TCP; Mon, 15 Aug 88 18:10:30 PDT
Date: Mon 15 Aug 88 17:35:20-PDT
From: Stuart Nelson <[email protected]>
Subject: Extended addressing in kcc
To: [email protected]
Message-ID: <[email protected]>
An area in kcc where we would like to see some improvement is its
treatment of extended addressing. As the documentation states, kcc
can compile programs to run in extended (multi-section) memory. The
catch, however, is that all your code and variables (except auto
variables, which go on the stack) must fit in one section. For
large named arrays, structures, etc. we find this crippling. (This
problem arose in our case because we need to refer in C routines to
named COMMON blocks put in extended memory by TOPS-20 Fortran, and
there is no way to do this C as kcc stands. Comparisons are
invidious, but Fortran has options to load code and data directly
into extended memory.)
A related shortcoming that does not bother us as much is the
inability to call functions in another section. Our code fits in
one section, but code + variables does not.
Are there any other kcc users out there to whom either of these
problems is significant?
--Peter R. Samson
Systems Concepts
-------
-------
16-Aug-88 04:17:28-PDT,2433;000000000000
Return-Path: <[email protected]>
Received: from trout.nosc.mil by SRI-NIC.ARPA with TCP; Tue, 16 Aug 88 04:17:19 PDT
Received: from [192.12.141.129] by trout.nosc.mil (5.59/1.27)
id AA29453; Tue, 16 Aug 88 04:16:37 PDT
Received: from [128.171.1.101] by uunet.UU.NET (5.59/1.14)
id AA01514; Tue, 16 Aug 88 07:15:33 EDT
Date: Tue, 16 Aug 88 07:15:33 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
bad system name: edu
uux failed. code 68
550 <EDU!jeff>... Host unknown
----- Unsent message follows -----
Received: from [128.171.1.101] by uunet.UU.NET (5.59/1.14)
id AA01476; Tue, 16 Aug 88 07:15:33 EDT
Received: by uhccux.uhcc.hawaii.edu (1.2/Ultrix2.2)
id AA16233; Tue, 16 Aug 88 01:15:16-1000
Received: by humu.nosc.mil (5.59/1.27)
id AA21713; Mon, 15 Aug 88 23:26:10 HST
Received: from SRI-NIC.ARPA by trout.nosc.mil (5.59/1.27)
id AA27688; Tue, 16 Aug 88 02:27:45 PDT
Received: from MACBETH.STANFORD.EDU by SRI-NIC.ARPA with TCP; Mon, 15 Aug 88 18:10:30 PDT
Date: Mon 15 Aug 88 17:35:20-PDT
From: Stuart Nelson <[email protected]>
Subject: Extended addressing in kcc
To: [email protected]
Message-Id: <[email protected]>
An area in kcc where we would like to see some improvement is its
treatment of extended addressing. As the documentation states, kcc
can compile programs to run in extended (multi-section) memory. The
catch, however, is that all your code and variables (except auto
variables, which go on the stack) must fit in one section. For
large named arrays, structures, etc. we find this crippling. (This
problem arose in our case because we need to refer in C routines to
named COMMON blocks put in extended memory by TOPS-20 Fortran, and
there is no way to do this C as kcc stands. Comparisons are
invidious, but Fortran has options to load code and data directly
into extended memory.)
A related shortcoming that does not bother us as much is the
inability to call functions in another section. Our code fits in
one section, but code + variables does not.
Are there any other kcc users out there to whom either of these
problems is significant?
--Peter R. Samson
Systems Concepts
-------
18-Aug-88 12:04:03-PDT,834;000000000000
Return-Path: <[email protected]>
Received: from dorsai.ics.hawaii.edu by SRI-NIC.ARPA with TCP; Thu, 18 Aug 88 12:03:16 PDT
Received: from uhccux.uhcc.hawaii.edu by dorsai.ics.hawaii.edu with SMTP id 4214; Thu, 18 Aug 88 09:04:10 HST
Received: by uhccux.uhcc.hawaii.edu (1.2/Ultrix2.2)
id AA15870; Thu, 18 Aug 88 09:02:05-1000
Date: Thu, 18 Aug 88 05:05:00 HST
From: Jeffrey Blomberg <[email protected]>
To: [email protected]
Subject: Please remove my name....
Message-Id: <[email protected]>
Please remove my name from the info-kcc list. I believe my current address
is [email protected] on your list and it is causing problems. Also, our
-20 is slated for removal in a few months.....
-Jeff Blomberg
20-Aug-88 19:40:49-PDT,1606;000000000000
Date: Sat, 20 Aug 88 19:40:43 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 15-Aug-88 18:10:37
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Received: from MACBETH.STANFORD.EDU by SRI-NIC.ARPA with TCP; Mon, 15 Aug 88 18:10:30 PDT
Date: Mon 15 Aug 88 17:35:20-PDT
From: Stuart Nelson <[email protected]>
Subject: Extended addressing in kcc
To: [email protected]
Message-ID: <[email protected]>
An area in kcc where we would like to see some improvement is its
treatment of extended addressing. As the documentation states, kcc
can compile programs to run in extended (multi-section) memory. The
catch, however, is that all your code and variables (except auto
variables, which go on the stack) must fit in one section. For
large named arrays, structures, etc. we find this crippling. (This
problem arose in our case because we need to refer in C routines to
named COMMON blocks put in extended memory by TOPS-20 Fortran, and
there is no way to do this C as kcc stands. Comparisons are
invidious, but Fortran has options to load code and data directly
into extended memory.)
A related shortcoming that does not bother us as much is the
inability to call functions in another section. Our code fits in
one section, but code + variables does not.
Are there any other kcc users out there to whom either of these
problems is significant?
--Peter R. Samson
Systems Concepts
-------
-------
17-Dec-88 02:23:15-PST,3154;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Sat, 17 Dec 88 02:22:58 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for [email protected]; id AA19879; Sat, 17 Dec 88 02:22:48 PST
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA00269; Sat, 17 Dec 88 01:34:46 PST
Date: Sat, 17 Dec 88 01:34:46 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
To: [email protected]
----- Transcript of session follows -----
550 User unknown
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA00267; Sat, 17 Dec 88 01:34:46 PST
Received: from SRI-NIC.ARPA by decwrl.dec.com (5.54.5/4.7.34)
for kchen; id AA10758; Fri, 16 Dec 88 22:10:20 PST
Received: from WSMR-SIMTEL20.ARMY.MIL by SRI-NIC.ARPA with TCP; Fri, 16 Dec 88 20:02:56 PST
Date: Fri, 16 Dec 1988 21:03 MST
Message-Id: <[email protected]>
From: "Frank J. Wancho" <[email protected]>
To: [email protected]
Subject: [WANCHO: free() bug (CC 608, LIBC 235)]
Somehow I missed even an acknowledgement that this report was
received...
--Frank
--------------------
Date: Saturday, 15 October 1988 00:55-MDT
From: Frank J. Wancho <WANCHO>
To: BUG-KCC at SRI-NIC.ARPA
cc: WANCHO
Re: free() bug (CC 608, LIBC 235)
The attached program produces the following errors when compiled and
run with the -DDEBUG option:
[PHOTO: Recording initiated Sat 15-Oct-88 12:50AM]
$cc -DDEBUG tstchk
KCC: tstchk
MACRO: tstchk
EXIT
LINK: Loading
$tstchk sri-nic.arpa
Host number for sri-nic.arpa: 26.0.0.73
Host number for : 26.0.0.73
free(): tried to free invalid block (0,,432006)
?Illegal instruction 0 at ABORT
?Undefined operation code
$cc tstchk
KCC: tstchk
MACRO: tstchk
EXIT
LINK: Loading
$tstchk sri-nic.arpa
Host number for SRI-NIC.ARPA: 26.0.0.73
$pop
[PHOTO: Recording terminated Sat 15-Oct-88 12:51AM]
TSTCHK.C:
#include <stdio.h>
#include <jsys.h>
#define TRUE 1
#define FALSE 0
char hname[100];
main(num, arg)
int num;
char *arg[];
{
int ablock[5];
int n[5];
int i, hnum;
ablock[1] = _GTHSN;
ablock[2] = (int) (arg[1] - 1);
if (!jsys(GTHST, ablock)) {
fprintf(stderr, "Host %s is not known.\n", arg[1]);
exit(1);
}
hnum = ablock[3];
for(i = 4; --i >= 0; hnum >>= 8) {
n[i] = hnum&0xFF;
}
#ifdef DEBUG
printf("Host number for %s: %d.%d.%d.%d\n",
arg[1], n[0], n[1], n[2], n[3]);
#endif
ablock[1] = _GTHNS; /* want official name now */
ablock[2] = (int) (hname - 1); /* where to put it */
if (!jsys(GTHST, ablock)) { /* if can't get the official */
fprintf(stderr, "Host %s is not known.\n", arg[1]);
exit(1);
}
for(i = 4; --i >= 0; ablock[3] >>= 8) {
n[i] = ablock[3]&0xFF;
}
printf("Host number for %s: %d.%d.%d.%d\n",
hname, n[0], n[1], n[2], n[3]);
}
16-Jan-89 23:48:17-PST,1153;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Mon, 16 Jan 89 23:48:07 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for [email protected]; id AA06153; Mon, 16 Jan 89 23:48:08 PST
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA19567; Mon, 16 Jan 89 23:39:27 PST
Date: Mon, 16 Jan 89 23:39:27 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
To: [email protected]
----- Transcript of session follows -----
550 User unknown
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA19565; Mon, 16 Jan 89 23:39:27 PST
Received: from SRI-NIC.ARPA by decwrl.dec.com (5.54.5/4.7.34)
for kchen; id AA05897; Mon, 16 Jan 89 23:38:16 PST
Date: Mon, 16 Jan 89 09:56:08 PST
From: Mimi Recker <[email protected]>
Subject: re: bug in strCMP
To: [email protected]
Message-Id: <[email protected]>
Ooops...never mind.
-------
17-Jan-89 00:11:21-PST,1277;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Tue, 17 Jan 89 00:11:08 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for [email protected]; id AA07268; Tue, 17 Jan 89 00:11:04 PST
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA19732; Mon, 16 Jan 89 23:49:19 PST
Date: Mon, 16 Jan 89 23:49:19 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
To: [email protected]
----- Transcript of session follows -----
550 User unknown
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA19730; Mon, 16 Jan 89 23:49:19 PST
Received: from SRI-NIC.ARPA by decwrl.dec.com (5.54.5/4.7.34)
for kchen; id AA05941; Mon, 16 Jan 89 23:40:06 PST
Date: Mon, 16 Jan 89 10:24:46 PST
From: Ken Harrenstien <[email protected]>
Subject: re: bug in strCMP
To: [email protected], [email protected]
Cc: [email protected]
In-Reply-To: <[email protected]>
Message-Id: <[email protected]>
I bet you forgot to #include <nic/strung.h>, right?
-------
17-Jan-89 00:21:58-PST,1506;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Tue, 17 Jan 89 00:21:46 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for [email protected]; id AA07644; Tue, 17 Jan 89 00:21:48 PST
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA19997; Tue, 17 Jan 89 00:15:24 PST
Date: Tue, 17 Jan 89 00:15:24 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
To: [email protected]
----- Transcript of session follows -----
550 User unknown
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA19993; Tue, 17 Jan 89 00:15:24 PST
Received: from SRI-NIC.ARPA by decwrl.dec.com (5.54.5/4.7.34)
for kchen; id AA07409; Tue, 17 Jan 89 00:13:54 PST
Date: Sun, 15 Jan 89 20:58:57 PST
From: Mimi Recker <[email protected]>
Subject: strCMP() bug???
To: [email protected]
Message-Id: <[email protected]>
seems to apply to other case insentive str ops too...
[PHOTO: Recording initiated Sun 15-Jan-89 8:56pm]
@ty test.c
main()
{
(strcmp("aaa", "aaa")==0) ? puts("cmp same") : puts("cmp not same");
(strCMP("aaa", "AAA")==0) ? puts("CMP same") : puts("CMP not same");
}
@test
cmp same
CMP not same
@pop
[PHOTO: Recording terminated Sun 15-Jan-89 8:56pm]
-------
18-Jan-89 22:29:32-PST,2002;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by SRI-NIC.ARPA with TCP; Wed, 18 Jan 89 22:29:20 PST
Received: by decwrl.dec.com (5.54.5/4.7.34)
for [email protected]; id AA16538; Wed, 18 Jan 89 22:29:29 PST
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA09754; Wed, 18 Jan 89 22:03:58 PST
Date: Wed, 18 Jan 89 22:03:58 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
To: [email protected]
----- Transcript of session follows -----
550 User unknown
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA09752; Wed, 18 Jan 89 22:03:58 PST
Received: from SRI-NIC.ARPA by decwrl.dec.com (5.54.5/4.7.34)
for kchen; id AA10620; Wed, 18 Jan 89 20:38:42 PST
Received: from VERA.NADA.KTH.SE ([130.237.222.17]) by SRI-NIC.ARPA with TCP; Wed, 18 Jan 89 12:50:22 PST
Date: Wed 18 Jan 89 21:49:44
From: Jan Michael Rynning <[email protected]>
Subject: <C.KCC.CC>*.* - Not found.
To: [email protected]
Organization: Royal Institute of Technology, Stockholm, Sweden.
Address: NADA, KTH, S-100 44 Stockholm, Sweden.
Telephone: +46-8-7906288
Message-Id: <[email protected]>
I am trying to update my KCC compiler sources, but when I ask for a
directory listing of <C.KCC.CC>*.* yor FTP server says "Not found".
Did I look in the wrong place, did you move the compiler sources to
another directory, or is <C.KCC.CC> protected so I can't read it?
Jan Michael Rynning, [email protected]
Department of Numerical Analysis If you can't fully handle domains:
and Computing Science, ARPA: jmr%[email protected]
Royal Institute of Technology, UUCP: {uunet,mcvax,...}!nada.kth.se!jmr
S-100 44 Stockholm, BITNET: jmr@sekth
Sweden. Phone: +46-8-7906288
-------
13-Mar-89 08:40:25-PST,521;000000000000
Return-Path: <[email protected]>
Received: from presto.ig.com by SRI-NIC.ARPA with TCP; Mon, 13 Mar 89 08:40:00 PST
Received: by presto.ig.com (5.59/1.15)
id AA21283; Mon, 13 Mar 89 08:39:45 PST
Date: Mon, 13 Mar 1989 8:39:44 PST
From: John M. Relph <[email protected]>
To: [email protected]
Subject: BUG-KCC mailing list
Message-Id: <[email protected]>
Please remove me ([email protected] or [email protected]) from the
Bug-KCC mailing list. Thank you.
-- John
13-Mar-89 13:34:40-PST,367;000000000000
Mail-From: KLH created at 13-Mar-89 13:25:31
Date: Mon, 13 Mar 89 13:25:30 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: BUG-KCC mailing list
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
OK, you're off...
-------
14-Mar-89 13:39:21-PST,483;000000000000
Return-Path: <[email protected]>
Received: from presto.ig.com by SRI-NIC.ARPA with TCP; Tue, 14 Mar 89 13:38:32 PST
Received: by presto.ig.com (5.59/1.15)
id AA19508; Tue, 14 Mar 89 13:38:24 PST
Date: Tue, 14 Mar 89 13:38:24 PST
From: [email protected] (Jean-Pierre Dautricourt)
Message-Id: <[email protected]>
To: [email protected]
Subject: remove name
Please remove my name from the bug-kcc mail list. Thank you.
Jean-Pierre Dautricourt
14-Mar-89 14:02:05-PST,350;000000000000
Mail-From: KLH created at 14-Mar-89 13:54:26
Date: Tue, 14 Mar 89 13:54:26 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: remove name
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
OK, you're off...
-------
14-Mar-89 23:20:15-PST,1939;000000000000
Date: Tue, 14 Mar 89 22:57:12 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 9-Mar-89 17:15:38
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Received: from SCIENCE.UTAH.EDU by SRI-NIC.ARPA with TCP; Thu, 9 Mar 89 17:15:20 PST
Date: Thu 9 Mar 89 18:14:39-MST
From: Pieter <[email protected]>
Subject: FORKEX.C bug and correction
To: [email protected]
cc: [email protected]
Snail: Center for Scientific Computing
Snail: 224 Physics South
Snail: Department of Mathematics
Snail: University of Utah
Snail: Salt Lake City, UT 84112, USA, Terra
Telephone: 1-801-581-6286
Message-ID: <[email protected]>
I've been trying to port some code from Unix which uses the
execlp function. Today I finally tracked down the problem.
It occurs in the FORKEX module in function revstack. Here is
the fix. The two lines marked with '|' are the ones.
Pieter
[email protected]
/* REVSTACK - auxiliary for execl*() routines.
** Reverses an array of pointers on the stack.
** On the PDP-10 an arg list like arg1, arg2, ... 0 is stored on
** the stack such that 0 is at the lowest address, arg1 at highest.
** We need to reverse this ordering so we can treat it like a normal
** argv array (with a null pointer as the last element).
*/
static char **
revstack(av)
char **av;
{
register char **t, **b, *tmp; /* Top and bottom pointers */
register int i;
for (t = b = av; *t; --t); /* Back up to top of array (a null ptr) */
av = t; /* Remember where top is */
i = (1 + b - t) / 2; /* Find # of elements to swap in array */
for (; i > 0; --i) {
tmp = *t; /* Swap elements, and bump ptrs closer. */
| *t++ = *b;
| *b-- = tmp;
}
return av; /* Return ptr to top of reversed array */
}
-------
-------
14-Mar-89 23:20:20-PST,701;000000000000
Date: Tue, 14 Mar 89 22:57:14 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 9-Mar-89 17:24:16
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Date: Thu, 9 Mar 89 17:24:07 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: FORKEX.C bug and correction
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Thanks for tracking down that bug and fixing it. Gack... the top/bottom
higher#/lower# confusion strikes once again!
-------
-------
15-Mar-89 16:13:46-PST,833;000000000000
Date: Wed, 15 Mar 89 16:12:31 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 10-Mar-89 04:46:17
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Date: Fri, 10 Mar 89 04:46:13 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: Bug in KCC v607
To: REIN%[email protected], [email protected]
cc: [email protected]
In-Reply-To: <12476332632.16.REIN@TONE>
Message-ID: <[email protected]>
Sorry, but I cannot reproduce this problem. I tried compiling that code
with version 607 and had no problems. You might wish to FTP a more recent
version (SYS:CC.EXE is now version 609), just in case your copy got
clobbered somehow. Let me know if you find any more details.
-------
-------
15-Mar-89 16:33:46-PST,1843;000000000000
Date: Wed, 15 Mar 89 16:31:35 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 10-Mar-89 06:14:20
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Date: Fri, 10 Mar 89 06:14:16 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: piping w/TOPS-20 extended addressing
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
OK, I found a bug in the way wait() was coded which caused it to not work
in extended addressing, and fixed it (not yet installed, too tired).
Piping was involved only to the extent that it invoked an inferior fork
and waited for it to stop.
Unfortunately, I found a more serious bug which is much harder to fix.
There is no way I know of on TOPS-20 to suspend the current process
until any one of its inferiors terminates. WFORK% lets you either
wait for a SPECIFIC inferior, or wait for ALL inferiors to terminate,
but you can't wait for ANY inferior. Really amazing brain damage
here.
The only way out of this I can think of is to loop forever doing a GFRKS%
to examine the fork structure by hand, with a sleep period somewhere in the
loop to avoid burning too much CPU time. This not only eats more cycles,
it imposes a certain delay in recognizing that a fork has died. It would
be possible to use .ICIFT (Inferior Fork Termination PSI) but this is even
more complicated and would require (1) the overhead of PSI activation for
every C program, plus (2) special code to avoid interfering with users who
want to handle SIGCHLD signals (currently implemented, by the way).
If anyone has comments on this I'd appreciate them.
--Ken
-------
-------
3-Aug-89 14:58:09-PDT,759;000000000000
Return-Path: <GUEST.RICKARD-LINCK%[email protected]>
Received: from life.ai.mit.edu by SRI-NIC.ARPA with TCP; Thu, 3 Aug 89 14:56:28 PDT
Received: from KICKI.STACKEN.KTH.SE by life.ai.mit.edu (4.1/AI-4.10) id AA07471; Thu, 3 Aug 89 17:40:19 EDT
Return-Path: <@XERXES.STACKEN.KTH.SE:[email protected]>
Received: from XERXES.STACKEN.KTH.SE by KICKI.STACKEN.KTH.SE; Thu, 3 Aug 89 23:33:16 +0200
Received: from ATHENA.DSV.SU.SE (not validated) by XERXES; Thu, 3 Aug 89 23:27:20 O
Date: Thu 3 Aug 89 23:26:53
From: Rickard <[email protected]>
To: [email protected]
Subject: test
Message-Id: <[email protected]>
Is this getting thru??
-------
3-Aug-89 14:59:20-PDT,444;000000000000
Mail-From: KLH created at 3-Aug-89 14:58:50
Date: Thu, 3 Aug 89 14:58:50 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: test
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Yep, I got your message. Now let's see if this response can get back
to you...
-------
27-Oct-89 02:46:53-PDT,2403;000000000000
Date: Fri, 27 Oct 89 02:39:03 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 26-Oct-89 14:00:38
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Date: Thu, 26 Oct 89 13:56:01 PDT
From: Ken Harrenstien <[email protected]>
Subject: ANSI KCC coming soon
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I wanted to reassure people that ANSI KCC does exist and I'm still trying
to get it into shape for distribution. Here's the story thus far:
With support from CompuServe, I spent most of the summer upgrading KCC
to both run on TOPS-10 and conform to the latest version of ANSI C
(formally still a "proposed ANS" text). The resulting implementation
has been undergoing testing and refinement on both TOPS-10 and TOPS-20
for the last couple of months. I was hoping to freeze things for a
while and start putting together a clean distribution, but just last
week CompuServe began running KCC through the Plum Hall test suite, and
sure enough this has shaken out a number of minor bugs (total thus
far looks like KCC 9, PH 1). Currently I'm waiting to see if any more
turn up before starting on the distribution.
The directory structure for the new KCC is quite different. I have
split the library routines into several subdirectories, and the
building process puts all binaries into a single directory which can
be configured for a specific machine or system. This was necessary so
I could maintain versions for several independent configurations in parallel
without duplicating the sources for each one.
So, of course, the procedures that I relied on in the past for taking
snapshots or writing tapes no longer work and I need to revise them as
well. I do, however, have a single directory that could be FTP'd if any
Internet TOPS-20 sites are dying to do beta-testing with the binaries.
Note that $$CVER has been bumped so anything used with the new KCC must
be completely recompiled.
Sometime later I'll be sending more messages describing some of the new
features, where things are, etc...
--Ken
-------
-------
28-Oct-89 22:12:13-PDT,2264;000000000000
Date: Sat, 28 Oct 89 22:09:54 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 26-Oct-89 14:00:38
Message failed for the following:
white%[email protected]: 550 (BHST) Unknown host/domain name in "white%[email protected]"
------------
Date: Thu, 26 Oct 89 13:56:01 PDT
From: Ken Harrenstien <[email protected]>
Subject: ANSI KCC coming soon
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I wanted to reassure people that ANSI KCC does exist and I'm still trying
to get it into shape for distribution. Here's the story thus far:
With support from CompuServe, I spent most of the summer upgrading KCC
to both run on TOPS-10 and conform to the latest version of ANSI C
(formally still a "proposed ANS" text). The resulting implementation
has been undergoing testing and refinement on both TOPS-10 and TOPS-20
for the last couple of months. I was hoping to freeze things for a
while and start putting together a clean distribution, but just last
week CompuServe began running KCC through the Plum Hall test suite, and
sure enough this has shaken out a number of minor bugs (total thus
far looks like KCC 9, PH 1). Currently I'm waiting to see if any more
turn up before starting on the distribution.
The directory structure for the new KCC is quite different. I have
split the library routines into several subdirectories, and the
building process puts all binaries into a single directory which can
be configured for a specific machine or system. This was necessary so
I could maintain versions for several independent configurations in parallel
without duplicating the sources for each one.
So, of course, the procedures that I relied on in the past for taking
snapshots or writing tapes no longer work and I need to revise them as
well. I do, however, have a single directory that could be FTP'd if any
Internet TOPS-20 sites are dying to do beta-testing with the binaries.
Note that $$CVER has been bumped so anything used with the new KCC must
be completely recompiled.
Sometime later I'll be sending more messages describing some of the new
features, where things are, etc...
--Ken
-------
-------
29-Oct-89 06:33:16-PST,2813;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Sun, 29 Oct 89 06:33:11 PST
Received: by decwrl.dec.com; id AA02065; Sun, 29 Oct 89 06:33:27 -0800
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA12793; Sun, 29 Oct 89 03:40:53 PST
Date: Sun, 29 Oct 89 03:40:53 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
To: [email protected]
----- Transcript of session follows -----
550 kchen... User unknown
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: by imagen.uucp (5.51/Imagen-1.1)
id AA12791; Sun, 29 Oct 89 03:40:53 PST
Received: by decwrl.dec.com; id AA13927; Sat, 28 Oct 89 22:08:37 -0700
Date: Thu, 26 Oct 89 13:56:01 PDT
From: Ken Harrenstien <[email protected]>
Subject: ANSI KCC coming soon
To: [email protected]
Cc: [email protected]
Message-Id: <[email protected]>
I wanted to reassure people that ANSI KCC does exist and I'm still trying
to get it into shape for distribution. Here's the story thus far:
With support from CompuServe, I spent most of the summer upgrading KCC
to both run on TOPS-10 and conform to the latest version of ANSI C
(formally still a "proposed ANS" text). The resulting implementation
has been undergoing testing and refinement on both TOPS-10 and TOPS-20
for the last couple of months. I was hoping to freeze things for a
while and start putting together a clean distribution, but just last
week CompuServe began running KCC through the Plum Hall test suite, and
sure enough this has shaken out a number of minor bugs (total thus
far looks like KCC 9, PH 1). Currently I'm waiting to see if any more
turn up before starting on the distribution.
The directory structure for the new KCC is quite different. I have
split the library routines into several subdirectories, and the
building process puts all binaries into a single directory which can
be configured for a specific machine or system. This was necessary so
I could maintain versions for several independent configurations in parallel
without duplicating the sources for each one.
So, of course, the procedures that I relied on in the past for taking
snapshots or writing tapes no longer work and I need to revise them as
well. I do, however, have a single directory that could be FTP'd if any
Internet TOPS-20 sites are dying to do beta-testing with the binaries.
Note that $$CVER has been bumped so anything used with the new KCC must
be completely recompiled.
Sometime later I'll be sending more messages describing some of the new
features, where things are, etc...
--Ken
-------
29-Oct-89 09:38:11-PST,3277;000000000000
Return-Path: <@ugw.utcs.utoronto.ca:Delivr@UNCAEDU>
Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Sun, 29 Oct 89 09:38:01 PST
Received: from UNCAEDU.BITnet (stdin) by ugw.utcs.utoronto.ca with SMTP id 57378; Sun, 29 Oct 89 12:38:09 EST
Date: Sun, 29 Oct 89 02:08:41 EST
From: Delivr%[email protected]
Subject: Undeliverable Mail
To: [email protected]
Comment: reason for return --
Comment: Unknown host or domain
Comment: decnet - %SYSTEM-F-NOSUCHNODE, remote node is unknown
Comment: vmsmail - %SYSTEM-F-NOSUCHNODE, remote node is unknown
Comment: the affected addresses follow ...
Comment: [email protected]
Message-Id: <[email protected]>
Start of returned message
Received: from CUNYVM.BITNET by UNCAEDU.BITnet with BSMTP via BITNET ;
Sat, 28 Oct 89 23:53:20 MDT
Received: From CUNYVM(MAILER) by UNCAEDU with RSCS id 9168
for MAILER@UNCAEDU; Sat, 28 Oct 89 23:53 MDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.03B) with BSMTP id 1399; Sun
,
29 Oct 89 01:09:58 EDT
Received: from NIC.DDN.MIL by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.1MX) with TCP;
Sun, 29 Oct 89 01:09:51 EDT
Date: Thu, 26 Oct 89 13:56:01 PDT
From: Ken Harrenstien <[email protected]>
Subject: ANSI KCC coming soon
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I wanted to reassure people that ANSI KCC does exist and I'm still trying
to get it into shape for distribution. Here's the story thus far:
With support from CompuServe, I spent most of the summer upgrading KCC
to both run on TOPS-10 and conform to the latest version of ANSI C
(formally still a "proposed ANS" text). The resulting implementation
has been undergoing testing and refinement on both TOPS-10 and TOPS-20
for the last couple of months. I was hoping to freeze things for a
while and start putting together a clean distribution, but just last
week CompuServe began running KCC through the Plum Hall test suite, and
sure enough this has shaken out a number of minor bugs (total thus
far looks like KCC 9, PH 1). Currently I'm waiting to see if any more
turn up before starting on the distribution.
The directory structure for the new KCC is quite different. I have
split the library routines into several subdirectories, and the
building process puts all binaries into a single directory which can
be configured for a specific machine or system. This was necessary so
I could maintain versions for several independent configurations in parallel
without duplicating the sources for each one.
So, of course, the procedures that I relied on in the past for taking
snapshots or writing tapes no longer work and I need to revise them as
well. I do, however, have a single directory that could be FTP'd if any
Internet TOPS-20 sites are dying to do beta-testing with the binaries.
Note that $$CVER has been bumped so anything used with the new KCC must
be completely recompiled.
Sometime later I'll be sending more messages describing some of the new
features, where things are, etc...
--Ken
-------
End of returned message
31-Oct-89 20:37:44-PST,2232;000000000000
Date: Tue, 31 Oct 89 20:35:50 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 26-Oct-89 14:00:38
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Date: Thu, 26 Oct 89 13:56:01 PDT
From: Ken Harrenstien <[email protected]>
Subject: ANSI KCC coming soon
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I wanted to reassure people that ANSI KCC does exist and I'm still trying
to get it into shape for distribution. Here's the story thus far:
With support from CompuServe, I spent most of the summer upgrading KCC
to both run on TOPS-10 and conform to the latest version of ANSI C
(formally still a "proposed ANS" text). The resulting implementation
has been undergoing testing and refinement on both TOPS-10 and TOPS-20
for the last couple of months. I was hoping to freeze things for a
while and start putting together a clean distribution, but just last
week CompuServe began running KCC through the Plum Hall test suite, and
sure enough this has shaken out a number of minor bugs (total thus
far looks like KCC 9, PH 1). Currently I'm waiting to see if any more
turn up before starting on the distribution.
The directory structure for the new KCC is quite different. I have
split the library routines into several subdirectories, and the
building process puts all binaries into a single directory which can
be configured for a specific machine or system. This was necessary so
I could maintain versions for several independent configurations in parallel
without duplicating the sources for each one.
So, of course, the procedures that I relied on in the past for taking
snapshots or writing tapes no longer work and I need to revise them as
well. I do, however, have a single directory that could be FTP'd if any
Internet TOPS-20 sites are dying to do beta-testing with the binaries.
Note that $$CVER has been bumped so anything used with the new KCC must
be completely recompiled.
Sometime later I'll be sending more messages describing some of the new
features, where things are, etc...
--Ken
-------
-------
2-Feb-90 15:07:12-PST,1674;000000000000
Return-Path: <[email protected]>
Received: from science.utah.edu by NIC.DDN.MIL with TCP; Fri, 2 Feb 90 15:06:03 PST
Date: Fri 2 Feb 90 15:27:36-MST
From: "Nelson H.F. Beebe" <[email protected]>
Subject: Error in putenv() in <KCC-5.LIB>GETENV.C
To: [email protected]
cc: [email protected]
X-US-Mail: "Center for Scientific Computing, South Physics, University of Utah, Salt Lake City, UT 84112"
X-Telephone: (801) 581-5254
Message-ID: <[email protected]>
File
FES:<KCC-5.LIB>
GETENV.C.18;P777752 4 8928(7) 1-Jun-87 23:11:58 KLH
has an error in putenv():
@diff getenv.c.18 getenv.c.21
104c104
< if (*np == 0 || --i > 0) /* If not in name=val format */
---
> if ((*np == 0) || ((--i) < 0)) /* If not in name=val format */
Note that the test was > 0; it should be < 0.
I was unable to recompile getenv.c here without inserting
#if 0 ... #endif at
201a202
> #if 0
327a329
> #endif /* 0 */
because our unv:monsym.unv doesn't have the .TTxxx terminal
types referred to there.
If you have executables that use putenv(), you can DDT them
as follows:
@get foo.exe
@ddt
DDT
PUTENV+14/ SOSG 3,-14(17) sosl 3,-14(17)
^Z
@save foo.exe
This finally trounces a bug that affected my gmake
(generalized make) implementation on TOPS-20; before the
patch, it always said:
%Debug: arg_flags(): putenv("MAKEFLAGS=-n") FAILED
Actually, I'm now going to supply a private version of
getenv() and putenv(), because for gmake, putenv() has to
put things into the environment inherited by children, so it
has to be done with a logical name.
-------
8-Mar-90 16:11:02-PST,3194;000000000000
Date: Thu, 8 Mar 90 16:00:10 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 8-Mar-90 15:26:25
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Date: Thu, 8 Mar 90 15:26:19 PST
From: Ken Harrenstien <[email protected]>
Subject: ANSI KCC: come and get it!
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
After so long, it's hard to believe -- but the ANSI version of KCC
is finally ready for network distribution! Thanks to CompuServe for
time support, SRI for hardware support, and Systems Concepts for the
final nudge.
You will need a new directory tree; you should NOT try to simply
update your existing KCC directories. It is best to start by first
FTPing these files from NIC.DDN.MIL:
KCCDIST:OBTAIN.DOC
KCCDIST:INSTAL.DOC
KCCDIST:-FTP-.MIC
For convenience, I am enclosing the new portion of KCCDIST:NEWS.TXT here:
----------------------------------
03/06/90 KCC 653, LIBC 606: <2,,3> Sixth formal distribution snapshot
General:
There are MANY changes in this version. The biggest and most
important is that KCC now supports the proposed ANSI C standard (as of
the December 7, 1988 draft), and almost all of the visible changes
stem from this. In particular, many library routines have been added
or modified, and for this reason the library version number has
been bumped to ensure that previously compiled modules cannot be
loaded without warning messages.
The other major bit of news is that KCC has been ported to
TOPS-10, including most of the library routines. The need to support
multiple configurations from the same sources led to a reorganization
of the way KCC source files are stored and used. You will definitely
need to read <KCC-6.BUILD>BUILD.DOC to learn again how to recompile KCC.
KCC+LIBC details:
Far too many changes to list here. You will have to read the new
CC.DOC and LIBC.DOC files to get an idea of what is different. You
really should get a copy of some reference that describes ANSI C (H&S 2,
K&R 2, or the draft itself); without these references, some error messages
may leave you mystified. I did not seriously attempt to retain complete
compatibility with former versions of KCC, judging that ANSI compatibility
was more important in the long run. Thus, things that previously compiled
may now fail to compile under the new ANSI regime.
Acknowledgements:
This version would never have happened without the help of
CompuServe Inc. and SRI International. The bulk of my time spent on
ANSI and TOPS-10 was supported by CSI, while SRI provided its own
local computer facilities -- many megabytes and many many CPU hours on
SRI's own DEC-2065 and SUN 3/60. In particular, thanks to:
Benny Jones (CSI everything)
Frank Kuo (SRI NISC facilities)
Steve Milunovic (SRI ISO facilities)
Dave Prosser (knotty dpANS queries)
-------
-------
8-Mar-90 18:22:14-PST,3618;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Thu, 8 Mar 90 18:22:02 PST
Received: by decwrl.dec.com; id AA01332; Thu, 8 Mar 90 18:20:42 -0800
Received: by imagen.imagen.com (5.51/Imagen-1.1)
id AA15394; Thu, 8 Mar 90 16:12:20 PST
Date: Thu, 8 Mar 90 16:12:20 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
To: [email protected]
----- Transcript of session follows -----
550 kchen... User unknown
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: by imagen.imagen.com (5.51/Imagen-1.1)
id AA15392; Thu, 8 Mar 90 16:12:20 PST
Received: by decwrl.dec.com; id AA14041; Thu, 8 Mar 90 15:46:17 -0800
Date: Thu, 8 Mar 90 15:26:19 PST
From: Ken Harrenstien <[email protected]>
Subject: ANSI KCC: come and get it!
To: [email protected]
Cc: [email protected]
Message-Id: <[email protected]>
After so long, it's hard to believe -- but the ANSI version of KCC
is finally ready for network distribution! Thanks to CompuServe for
time support, SRI for hardware support, and Systems Concepts for the
final nudge.
You will need a new directory tree; you should NOT try to simply
update your existing KCC directories. It is best to start by first
FTPing these files from NIC.DDN.MIL:
KCCDIST:OBTAIN.DOC
KCCDIST:INSTAL.DOC
KCCDIST:-FTP-.MIC
For convenience, I am enclosing the new portion of KCCDIST:NEWS.TXT here:
----------------------------------
03/06/90 KCC 653, LIBC 606: <2,,3> Sixth formal distribution snapshot
General:
There are MANY changes in this version. The biggest and most
important is that KCC now supports the proposed ANSI C standard (as of
the December 7, 1988 draft), and almost all of the visible changes
stem from this. In particular, many library routines have been added
or modified, and for this reason the library version number has
been bumped to ensure that previously compiled modules cannot be
loaded without warning messages.
The other major bit of news is that KCC has been ported to
TOPS-10, including most of the library routines. The need to support
multiple configurations from the same sources led to a reorganization
of the way KCC source files are stored and used. You will definitely
need to read <KCC-6.BUILD>BUILD.DOC to learn again how to recompile KCC.
KCC+LIBC details:
Far too many changes to list here. You will have to read the new
CC.DOC and LIBC.DOC files to get an idea of what is different. You
really should get a copy of some reference that describes ANSI C (H&S 2,
K&R 2, or the draft itself); without these references, some error messages
may leave you mystified. I did not seriously attempt to retain complete
compatibility with former versions of KCC, judging that ANSI compatibility
was more important in the long run. Thus, things that previously compiled
may now fail to compile under the new ANSI regime.
Acknowledgements:
This version would never have happened without the help of
CompuServe Inc. and SRI International. The bulk of my time spent on
ANSI and TOPS-10 was supported by CSI, while SRI provided its own
local computer facilities -- many megabytes and many many CPU hours on
SRI's own DEC-2065 and SUN 3/60. In particular, thanks to:
Benny Jones (CSI everything)
Frank Kuo (SRI NISC facilities)
Steve Milunovic (SRI ISO facilities)
Dave Prosser (knotty dpANS queries)
-------
8-Mar-90 19:02:46-PST,4194;000000000000
Return-Path: <@ugw.utcs.utoronto.ca:Delivr@UNCAEDU>
Received: from ugw.utcs.utoronto.ca by NIC.DDN.MIL with TCP; Thu, 8 Mar 90 19:02:34 PST
Received: from UNCAEDU.BITnet (stdin) by ugw.utcs.utoronto.ca with SMTP id 58365; Thu, 8 Mar 90 22:01:41 EST
Date: Thu, 8 Mar 90 21:54:08 EST
From: Delivr%[email protected]
Subject: Undeliverable Mail
To: [email protected]
Comment: reason for return --
Comment: Unknown host or domain
Comment: decnet - %SYSTEM-F-NOSUCHNODE, remote node is unknown
Comment: vmsmail - %SYSTEM-F-NOSUCHNODE, remote node is unknown
Comment: the affected addresses follow ...
Comment: [email protected]
Message-Id: <[email protected]>
Start of returned message
Received: from CUNYVM.BITNET by UNCAEDU.BITnet with BSMTP via BITNET ;
Thu, 8 Mar 90 19:45:54 MST
Received: From CUNYVMV2(MAILER) by UNCAEDU with RSCS id 7246
for MAILER@UNCAEDU; Thu, 8 Mar 90 19:45 MDT
Received: from CUNYVM by CUNYVM.BITNET (Mailer R2.03B) with BSMTP id 1430; Thu
,
08 Mar 90 18:47:18 EST
Received: from NIC.DDN.MIL by CUNYVM.CUNY.EDU (IBM VM SMTP R1.2.2MX) with TCP;
Thu, 08 Mar 90 18:47:12 EST
Date: Thu, 8 Mar 90 15:26:19 PST
From: Ken Harrenstien <[email protected]>
Subject: ANSI KCC: come and get it!
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
After so long, it's hard to believe -- but the ANSI version of KCC
is finally ready for network distribution! Thanks to CompuServe for
time support, SRI for hardware support, and Systems Concepts for the
final nudge.
You will need a new directory tree; you should NOT try to simply
update your existing KCC directories. It is best to start by first
FTPing these files from NIC.DDN.MIL:
KCCDIST:OBTAIN.DOC
KCCDIST:INSTAL.DOC
KCCDIST:-FTP-.MIC
For convenience, I am enclosing the new portion of KCCDIST:NEWS.TXT here:
----------------------------------
03/06/90 KCC 653, LIBC 606: <2,,3> Sixth formal distribution snapshot
General:
There are MANY changes in this version. The biggest and most
important is that KCC now supports the proposed ANSI C standard (as of
the December 7, 1988 draft), and almost all of the visible changes
stem from this. In particular, many library routines have been added
or modified, and for this reason the library version number has
been bumped to ensure that previously compiled modules cannot be
loaded without warning messages.
The other major bit of news is that KCC has been ported to
TOPS-10, including most of the library routines. The need to support
multiple configurations from the same sources led to a reorganization
of the way KCC source files are stored and used. You will definitely
need to read <KCC-6.BUILD>BUILD.DOC to learn again how to recompile KCC.
KCC+LIBC details:
Far too many changes to list here. You will have to read the new
CC.DOC and LIBC.DOC files to get an idea of what is different. You
really should get a copy of some reference that describes ANSI C (H&S 2,
K&R 2, or the draft itself); without these references, some error messages
may leave you mystified. I did not seriously attempt to retain complete
compatibility with former versions of KCC, judging that ANSI compatibility
was more important in the long run. Thus, things that previously compiled
may now fail to compile under the new ANSI regime.
Acknowledgements:
This version would never have happened without the help of
CompuServe Inc. and SRI International. The bulk of my time spent on
ANSI and TOPS-10 was supported by CSI, while SRI provided its own
local computer facilities -- many megabytes and many many CPU hours on
SRI's own DEC-2065 and SUN 3/60. In particular, thanks to:
Benny Jones (CSI everything)
Frank Kuo (SRI NISC facilities)
Steve Milunovic (SRI ISO facilities)
Dave Prosser (knotty dpANS queries)
-------
End of returned message
12-Mar-90 22:17:15-PST,3140;000000000000
Date: Mon, 12 Mar 90 22:12:27 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 8-Mar-90 15:26:25
Message failed for the following:
white%[email protected]: 550 (BHST) Unknown host/domain name in "white%[email protected]"
[email protected]: 550 Host name "TOPS20.DEC.COM" unknown, recipient rejected
------------
Date: Thu, 8 Mar 90 15:26:19 PST
From: Ken Harrenstien <[email protected]>
Subject: ANSI KCC: come and get it!
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
After so long, it's hard to believe -- but the ANSI version of KCC
is finally ready for network distribution! Thanks to CompuServe for
time support, SRI for hardware support, and Systems Concepts for the
final nudge.
You will need a new directory tree; you should NOT try to simply
update your existing KCC directories. It is best to start by first
FTPing these files from NIC.DDN.MIL:
KCCDIST:OBTAIN.DOC
KCCDIST:INSTAL.DOC
KCCDIST:-FTP-.MIC
For convenience, I am enclosing the new portion of KCCDIST:NEWS.TXT here:
----------------------------------
03/06/90 KCC 653, LIBC 606: <2,,3> Sixth formal distribution snapshot
General:
There are MANY changes in this version. The biggest and most
important is that KCC now supports the proposed ANSI C standard (as of
the December 7, 1988 draft), and almost all of the visible changes
stem from this. In particular, many library routines have been added
or modified, and for this reason the library version number has
been bumped to ensure that previously compiled modules cannot be
loaded without warning messages.
The other major bit of news is that KCC has been ported to
TOPS-10, including most of the library routines. The need to support
multiple configurations from the same sources led to a reorganization
of the way KCC source files are stored and used. You will definitely
need to read <KCC-6.BUILD>BUILD.DOC to learn again how to recompile KCC.
KCC+LIBC details:
Far too many changes to list here. You will have to read the new
CC.DOC and LIBC.DOC files to get an idea of what is different. You
really should get a copy of some reference that describes ANSI C (H&S 2,
K&R 2, or the draft itself); without these references, some error messages
may leave you mystified. I did not seriously attempt to retain complete
compatibility with former versions of KCC, judging that ANSI compatibility
was more important in the long run. Thus, things that previously compiled
may now fail to compile under the new ANSI regime.
Acknowledgements:
This version would never have happened without the help of
CompuServe Inc. and SRI International. The bulk of my time spent on
ANSI and TOPS-10 was supported by CSI, while SRI provided its own
local computer facilities -- many megabytes and many many CPU hours on
SRI's own DEC-2065 and SUN 3/60. In particular, thanks to:
Benny Jones (CSI everything)
Frank Kuo (SRI NISC facilities)
Steve Milunovic (SRI ISO facilities)
Dave Prosser (knotty dpANS queries)
-------
-------
17-Apr-90 16:34:19-PDT,622;000000000000
Return-Path: <[email protected]>
Received: from vall.dsv.su.se by NIC.DDN.MIL with TCP; Tue, 17 Apr 90 16:34:00 PDT
Received: from ATHENA.DSV.SU.SE by vall.dsv.su.se (4.0/SMI-4.0)
id AA11053; Wed, 18 Apr 90 01:09:54 +0200
Date: Wed 18 Apr 90 01:09:00
From: "Bertil Hansson" <[email protected]>
Subject: Please add this site to the list.
To: [email protected]
Organization: University of Stockholm, Sweden
Message-Id: <[email protected]>
I will happily receive announcements under the alias
[email protected]
Thank you!
-------
14-May-90 16:06:38-PDT,1434;000000000000
Date: Mon, 14 May 90 10:51:42 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 9-May-90 06:55:29
Message undeliverable and dequeued after 5 days:
*fs:<c.dist>[email protected].#Internet: Disk quota exceeded
------------
Received: from vera.nada.kth.se by NIC.DDN.MIL with TCP; Wed, 9 May 90 06:55:21 PDT
Date: Tue, 8 May 90 15:03:54 +0200
From: Jan Michael Rynning <[email protected]>
Subject: Bug fix for KCC-6 tadl_from_utime()
Sender: [email protected]
To: [email protected]
Reply-To: Jan Michael Rynning <[email protected]>
Organization: Royal Institute of Technology, Stockholm, Sweden.
Address: NADA, KTH, S-100 44 Stockholm, Sweden.
Telephone: +46-8-7906288
Message-ID: <[email protected]>
In KCCDIST:<KCC-6.LIB.USYS>TIME.C.87, in function tadl_from_utime():
+ ((utad%DAYSECS)<<HBITS + DAYSECS/2)/DAYSECS /* # units of rem */
Due to operator precendence, an extra pair of parentheses is required:
+ (((utad%DAYSECS)<<HBITS) + DAYSECS/2)/DAYSECS /* # units of rem */
Jan Michael Rynning, [email protected]
Department of Numerical Analysis If you can't fully handle domains:
and Computing Science, ARPA: jmr%[email protected]
Royal Institute of Technology, UUCP: {uunet,mcvax,...}!nada.kth.se!jmr
S-100 44 Stockholm, BITNET: jmr@sekth
Sweden. Phone: +46-8-7906288
-------
14-May-90 16:06:40-PDT,1269;000000000000
Date: Mon, 14 May 90 10:51:43 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 9-May-90 06:55:47
Message undeliverable and dequeued after 5 days:
*fs:<c.dist>[email protected].#Internet: Disk quota exceeded
------------
Received: from vera.nada.kth.se by NIC.DDN.MIL with TCP; Wed, 9 May 90 06:55:44 PDT
Date: Tue, 8 May 90 16:01:27 +0200
From: Jan Michael Rynning <[email protected]>
Subject: BSD4.3 utimes() for KCC-6
Sender: [email protected]
To: [email protected]
Reply-To: Jan Michael Rynning <[email protected]>
Organization: Royal Institute of Technology, Stockholm, Sweden.
Address: NADA, KTH, S-100 44 Stockholm, Sweden.
Telephone: +46-8-7906288
Message-ID: <[email protected]>
/*
** UTIMES - set file times
**
** (c) Copyright Jan Michael Rynning 1990
*/
#include <sys/usysig.h>
#include <sys/time.h>
extern int utime();
int utimes(file, tvp)
char *file;
struct timeval tvp[2];
{
time_t timep[2];
USYS_BEG();
timep[0] = tvp[0].tv_sec; /* copy the read time */
timep[1] = tvp[1].tv_sec; /* copy the write time */
USYS_RETVOLATILE(utime(file, timep)); /* let utime() do the job */
}
-------