Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_FS_1_19910112
-
c/seers.mail
There are no other files named seers.mail in the archive.
16-Nov-85 04:44:53-PST,711;000000000000
Mail-From: KLH created at 16-Nov-85 04:44:44
Date: Sat 16 Nov 85 04:44:44-PST
From: Ken Harrenstien <[email protected]>
Subject: New list
To: [email protected]
Message-ID: <[email protected]>
This list should help everyone keep up on the status of C stuff, which is
likely to be evolving steadily over the next few months. A log is in
SS:<C>SEERS.MAIL for reference.
If you encounter a KCC/library bug, or some kind of problem with your
C program that you need assistance with, use the SEERS list. This will
help ensure that everyone else is aware of the problem and the solution
(or at least the status of things). I would rather see too many messages
than too few.
-------
18-Nov-85 18:19:17-PST,459;000000000000
Mail-From: KLH created at 18-Nov-85 18:19:15
Date: Mon 18 Nov 85 18:19:15-PST
From: Ken Harrenstien <[email protected]>
Subject: New CIFP routine ID_ITMDEL
To: [email protected]
cc: [email protected], [email protected]
Message-ID: <[email protected]>
I have created a new routine called ID_ITMDEL which takes one argument,
an item #, and deletes that item from the current record. An error (with
error message) is possible.
-------
18-Nov-85 18:40:35-PST,418;000000000001
Mail-From: KLH created at 18-Nov-85 18:40:34
Date: Mon 18 Nov 85 18:40:34-PST
From: Ken Harrenstien <[email protected]>
Subject: ID_STR information
To: [email protected]
Message-ID: <[email protected]>
Ian and Mimi have expressed confusion about ID_STRs. I have written
up a short blurb and stuffed it into <NICPROG>CIFP.DOC which eventually
should contain more help of that nature.
-------
19-Nov-85 15:35:20-PST,2852;000000000000
Mail-From: KLH created at 19-Nov-85 15:35:15
Date: Tue 19 Nov 85 15:35:15-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: ifpack-aux problem
To: [email protected]
cc: [email protected], [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Sorry, I wasn't shouting, I was emphasizing the root of the problem.
(1) Every C identifier must ****always**** be ****properly**** declared
prior to its first use, with the sole exception of INT function names.
(2) Function arguments in C are just another case of identifiers, and
the type of the declared arguments must match the type of the
values furnished to the call.
To "cast" something does not mean that "this expression value is of
this type". It means "CONVERT this expression value from its present
type to a value of this new type". The fact that most such casts
produce no actual conversion code should not mislead you into thinking
that a cast is a declaration instead of a conversion operation.
Furthermore, the conversion operation will not work properly if the
compiler has the wrong idea of the "present type" of the expression.
This is why it is so important to make sure you get the type right the
FIRST time. Otherwise you have no guarantee that any C compiler will
produce correct code.
Example of incorrect casting:
char *cp;
cp = (char *)malloc(100);
This will compile, and may even work on some machines, but is
incorrect because in the absence of any declaration, the compiler
must assume that "malloc" is type (int) and thus the conversion
that takes place is one converting an (int) to a (char *).
It doesn't know that malloc is really returning a char pointer rather
than an integer. The fix is to declare malloc properly:
char *malloc(), *cp;
cp = malloc(100);
The fact that the code may work in certain situations does not
necessarily mean that it is correct. Many old PDP-11 C programs took
great liberties in dealing with types since they "knew" that a
structure pointer was the same as a char pointer, and a char pointer
could be treated like a integer, and so on. They blow up horribly
when transported to different machines, where pointers may not even be
the same size as integers, much less have the same format! C
compilers nowadays try to be much stricter about enforcing type
consistency, but can still be flummoxed by function calls (the type info
isn't passed to the linking loader).
You have to understand how PDP-10 byte pointers and extended addressing
work in order to understand why your bug remained hidden. I tried to
explain this in an earlier message. If that did not take, we should
probably have a little pow-wow where I can draw pictures and stuff.
-------
20-Nov-85 13:51:38-PST,455;000000000000
Mail-From: KLH created at 20-Nov-85 13:51:35
Date: Wed 20 Nov 85 13:51:35-PST
From: Ken Harrenstien <[email protected]>
Subject: <NICPROG>CIFP.DOC
To: [email protected]
Message-ID: <[email protected]>
This file now attempts to document everything that CIFP provides.
If you notice anything which is not covered but which should be,
let me know. It is still being worked on but is at the stage where
feedback is useful.
-------
21-Nov-85 10:32:20-PST,686;000000000000
Mail-From: SKAHN created at 21-Nov-85 10:32:13
Date: Thu 21 Nov 85 10:32:13-PST
From: Susan Kahn <[email protected]>
Subject: Re: ifpack-aux problem
To: [email protected]
cc: [email protected], [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Ken,
Thanks for your response. I would very much like to understand extended
addressing. Let's set a time when you could explain. I'll be here until
around 2:30 today. I'm usually in on Tuesdays, Thursdays and Fridays,
but my hours are a bit sporadic, and usually I need to leave in the early
afternoon.
Susan
-------
21-Nov-85 12:25:25-PST,727;000000000001
Mail-From: KLH created at 21-Nov-85 12:25:20
Date: Thu 21 Nov 85 12:25:20-PST
From: Ken Harrenstien <[email protected]>
Subject: C meeting
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I'd like to have a get-together of all C programmers on Tuesday,
11/26, 1:00pm (place TBD). Glenn has suggested that we need to
compare notes and decide how we should organize our various
subroutines into more sharable form. This will also be a chance to
go over the C stuff that still needs to be developed and see which
aspects should have highest priority.
Let me know if you can't make it. This time was picked so that
Susan (and I hope Glenn) could attend.
-------
21-Nov-85 14:00:34-PST,536;000000000001
Mail-From: FRED created at 21-Nov-85 14:00:21
Date: Thu 21 Nov 85 14:00:21-PST
From: Fred Ostapik <[email protected]>
Subject: One more item for the inaugural C meeting
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Folks,
Since all the programmers will be congregated together Tuesday, I would
like to make another pass on the list of programming assignments. So please
add it to the agenda and at Ken's request it will be the last item of
business.
Fred
-------
22-Nov-85 13:22:58-PST,666;000000000000
Mail-From: KLH created at 22-Nov-85 13:22:56
Date: Fri 22 Nov 85 13:22:56-PST
From: Ken Harrenstien <[email protected]>
Subject: KCC and CLIB
To: [email protected]
Message-ID: <[email protected]>
I have installed new uptodate versions of KCC and CLIB. From this point
on there will continue to be frequent new versions, which will not
be announced unless some particularly noteworthy change is installed.
As a general rule, if you find that a program which used to compile OK has
suddenly broken, and suspect the compiler or library, check with me or
Ian -- you might well be right, and it should be caught as soon as possible.
-------
22-Nov-85 13:26:05-PST,459;000000000000
Mail-From: KLH created at 22-Nov-85 13:26:04
Date: Fri 22 Nov 85 13:26:04-PST
From: Ken Harrenstien <[email protected]>
Subject: New SCANF
To: [email protected]
Message-ID: <[email protected]>
SSCANF has been fixed. By the way, in general it is better not to use
SCANF on the stdin stream; using some other function like GETS to read a
line and then applying SSCANF on it tends to work better from a portability
viewpoint.
-------
22-Nov-85 13:41:01-PST,802;000000000000
Mail-From: MIMI created at 22-Nov-85 13:40:59
Date: Fri 22 Nov 85 13:40:59-PST
From: sue
Subject: Re: <NICPROG>CIFP.DOC
Sender: [email protected]
To: [email protected]
cc: [email protected], [email protected]
Reply-To: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I finally got around to reading the CIFP documentation and it really
helps my understanding of things.
One comment:
We had been declaring variables to store item numbers and
record indexes as INT rather than "ID_ITM" and "ID_RIX."
This worked but I will change all declarations over. My
question concerns the <nicprog>iditem.h file. Will
the compiler correctly interpret the types of the symbolic
constants declared there?
-------
22-Nov-85 13:46:15-PST,594;000000000000
Mail-From: KLH created at 22-Nov-85 13:46:12
Date: Fri 22 Nov 85 13:46:12-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: <NICPROG>CIFP.DOC
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Yes, the things in iditem.h are integer constants and as long as some
default conversion exists, the compiler will use it. ID_ITM and ID_RIX
are just "int" right now; I thought it would be wise to use our own typedefs
just in case someday the type has to change.
-------
2-Jan-86 18:28:52-PST,434;000000000000
Mail-From: KLH created at 2-Jan-86 18:28:51
Date: Thu 2 Jan 86 18:28:51-PST
From: Ken Harrenstien <[email protected]>
Subject: More CARM copies
To: [email protected]
Message-ID: <[email protected]>
Joy has just received some more copies of Harbison & Steele ("C: A
Reference Manual"). If there are any C programmers who are still
missing a copy of this, or the Kernighan&Ritchie book, let me know.
-------
21-Jan-86 00:37:35-PST,1475;000000000000
Mail-From: KLH created at 21-Jan-86 00:37:32
Date: Tue 21 Jan 86 00:37:32-PST
From: Ken Harrenstien <[email protected]>
Subject: New C compiler installed
To: [email protected]
Message-ID: <[email protected]>
A new C compiler has been installed. This is the version that we have
been working on for some time, and incorporates several bug fixes.
If you suspect that the new compiler may have problems, compare its output
with that of the old compiler (CC.EXE.109), but I don't expect that
any will appear.
Most changes were done to clear up the internal workings of the compiler
and remove various inconsistencies. Input processing was made more
efficient and a good deal of bullet-proofing added (which will catch
things that used to invisibly overflow, like long constant strings).
Double-precision floating point arithmetic and comparisons now should
work properly (protected from excessive optimization). Command line
switch processing is done better. The "entry" statement is no longer
necessary for library files; in fact any .REL file can now be used
as a library module.
The main user visible change is that KCC will, in general, now emit
two files rather than just one: foo.PRE and foo.FAI instead of just
foo.FAI. Normal assembly will crunch and delete both files.
This is all documented, along with more details on how symbols are
exported to the linker and other useful things, in a new C:CC.DOC file.
-------
23-Jan-86 13:06:25-PST,345;000000000000
Mail-From: HSS created at 23-Jan-86 13:06:23
Date: Thu 23 Jan 86 13:06:22-PST
From: Harry Sameshima <[email protected]>
Subject: file pointers
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
If I get a file pointer from fopen() is there an easy way to get a hold
of the JFN?
Harry
-------
23-Jan-86 13:26:42-PST,505;000000000000
Mail-From: KLH created at 23-Jan-86 13:26:39
Date: Thu 23 Jan 86 13:26:38-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: file pointers
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
It is possible to get the JFN but you would have to know a little too
much about the internals of STDIO. Perhaps a non-portable call could
be provided. What would you need it for?
-------
23-Jan-86 13:31:07-PST,390;000000000000
Mail-From: HSS created at 23-Jan-86 13:31:05
Date: Thu 23 Jan 86 13:31:04-PST
From: Harry Sameshima <[email protected]>
Subject: Re: file pointers
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I want to use the JFNS JSYS to figure out the generation number of the
file.
Harry
-------
24-Jan-86 11:04:31-PST,472;000000000000
Mail-From: KLH created at 24-Jan-86 11:04:28
Date: Fri 24 Jan 86 11:04:28-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: file pointers
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Well, yes, but why do you need the generation number? What I'm looking
for is a portable way to do what you want, but I don't have any
context yet.
-------
24-Jan-86 12:19:44-PST,802;000000000000
Mail-From: HSS created at 24-Jan-86 12:19:41
Date: Fri 24 Jan 86 12:19:41-PST
From: Harry Sameshima <[email protected]>
Subject: Re: file pointers
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
The host table generator reads the old host table to get the version number
and the comments about format, etc. Mary wanted the comments to be in a
separate file for easy editing. I was worried that a simple editing error
could really screw things up. Since the host table version number is supposed
to be the same as the file generation number it seemed more reasonable to get
the number with a JFNS rather than expect it to always be in the same place
in some random text file.
Harry
-------
24-Jan-86 16:42:12-PST,545;000000000000
Mail-From: KLH created at 24-Jan-86 16:42:10
Date: Fri 24 Jan 86 16:42:10-PST
From: Ken Harrenstien <[email protected]>
Subject: New KCC
To: [email protected]
Message-ID: <[email protected]>
Upgraded preprocessor to handle #elif and the "defined" operator. The
KCC preprocessor should now handle everything from H&S. However, code
intended to be widely portable should not use either of those two
additional features, since some older compilers (notably the standard
PDP-11 compiler) do not implement them.
-------
4-Feb-86 10:52:33-PST,4885;000000000000
Mail-From: FRED created at 4-Feb-86 10:52:29
Date: Tue 4 Feb 86 10:52:28-PST
From: Fred Ostapik <[email protected]>
Subject: Programmers' Meeting
To: [email protected], [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Just a reminder that the programmers' meeting is scheduled for 2:00 this
afternoon in the AI conference room. I'm including the latest
programmers' assignments sheet for you to look over.
Fred
PROGRAMMING TASK ASSIGNMENTS 01/13/86
----------------------------
PROGRAMMER PROJECT/ ESTIMATED ESTIMATED STATUS *
TASK TIME as of COMPLETION
01/13 DATE
---------- ------------------------------- --------- ---------- ------
Audit Trail/
------------
HSS Multiple Login Reports 15hrs 02/15/86 Active
Local Time Modification 15hrs 02/15/86 Wait
Do a 'C' version of 'Gather' 90hrs 03/31/86 Pending
Fred/Peter Report/Part II 50hrs 02/28/86 Active
Fred/StJoh Specs for Working System 25hrs 02/28/86 Active
Fred/PMO Equipment Proposal 10hrs 01/30/86 Done
Fred/Hss Streamline the process of
searching the data 15hrs 02/20/86
Domain/
-------
MKL Query Done
Bugs in BRL Server Wait
S.Kahn Put domain names into host name 15hrs 01/30/86 Done
fields (C programming).
Ken Apply pressure to get zone file
transfers program implemented. Pending
'C'
---
KEN Math Library Pending
Allow database programs to use
logical names. 8hrs 11/01/85 Active
Changes to database package to
use page reload feature. Pending
Get Ian acquainted with 'C' &
its libraries. Active
Net-Performance
---------------
Ian Menu System 8hrs Waiting
Fred/ Heading Standardization 10hrs 01/30/86 Active
Snively
Register
--------
Jojo External Site Testing 35hrs 01/30/86 Active
Jojo Documentation 30hrs 02/28/86 Pending
Ian Mail Forwarding 10hrs 01/11/86 Done
Ian Server Cleanup Wait
MKL User program cleanup Wait
Usage
-----
Cross Prototype Report 45hrs 02/10/86 Active
Implement CRC check on usage
data 20hrs 02/28/86
Cross/HSS/ Set up process to keep subsidiary
Fred files updated 15hrs 02/15/86 Pending
Fred/PMO Initial reports - Specs 25hrs 01/17/86 Done
/BBN
Fred/PMO Working System - Specs 45hrs 02/28/86 Active
Biblio
------
Sherwood Biblio Server Active
Miller SAM Active
Conversion (AUGMENT to 'C')
---------------------------
HSS NICREG Back
SKahn NICSYS Ongoing 12/30/85 Active
Computer Facility
-----------------
Bob TAC port printing program (StJohn)
MKL Fix -RELAY/Exploder problem in MMAILR
Bring up new version of LSRSPL. Fix the problem
of not printing the full listing on large
listings
Fix MM to not spit out an extra page when single messages
are sent to the laser printer
Vivian Scribe - get latest version/
order postscript support(?)
Find out about hooking up LaserWriter
to Sun or 20
-------------------------------------------------------------------------------
* Active - Work in progress for the task
Back - Work to be done in the background (at the lowest priority)
Done - Task completed
Pending - Work assigned but not yet begun
Wait - Work is temporarily stopped pending results from other tasks
-------
5-Feb-86 11:54:58-PST,5938;000000000001
Mail-From: FRED created at 5-Feb-86 11:54:54
Date: Wed 5 Feb 86 11:54:53-PST
From: Fred Ostapik <[email protected]>
Subject: Verifty Prog Assignments
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Please look over the assigned sheets and make any corrections directly
to:
<FRED>Programmers-assignments.txt
or send me the corrections.
Fred
PROGRAMMING TASK ASSIGNMENTS 02/4/86
----------------------------
PROGRAMMER PROJECT/ ESTIMATED ESTIMATED STATUS *
TASK TIME as of COMPLETION
01/13 DATE
---------- ------------------------------- --------- ---------- ------
Audit Trail/
------------
HSS Multiple Login Reports 15hrs 02/15/86 Active
Local Time Modification 15hrs 02/15/86 Wait
Do a 'C' version of 'Gather' 90hrs 03/31/86 Pending
Fred/Peter Report/Part II 50hrs 02/28/86 Active
Fred/StJoh Specs for Working System 25hrs 02/28/86 Active
Fred/PMO Equipment Proposal 10hrs 01/30/86 Done
Fred/Hss Streamline the process of
searching the data 15hrs 02/20/86
Domain/
-------
MKL Query Done
Bugs in BRL Server Wait
Ken Apply pressure to get zone file
transfers program implemented. Pending
The only servers so far are BIND and a
TOPS20 version.
MKL Implement the TOPS20 version. Pending
SKAHN Modify MX and INADDR code Pending
'C'
---
KEN Math Library Done
Allow database programs to use
logical names. 8hrs 11/01/85 Done
Changes to database package to
use page reload feature. Pending
Get Ian acquainted with 'C' &
its libraries. Done
Modify the compiler to generate
'cleaner' code Active
Standardize the 'C' libraries Pending
Net-Performance
---------------
Ian Menu System 8hrs Waiting
Fred/ Heading Standardization 10hrs 01/30/86 Active
Snively
Register
--------
Jojo External Site Testing 35hrs 02/15/86 Active
Jojo Documentation 30hrs 02/28/86 Pending
Ian Mail Forwarding 10hrs 01/11/86 Done
Ian Server Cleanup Wait
MKL User program cleanup Wait
Usage
-----
Cross Prototype Report 45hrs 02/10/86 Active
Implement CRC check on usage
data 20hrs 02/28/86
Cross/HSS/ Set up process to keep subsidiary
Fred files updated 15hrs 02/15/86 Pending
Fred/PMO Initial reports - Specs 25hrs 01/17/86 Done
/BBN
Fred/PMO Working System - Specs 45hrs 02/28/86 Active
Biblio
------
Sherwood Biblio Server Active
SAM Active
Miller DOTS development (DBASE III applications) Active
Conversion (AUGMENT to 'C')
---------------------------
HSS NICREG (Most of it is converted
except for the code which generates
the guest cards) 35hrs 03/15/86 Back
SKahn NICSYS - Analyze what features are used 03/15/86 Back
HOTLIST conversion 40hrs 05/15/86 Active
Computer Facility
-----------------
Bob TAC port printing program (StJohn) Done
Bring up TEK (sic?) on the 20 Pend
Explore the possibility of acquiring the PC
version of TEK. Active
MKL Fix -RELAY/Exploder problem in MMAILR Back
Bring up new version of LSRSPL. Fix the problem
of not printing the full listing on large
listings Back
Fix MM to not spit out an extra page when single messages
are sent to the laser printer Back
Vivian Scribe - get latest version/
order postscript support(?) Active
Find out about hooking up LaserWriter
to Sun or 20 Active
-------------------------------------------------------------------------------
* Active - Work in progress for the task
Back - Work to be done in the background (at the lowest priority)
Done - Task completed
Pending - Work assigned but not yet begun
Wait - Work is temporarily stopped pending results from other tasks
-------
20-Feb-86 17:27:54-PST,713;000000000001
Mail-From: KLH created at 20-Feb-86 17:27:51
Date: Thu 20 Feb 86 17:27:51-PST
From: Ken Harrenstien <[email protected]>
Subject: New KCC version installed
To: [email protected]
Message-ID: <[email protected]>
In order to fix a bug that Susan Kahn reported, version 251 has been
installed -- a little earlier than I planned. This includes some changes
to the parsing of declarations, but nothing I would call user visible.
A new warning message you might see is "Null declaration" which means
an empty or meaningless declaration statement was encountered. This is
not an error of itself, but a warning is given because the user probably
is making some higher-level mistake.
-------
17-Mar-86 12:13:46-PST,455;000000000001
Mail-From: HSS created at 17-Mar-86 12:13:42
Date: Mon 17 Mar 86 12:13:41-PST
From: Harry Sameshima <[email protected]>
Subject: C bug
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Executing the following program gives me a result of zero. I don't think
that that is reasonable.
#include <stdio.h>
main()
{
int foo=500;
foo *= 3.141592654;
printf("foo=%d\n",foo);
}
Harry
-------
17-Mar-86 12:18:43-PST,336;000000000001
Mail-From: HSS created at 17-Mar-86 12:18:40
Date: Mon 17 Mar 86 12:18:39-PST
From: Harry Sameshima <[email protected]>
Subject: More on C bug
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
The Sun's compiler produces a program that says the result should be
1500.
Harry
-------
17-Mar-86 12:36:13-PST,924;000000000001
Mail-From: KLH created at 17-Mar-86 12:36:09
Date: Mon 17 Mar 86 12:36:08-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: C bug
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Boy oh boy. It looks as if KCC's code generator assumes that the only
kind of assignment operation feasible for double words is simple
assignment (just like for structures). So it completely ignores the
multiplication and gets confused. A case of inconsistency between the
parser's type checking and the generator's actual capabilities. By
coincidence that is exactly what I am revising at the moment, so I
expect this bug will be fixed within a week. Can special-case it sooner
if it is urgent. (In the meantime you can get around it by not using
assignment arithmetic (*=, +=, etc) on doubles).
-------
27-Mar-86 09:25:08-PST,802;000000000001
Mail-From: HSS created at 27-Mar-86 09:25:02
Date: Thu 27 Mar 86 09:25:01-PST
From: Harry Sameshima <[email protected]>
Subject: Another C problem
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Perhaps C should give me an arithmetic overflow message.....but then again,
maybe that isn't required by K&R.
/* 17179869184 is 2^34 */
#include <stdio.h>
main()
{
printf("%d\n",17179869184+17179869184);
}
[PHOTO: Recording initiated Thu 27-Mar-86 9:20am]
End of PS:<HSS>COMAND.CMD.7
!exECUTE (FROM) test.c
KCC: TEST
<AUDIT-TRAIL>TEST.PRE.2
<AUDIT-TRAIL>TEST.FAI.3
FAIL: TEST
LINK: Loading
[LNKXCT TEST execution]
-34359738368
!pop
[PHOTO: Recording terminated Thu 27-Mar-86 9:20am]
Harry
-------
27-Mar-86 13:34:36-PST,437;000000000000
Mail-From: KLH created at 27-Mar-86 13:33:59
Date: Thu 27 Mar 86 13:33:59-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: Another C problem
To: [email protected], [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
It isn't required, although everyone will agree it would be nice. See
H&S 7.2.3 and 2.7.1.
-------
31-Mar-86 17:14:20-PST,471;000000000000
Mail-From: HSS created at 31-Mar-86 17:14:15
Date: Mon 31 Mar 86 17:14:13-PST
From: Harry Sameshima <[email protected]>
Subject: Yet another C bug
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
The following program leaves me in I/O wait....
#include <stdio.h>
#include <strings.h>
main()
{
char foo[30];
char bar[30];
strcpy(foo,"SRI-NIC/XYZZY");
sscanf(foo,"%s",bar);
printf("%s\n",bar);
}
-------
31-Mar-86 21:03:54-PST,574;000000000000
Mail-From: KLH created at 31-Mar-86 21:03:48
Date: Mon 31 Mar 86 21:03:48-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: Yet another C bug
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Just another bug in the old SCANF. All of the STDIO routines have
been completely re-written, but not yet installed; Ian is still
working on the lower-level calls and testing stuff. I'd rather not
try to fix things we have already thrown away.
-------
8-Apr-86 12:44:24-PST,699;000000000000
Mail-From: SKAHN created at 8-Apr-86 12:44:20
Date: Tue 8 Apr 86 12:44:20-PST
From: Susan Kahn <[email protected]>
Subject: Problem with arguments to C program
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Ian,
I am finding that the last character in a three-letter argument to a
C program is not getting transmitted. E.G.
<nicprog>makez com
does not work because the 'm' is not getting transmitted correctly, but
<nicprog>makez arpa
does work.
If I go back to an old version of MAKEZ.EXE it works fine, but if I
recreate the MAKEZ.EXE using old source programs, it does not work.
So I suspect the C compiler.
Susan
-------
8-Apr-86 12:50:48-PST,436;000000000000
Mail-From: SKAHN created at 8-Apr-86 12:50:18
Date: Tue 8 Apr 86 12:50:17-PST
From: Susan Kahn <[email protected]>
Subject: More on the problem with arguments to C program
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
If I add a blank after the argument, the program works fine.
E.g. "<nicprog>makez com <CR>" works fine, but "<nicprog>makez com<CR>" do not.
Susan
-------
8-Apr-86 13:07:51-PST,506;000000000000
Mail-From: HSS created at 8-Apr-86 13:07:48
Date: Tue 8 Apr 86 13:07:47-PST
From: Harry Sameshima <[email protected]>
Subject: Re: More on the problem with arguments to C program
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
The problem turned out to be the new clib.rel. I renamed it and now makez
works fine. The new clib contained the new malloc, etc. code.
Harry
-------
8-Apr-86 13:14:32-PST,553;000000000000
Mail-From: IAN created at 8-Apr-86 13:14:27
Date: Tue, 8 Apr 1986 13:14 PST
Message-ID: <IAN.12197268037.BABYL@SRI-NIC>
From: Ian Macky <Ian@SRI-NIC>
To: Harry Sameshima <[email protected]>
Cc: [email protected], [email protected]
Subject: More on the problem with arguments to C program
In-reply-to: Msg of 8 Apr 1986 13:07-PST from Harry Sameshima <HSS at SRI-NIC.ARPA>
the new clib replaced ONLY the MALLOC module; the JCL parsing and
argv/argc stuff are in the URT module, which i left alone. harry,
where'd you rename it to?
8-Apr-86 13:15:43-PST,366;000000000000
Mail-From: HSS created at 8-Apr-86 13:15:41
Date: Tue 8 Apr 86 13:15:40-PST
From: Harry Sameshima <[email protected]>
Subject: Re: More on the problem with arguments to C program
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <IAN.12197268037.BABYL@SRI-NIC>
Message-ID: <[email protected]>
c:new-clib.
-------
10-Apr-86 15:16:35-PST,310;000000000000
Mail-From: HSS created at 10-Apr-86 15:16:30
Date: Thu 10 Apr 86 15:16:28-PST
From: Harry Sameshima <[email protected]>
Subject: qsort bug
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Qsort does not work when extended addressing is used.
Harry
-------
10-Apr-86 16:29:03-PST,375;000000000000
Mail-From: KLH created at 10-Apr-86 16:28:59
Date: Thu 10 Apr 86 16:28:59-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: qsort bug
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
It does. Make sure your arguments to qsort are (char *).
-------
10-Apr-86 16:42:26-PST,1806;000000000000
Mail-From: HSS created at 10-Apr-86 16:42:20
Date: Thu 10 Apr 86 16:42:19-PST
From: Harry Sameshima <[email protected]>
Subject: Re: qsort bug
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
What am I overlooking?
#include <stdio.h>
struct foo {
int address;
};
main()
{
int i; /* Index variable */
int compare(); /* Qsort comparison function declaration */
struct foo *array; /* Pointer to array */
/* Make sure we have room for the array */
if ((array=(struct foo *) malloc(sizeof(struct foo)*8))==NULL) {
printf("?Not enough space for the array\n");
exit(1);
}
/* Initialize the array */
array[0].address=50;
array[1].address=13;
array[2].address=7;
array[3].address=1233;
array[4].address=123;
array[5].address=124;
array[6].address=1;
array[7].address=9;
printf("Usorted numbers: ");
for (i=0;i<8;++i)
printf("%d ",array[i].address);
printf("\n");
/* Sort the array */
qsort((char *)array,8,sizeof(struct foo),compare);
/* Print the sorted numbers */
printf("\nSorted numbers: ");
for (i=0;i<8;++i)
printf("%d ",array[i].address);
printf("\n");
}
compare(node1,node2)
char *node1,*node2;
{
return((((struct foo *) node1)->address) - (((struct foo *)
node2)->address));
}
[PHOTO: Recording initiated Thu 10-Apr-86 4:33pm]
End of PS:<HSS>COMAND.CMD.7
!dsk:sort.exe
Usorted numbers: 50 13 7 1233 123 124 1 9
Sorted numbers: 1 7 9 13 50 123 124 1233
!dd
DDT
$exadf/ 0 1
^Z
!cs
SORT.EXE.2 Saved
!dsk:sort.exe
Usorted numbers: 50 13 7 1233 123 124 1 9
Sorted numbers: 50 13 7 1233 123 124 1 9
!pop
[PHOTO: Recording terminated Thu 10-Apr-86 4:34pm]
Harry
-------
10-Apr-86 16:44:36-PST,556;000000000000
Mail-From: KLH created at 10-Apr-86 16:44:28
Date: Thu 10 Apr 86 16:44:28-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: qsort bug
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
You forgot to declare malloc as returning (char *). So what you think
is a structure pointer really isn't, because KCC didn't think any conversion
was necessary. So the attempt to convert a structure pointer back into
(char *) fails.
-------
10-Apr-86 16:49:05-PST,336;000000000000
Mail-From: HSS created at 10-Apr-86 16:48:57
Date: Thu 10 Apr 86 16:48:55-PST
From: Harry Sameshima <[email protected]>
Subject: Re: qsort bug
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Sigh. You are quite right.
Harry
-------
10-Apr-86 17:13:12-PST,332;000000000000
Mail-From: IAN created at 10-Apr-86 17:13:10
Date: Thu 10 Apr 86 17:13:10-PST
From: Ian Macky <[email protected]>
Subject: JSYS constants
To: [email protected]
Message-ID: <[email protected]>
i started a C:JSYS.H file to keep jsys #s and flags and such in... i didn't
see one around anywhere else.
-------
14-Apr-86 15:30:51-PST,627;000000000000
Mail-From: IAN created at 14-Apr-86 15:30:45
Date: Mon 14 Apr 86 15:30:45-PST
From: Ian Macky <[email protected]>
Subject: I need sample C programs that do I/O...
To: [email protected]
Message-ID: <[email protected]>
...to test out the I/O code I am re-writing. Better yet, you can test out
known behavior with the new I/O stuff and see if it still works. You can
do this by redefining C: to look in SS:<C.LIB.STDIO> first, and then back
in C:, and then loading your program and running it (the runtime library
is automatically loaded along with your program, from C:CLIB.REL)...
--ian
-------
1-May-86 16:59:51-PDT,867;000000000000
Mail-From: KLH created at 1-May-86 16:59:27
Date: Thu 1 May 86 16:59:27-PDT
From: Ken Harrenstien <[email protected]>
Subject: NCC - new compiler
To: [email protected]
Message-ID: <[email protected]>
I have installed a new version of KCC; to invoke it, use "NCC" instead
of "CC". This doesn't introduce any new features, but does fix a number
of bugs. Try it out carefully; files compiled by CC and NCC will NOT
be identical, so it will be necessary to actually test out your software.
Those of you who grok assembler could also compare the .FAI files
produced by -S to see whether the changes amount to more than just different
registers being used.
While I don't know of any remaining bugs, I am sufficiently paranoid that
I will leave it as NCC until enough testing has been done to warrant "real"
installation as CC.
-------
5-May-86 11:14:45-PDT,773;000000000000
Mail-From: IAN created at 5-May-86 11:14:44
Date: Mon 5 May 86 11:14:44-PDT
From: Ian Macky <[email protected]>
Subject: C people, this means YOU - a brother in needs calls!
To: [email protected]
Message-ID: <[email protected]>
i need you to test out the new I/O package and runtime library. Try it
with old code you have lying around - relink and see if it still behaves
the same (or better!); you can even write little snippits to test out
specific things, if you are so inclined.
the runtime library is named CLIB.REL and lives normally in C:, so just
redefine C: to be SS:<C.LIB.STDIO>, C: and you will win.
bugs to me personally, i think.
--ian
ps don't expect MANY bugs. it's in prime condition. or is that primed?
-------
7-May-86 18:27:21-PDT,960;000000000000
Mail-From: HSS created at 7-May-86 18:27:17
Date: Wed 7 May 86 18:27:16-PDT
From: Harry Sameshima <[email protected]>
Subject: C oddity
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
When I use a JSYS to output to .priou, the output can become unsynchronized
with output produced by printf. For example, this program:
#include <stdio.h>
#define ODTIM 0220
main()
{
int i;
int ablock[5]; /* AC block */
for (i=0;i<3;++i) {
ablock[1]=0101; /* .priou */
ablock[2]=-1; /* Print current date */
ablock[3]=0;
jsys(ODTIM,ablock);
printf(" %d\n",i);
}
}
produces this output:
7-May-86 18:17:25 7-May-86 18:17:25 7-May-86 18:17:25 0
1
2
I don't think that it's a very important problem (I usually send ODTIM
output to a string), but I think it's interesting. I guess when I bypass
stdio, I take my life into my own hands....
Harry
-------
7-May-86 18:44:55-PDT,648;000000000000
Mail-From: KLH created at 7-May-86 18:44:52
Date: Wed 7 May 86 18:44:52-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: C oddity
To: [email protected], [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
That's right. The way to make sure a stream is emptied is to use
FFLUSH. However, in general you shouldn't mix the usages; either do
everything with JSYS calls on a JFN, or do everything with STDIO.
We should probably add a few extensions to STDIO in order to
deal with TOPS-20 features as the need comes up.
-------
15-May-86 14:55:51-PDT,468;000000000000
Mail-From: KLH created at 15-May-86 14:55:48
Date: Thu 15 May 86 14:55:47-PDT
From: Ken Harrenstien <[email protected]>
Subject: Another NCC
To: [email protected]
Message-ID: <[email protected]>
I have installed another version of NCC, which fixes a couple more
bugs that turned up (which exist in both the current CC and old NCC).
By next week this will become the standard CC, so better test things
now if you want to test at all.
-------
30-May-86 16:30:10-PDT,270;000000000000
Mail-From: SKAHN created at 30-May-86 16:30:07
Date: Fri 30 May 86 16:30:07-PDT
From: Susan Kahn <[email protected]>
Subject: missing C manual
To: [email protected]
Message-ID: <[email protected]>
Does anyone have my C manual?
Susan
-------
6-Jun-86 14:55:08-PDT,1329;000000000000
Mail-From: IAN created at 6-Jun-86 14:55:05
Date: Fri 6 Jun 86 14:55:05-PDT
From: Ian Macky <[email protected]>
Subject: IMPORTANT! New CLIB installation on MONDAY!!!
To: [email protected]
Message-ID: <[email protected]>
On Monday I am going to install the new CLIB. This includes totally new
STDIO, UIO, math and malloc code. Old .REL files will be IMCOMPATIBLE
and must be recompiled! Saved .EXE files will still work.
The new code fixes endless bugs in the old code, and is guaranteed to
be CROCK-FREE, yes, you heard it, gross-disgusting-kludge-free!! Plus
it also works, and it prettier.
In the event of REALLY bad karma (e.g. problems that necessitate backing
off to the previous code), the critical components of the new system
are:
C:CLIB.REL the runtime library itself
C:STDIO.H STDIO header file
if the latest versions of these files are nuked, we will be back to the
old stuff. but don't do this unless i'm not around and it's the last
resort!!
we, the management, feel you will be more than satisfied with the
quality and comfort of this newest C runtime system. we have spared
no expense in bringing you the finest in coding technique, modesty/
immortality reconstruction simulata, and silly catch-phrases.
--the mgt
PS Remember, MONDAY!!
-------
13-Jun-86 17:49:47-PDT,786;000000000000
Mail-From: KLH created at 13-Jun-86 17:49:46
Date: Fri 13 Jun 86 17:49:45-PDT
From: Ken Harrenstien <[email protected]>
Subject: New CC
To: [email protected]
Message-ID: <[email protected]>
I have installed a new version of the compiler as CC. There is no
longer a NCC.
The major difference in this version is that the right-shift operator >>
is now implemented using arithmetic shift (ASH) instead of logical shift
(LSH). This causes sign-bit duplication, as opposed to logical shifting
which always shifts in zero bits. "unsigned" operands will still be
shifted logically, however. It is STRONGLY RECOMMENDED for portability
reasons that << and >> only be applied to unsigned operands, since the
outcome is only guaranteed for that case.
-------
14-Jun-86 09:47:22-PDT,354;000000000000
Mail-From: IAN created at 14-Jun-86 09:47:20
Date: Sat 14 Jun 86 09:47:20-PDT
From: Ian Macky <[email protected]>
Subject: better late that never; new CLIB installed
To: [email protected]
Message-ID: <[email protected]>
OK, the new clib and associated files have been installed, as per my
old message. Give them a shot!
-------
16-Jun-86 13:33:26-PDT,911;000000000000
Mail-From: HSS created at 16-Jun-86 13:33:19
Date: Mon 16 Jun 86 13:33:17-PDT
From: Harry Sameshima <[email protected]>
Subject: C bug
To: [email protected], [email protected]
cc: [email protected], [email protected]
Message-ID: <[email protected]>
Susan noticed that the strupper routine (from <nicprog>nicsup.c) doesn't
work anymore. The following program runs correctly on Blackjack and passes
lint. The Blackjack version prints out "THIS IS A TEST STRING". The Nic
compiler version prints out "This".
Harry
#include <stdio.h>
#include <ctype.h>
main()
{
char *strupper();
printf("%s\n",strupper("This is a test string"));
}
char *
strupper(str)
register char *str;
{
register int c;
register char *start; /* Begining of string */
start=str;
while(c = *str)
if(islower(c)) *str++ = toupper(c);
else ++str;
return(start);
}
-------
16-Jun-86 13:50:37-PDT,526;000000000000
Mail-From: KLH created at 16-Jun-86 13:50:31
Date: Mon 16 Jun 86 13:50:31-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: C bug
To: [email protected], [email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
The problem was that Ian forgot to copy the new CTYPE.H file over to C:
(some of the bits and macros are different). Your test case now works
OK... thanks for spotting it.
-------
16-Jun-86 14:27:45-PDT,1158;000000000000
Mail-From: HSS created at 16-Jun-86 14:27:28
Date: Mon 16 Jun 86 14:27:26-PDT
From: Harry Sameshima <[email protected]>
Subject: printf
To: [email protected], [email protected]
cc: [email protected], [email protected]
Message-ID: <[email protected]>
The following code produces two lines of upper case output, which is
not what I'd expect. The Sun and Vax compilers produce programs that
do the same thing. Why should that be?
#include <stdio.h>
#include <ctype.h>
#include <string.h>
main()
{
char teststr[50];
char *strupper();
char *strlower();
strcpy(teststr,"This is a test string");
printf("%s\n%s\n",strupper(teststr),strlower(teststr));
}
char *
strupper(str)
register char *str;
{
register int c;
register char *start; /* Begining of string */
start=str;
while(c = *str)
if(islower(c)) *str++ = toupper(c);
else ++str;
return(start);
}
char *
strlower(str)
register char *str;
{
register int c;
register char *start; /* Begining of string */
start=str;
while(c = *str)
if(isupper(c)) *str++ = tolower(c);
else ++str;
return(start);
}
-------
16-Jun-86 14:42:36-PDT,518;000000000000
Mail-From: KLH created at 16-Jun-86 14:42:27
Date: Mon 16 Jun 86 14:42:27-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: printf
To: [email protected], [email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
You are modifying the string in place. Function arguments can't be
strings, they are pointers to strings. In general it is a bad idea to
modify string constants.
-------
16-Jun-86 15:03:55-PDT,706;000000000000
Mail-From: HSS created at 16-Jun-86 15:03:49
Date: Mon 16 Jun 86 15:03:47-PDT
From: Harry Sameshima <[email protected]>
Subject: argc and argv
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
The following is a program that writes out argc and the contents of argv.
Setting $EXADF to 1 (to use extended addressing) breaks it. Typing ^T
tells me that the program is at FOO Fork wait at 1,,411667 or something
like that.
Harry
#include <stdio.h>
main(argc,argv)
int argc;
char *argv[];
{
int i;
printf("argc: %d\n",argc);
printf("argv: ");
for (i=0;i<argc;++i)
printf("%s ",argv[i]);
printf("\n");
}
-------
18-Jun-86 11:58:08-PDT,505;000000000000
Mail-From: KLH created at 18-Jun-86 11:58:02
Date: Wed 18 Jun 86 11:58:02-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: argc and argv
To: [email protected], [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Ian has fixed this problem (it was due to an old bug in the runtime cleanup
code which rarely got tickled). This was the last known outstanding problem;
any more?
-------
18-Jun-86 18:19:50-PDT,723;000000000000
Mail-From: HSS created at 18-Jun-86 18:19:45
Date: Wed 18 Jun 86 18:19:44-PDT
From: Harry Sameshima <[email protected]>
Subject: fopen problem
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Well, the following program is supposed to create a new file, or append
to an existing one, for writing. I get a new test.txt every time, even when
an old version exists.
Harry
#include <stdio.h>
main()
{
FILE *fp; /* File pointer */
if ((fp=fopen("test.txt","a"))==NULL) {
printf("?Can't open test.txt\n");
exit(1);
}
fprintf(fp,"This is a test string\n");
fclose(fp);
}
-------
19-Jun-86 12:00:16-PDT,390;000000000000
Mail-From: IAN created at 19-Jun-86 12:00:09
Date: Thu 19 Jun 86 12:00:09-PDT
From: Ian Macky <[email protected]>
Subject: Re: fopen problem
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
i fixed this - append wasn't looking for an existing file, you were right.
-------
19-Jun-86 17:49:38-PDT,415;000000000000
Mail-From: HSS created at 19-Jun-86 17:49:35
Date: Thu 19 Jun 86 17:49:35-PDT
From: Harry Sameshima <[email protected]>
Subject: Malloc nitpick
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
If I ask malloc for a block with a size of zero, I should get a pointer to
a block rather than a NULL, right? Or am I confused again?
Harry
-------
19-Jun-86 17:53:28-PDT,519;000000000000
Mail-From: KLH created at 19-Jun-86 17:53:25
Date: Thu 19 Jun 86 17:53:25-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: Malloc nitpick
To: [email protected], [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I think it's reasonable to get a NULL return value. What on earth would
you do with a pointer to a non-existent block? NULL is a pointer to nothing,
so it qualifies, I think.
-------
19-Jun-86 18:07:59-PDT,672;000000000000
Mail-From: HSS created at 19-Jun-86 18:07:53
Date: Thu 19 Jun 86 18:07:52-PDT
From: Harry Sameshima <[email protected]>
Subject: Re: Malloc nitpick
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I made a for loop (set from 1 to 50000) and asked malloc for blocks of
size i%100, where i was the loop variable. I did it just for fun. I
was curious why the program kept bombing. I just checked it out on the
Sun and Vax and found that they return a pointer....but I have to admit
that it's a gross and degenerate use of malloc....
Harry
-------
24-Jun-86 17:53:35-PDT,606;000000000000
Mail-From: HSS created at 24-Jun-86 17:53:33
Date: Tue 24 Jun 86 17:53:31-PDT
From: Harry Sameshima <[email protected]>
Subject: C bug
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
The funny thing about the following program is that if I replace the
"bar=bar/FOO" with "bar/=FOO", the program produces the correct result,
2.000000. As things stand, it tells me that the result is 3.906250.
Harry
#include <stdio.h>
#define FOO 1000.0
main()
{
float bar;
bar=2000.0;
bar=bar/FOO;
printf("%f\n",bar);
}
-------
25-Jun-86 13:34:43-PDT,364;000000000000
Mail-From: KLH created at 25-Jun-86 13:34:41
Date: Wed 25 Jun 86 13:34:41-PDT
From: Ken Harrenstien <[email protected]>
Subject: C bug fixed
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
This one turned out to be another over-eager optimization (tried to use
FSC instead of FDVR). Fixed now, thanks.
-------
28-Jun-86 10:09:25-PDT,1201;000000000000
Mail-From: STEVE created at 24-Jun-86 06:19:51
Date: 24 Jun 1986 0619:51-PDT
From: STEVE at SRI-NIC.ARPA
Subject: File(s) not accessed since 1-Mar-86
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
C-ENV.H.3 2 29-Nov-85
C-ENV.H.4 2 29-Nov-85
C-ENV.H.5 2 29-Nov-85
C-ENV.H.6 2 29-Nov-85
C-ENV.H.7 2 2-Dec-85
C-HDR.FAI.17 1 22-Nov-85
CC.DOC.20 7 16-Jan-86
CC.DOC.24 9 21-Jan-86
CC.DOC.32 11 28-Jan-86
CLIB.REL.18 25 9-Aug-85
CLIB.REL.120 27 10-Aug-85
CLIB.REL.200 26 18-Dec-85
CLIB.REL.201 26 18-Dec-85
CTYPE.H.2 1 21-Nov-85
ERRNO.H.1 1 21-Nov-85
ERRNO.H.2 2 16-Dec-85
SETJMP.H.1 1 21-Nov-85
SIGNAL.H.3 1 21-Nov-85
STDIO.H.3 1 21-Nov-85
URTIO.H.3 1 27-Feb-86
Total of 150 pages in 20 files.
1-Jul-86 17:58:36-PDT,519;000000000000
Mail-From: KLH created at 1-Jul-86 17:58:33
Date: Tue 1 Jul 86 17:58:33-PDT
From: Ken Harrenstien <[email protected]>
Subject: new KCC
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Installed new KCC which searches in C: if it fails to find "" includes
anywhere else. This appears to be more consistent with the slightly vague
specifications found in K&R, H&S, and the 4.2 BSD documentation.
#include <foo> still searches in C: alone.
-------
11-Jul-86 11:49:17-PDT,479;000000000000
Mail-From: IAN created at 11-Jul-86 11:49:13
Date: Fri 11 Jul 86 11:49:13-PDT
From: Ian Macky <[email protected]>
Subject: problem with sequential CC failing with a free() error...
To: [email protected]
Message-ID: <[email protected]>
...i fixed the problem. CC for some reason wanted to call free() with
a null pointer. it seemed harmless, so i made it a no-op in free();
so multiple CC's (like from a mic or cmd file) will work right again.
-------
22-Jul-86 15:44:46-PDT,640;000000000000
Mail-From: SKAHN created at 22-Jul-86 15:44:33
Date: Tue 22 Jul 86 15:44:33-PDT
From: Susan Kahn <[email protected]>
Subject: User Interface to C programs
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Ken,
I am beginning to feel uneasy about the user interfaces to the various C
programs being developed. I think most of us are using a UNIX type interface,
more-or-less, but we really haven't made any effort to be consistent from
program to program, as far as I can tell. How would you feel about the
C programmers getting together to talk about this issue?
Susan
-------
22-Jul-86 16:27:11-PDT,694;000000000000
Mail-From: IAN created at 22-Jul-86 16:27:10
Date: Tue 22 Jul 86 16:27:09-PDT
From: Ian Macky <[email protected]>
Subject: new clib
To: [email protected]
Message-ID: <[email protected]>
i just installed a new clib with various changed to stdio. more unix
calls are supported, and the most notable change is that linebuffering
now works for all output calls, putc() included, so printf's output to
stdio will appear after every newline character (as it should), so
fflush() is not needed to force it. it's been tested with a half a
dozen different programs, but if there's any problem, you know who to
tell, right? right. harry.
--ian
p.s. ha ha
-------
24-Jul-86 12:13:35-PDT,794;000000000000
Mail-From: STEVE created at 24-Jul-86 06:17:16
Date: 24 Jul 1986 0617:16-PDT
From: STEVE at SRI-NIC.ARPA
Subject: File(s) not accessed since 31-Mar-86
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
CTYPE.H.2 1 21-Nov-85
ERRNO.H.1 1 21-Nov-85
ERRNO.H.2 2 16-Dec-85
SETJMP.H.1 1 21-Nov-85
SIGNAL.H.3 1 21-Nov-85
STDIO.H.3 1 21-Nov-85
URTIO.H.3 1 27-Feb-86
Total of 8 pages in 7 files.
27-Jul-86 18:29:53-PDT,696;000000000000
Mail-From: KLH created at 27-Jul-86 18:29:52
Date: Sun 27 Jul 86 18:29:52-PDT
From: Ken Harrenstien <[email protected]>
Subject: New <ctype.h>
To: [email protected]
Message-ID: <[email protected]>
I have put up a new <ctype.h> file (and a new library) which finally
implements all the character processing facilities correctly.
Although existing .REL files can still be loaded without error, this is
only because the current library was carefully massaged to retain a copy
of the old character flag table. The next version of the library will
not have this, and you will start to see undefined symbol errors for .CTYPE
if you need to recompile something.
-------
31-Jul-86 14:56:19-PDT,543;000000000000
Mail-From: FRED created at 31-Jul-86 14:49:32
Date: Thu 31 Jul 86 14:49:32-PDT
From: Fred Ostapik <[email protected]>
Subject: Let's have a programmers' meeting
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Folks,
I know you've all been complaining about the lack of meetings. Let's remedy
the situation. I cordially invite you to the AI Conference Room, Tuesday,
Aug. 5, at 2:00. We'll talk about what we've been up to and stuff like that.
Fred
-------
6-Aug-86 14:38:30-PDT,498;000000000000
Mail-From: IAN created at 6-Aug-86 14:38:28
Date: Wed 6 Aug 86 14:38:28-PDT
From: Ian Macky <[email protected]>
Subject: new clib
To: [email protected]
Message-ID: <[email protected]>
i just installed a new clib which fixes various problems. glenn, append
mode does the right thing now. setbuf had some problems (reported by
frank wancho) which are also fixed. report any new (or old) incorrect
behavior to moi, plz. or to bug-kcc if you're sure it's a bug.
-------
7-Aug-86 10:40:09-PDT,1410;000000000000
Mail-From: SKAHN created at 7-Aug-86 10:40:06
Date: Thu 7 Aug 86 10:40:05-PDT
From: Susan Kahn <[email protected]>
Subject: User Interface to C programs
To: [email protected]
Message-ID: <[email protected]>
Ken and I have talked about the NIC's using a consistent syntax
for the user interface for all the C programs that we develop.
Here's what we came up with. I believe it conforms to one of the
standard UNIX ways of invoking a command.
program-name -sw1 value -sw2 value ... arg1 arg2 ....
where
sw1, sw2, ... are the optional switches
value is the value for the switch
arg1, arg2, ... are the arguments to the program
As you can see, the value for each optional switch follows the switch
name. There can be more than one value for a switch, depending upon
the program. Our convention for specifying switches or arguments will
be that the user can type the minimal number of letters so as to
disambiguate the switch or argument, but more than the minimum is
valid. Switches and arguments can be specified in any order on the
line. Programs should scan the entire command line and flag any
errors before processing begins.
The plan is for all us C programmers to meet to discuss this issue
when Ken gets back from vacation, but I thought I would send around
this message so people can think about it in advace.
Susan
-------
25-Aug-86 16:42:46-PDT,600;000000000000
Mail-From: KLH created at 25-Aug-86 16:42:44
Date: Mon 25 Aug 86 16:42:43-PDT
From: Ken Harrenstien <[email protected]>
Subject: ANSI C standard draft
To: [email protected]
Message-ID: <[email protected]>
I just got the latest (July '86) copy of the draft. I am going to
send it off to the copy center for a few extras, (for myself and Ian)
and put one in the library. Since it is so drafty, I am not sure it
will do much good to give everyone a copy (as we did for H&S) but
anyone who feels the need for one can just ask. (It's about 300
double-sided pages).
-------
5-Sep-86 12:26:13-PDT,343;000000000000
Mail-From: SKAHN created at 5-Sep-86 12:26:08
Date: Fri 5 Sep 86 12:26:08-PDT
From: Susan Kahn <[email protected]>
Subject: Hyphenation
To: [email protected]
Message-ID: <[email protected]>
Is there a routine anywhere that knows how to hyphenate words using
the standard dictionary-type algorithm?
Susan
-------
8-Sep-86 02:43:40-PDT,2374;000000000000
Mail-From: KLH created at 8-Sep-86 02:43:39
Date: Mon 8 Sep 86 02:43:39-PDT
From: Ken Harrenstien <[email protected]>
Subject: NCC installed - important!
To: [email protected]
Message-ID: <[email protected]>
I have installed a new version of the compiler as NCC. It uses a
different library from the old version, and the code it produces is
not compatible with that of the old compiler. What this means is that
if you want to use NCC you will have to delete all of your .REL files
and recompile.
It would be a good idea to do this soon, and verify that your things
still work, since on Tuesday or so I would like to make NCC become CC
(and CC will become OCC). Although the old compiler and library will
exist for some time, no new bug fixes will be made to either of them.
The new compiler has several improvements, but only one incompatible
change. Programs which use #asm will now have to use it differently.
The only program that I know of which uses this (other than the library
routines) is CTLO.C. Glenn, you can find a revised version of this
file in PS:<KLH>CTLO.C.
Harry, NCC fixes your division over-optimization bug. The resulting code
is slightly less optimal but I don't have the time to do better right now.
It is no longer necessary or possible to make a program run
extended-addressing by manually patching $EXADF. This decision is
now made at load time. You can request that the program be extended
in either of two ways:
(1) If CC is doing the loading, specify the -i switch.
(2) If you are using LINK (or the LOAD command), load the
file C:LIBCKX first, before any others.
You can now use CC as an interface to the loader; files with an
explicit .REL extension will simply be passed along to the loader
rather than compiled. The -l switch is now significant when loading,
and works as for UNIX. That is, -lfoo will attempt to load the library
C:LIBfoo.REL. The -o switch is also implemented as for UNIX; the next
argument is the desired .EXE filename.
An example:
CC -i -o foo myprog sup.rel -lifp
This compiles MYPROG.C, then loads the modules MYPROG.REL, SUP.REL, and
scans the library C:LIBIFP.REL (as well as C:LIBC.REL, which is always
implicitly searched), and writes the resulting binary image in FOO.EXE.
Let me know ASAP of any problems, thanks.
-------
10-Sep-86 15:16:41-PDT,291;000000000000
Mail-From: IAN created at 10-Sep-86 15:16:39
Date: Wed 10 Sep 86 15:16:38-PDT
From: Ian Macky <[email protected]>
Subject: due to a lack of problems, NCC has been renamed to CC.
To: [email protected]
Message-ID: <[email protected]>
there is no NCC currently.
-------
17-Sep-86 11:53:13-PDT,905;000000000000
Mail-From: IAN created at 17-Sep-86 11:53:10
Date: Wed 17 Sep 86 11:53:09-PDT
From: Ian Macky <[email protected]>
Subject: New CLIB to be installed (called LIBC in these modern times).
To: [email protected]
Message-ID: <[email protected]>
A new version of LIBC (formerly called CLIB) will be installed today
at noon, which is right now! This new version allows update
(read/write) mode, plus correctly closes all open files upen exit so
you don't have to manually, plus other internal changes.
The updated FILE blocks are larger than before, which means you have to
(once again, sorry folks) recompile all code that uses stdio. Which means
basically all of it, I suppose. Two extra spare words were added to the
FILE blocks so that next time we need to add a new functional word to
the block it can be done without the need for yet another recompile.
--ian
-------
17-Sep-86 14:09:45-PDT,434;000000000000
Mail-From: KLH created at 17-Sep-86 14:09:43
Date: Wed 17 Sep 86 14:09:43-PDT
From: Ken Harrenstien <[email protected]>
Subject: Recompile, yes, but not just yet...
To: [email protected]
Message-ID: <[email protected]>
There is an ill interaction between KCC and the new library so I've
rolled things back for the time being. There will be another warning
when the new version gets installed again.
-------
20-Sep-86 17:33:45-PDT,524;000000000001
Mail-From: IAN created at 20-Sep-86 17:33:43
Date: Sat 20 Sep 86 17:33:43-PDT
From: Ian Macky <[email protected]>
Subject: ...nk you for waiting. we are returning to our regularly scheduled
To: [email protected]
Message-ID: <[email protected]>
programming.
oops, ... oh! sorry! anyway, that new LIBC which will require you to
recompile your code is finally being installed. c:stdio.h and c:libc.rel
are the two relevant files.
harry, this lib fixes your gets() bug too.
--ian
-------
14-Nov-86 17:23:33-PST,297;000000000000
Mail-From: KLH created at 14-Nov-86 17:23:32
Date: Fri 14 Nov 86 17:23:32-PST
From: Ken Harrenstien <[email protected]>
Subject: New KCC
To: [email protected]
Message-ID: <[email protected]>
Installed a new KCC that fixes a few obscure (ie never seen before) bugs.
-------
24-Dec-86 14:42:19-PST,820;000000000000
Mail-From: FMC created at 24-Dec-86 13:21:35
Date: 24 Dec 1986 1321:35-PST
From: FMC at SRI-NIC.ARPA
Subject: File(s) not accessed since 31-Aug-86
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
C-ENV.H.8 2 14-Aug-86
CC.DOC.48 19 8-Aug-86
CC.DOC.51 20 8-Aug-86
ERRNO.H.4 2 14-Aug-86
ERRNO.H.5 2 14-Aug-86
ERRNO.H.6 2 14-Aug-86
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
Total of 51 pages in 8 files.
24-Jan-87 13:49:35-PST,375;000000000000
Mail-From: IAN created at 24-Jan-87 13:49:34
Date: Sat 24 Jan 87 13:49:34-PST
From: Ian Macky <[email protected]>
Subject: logical name for local nic sources, libraries, etc
To: [email protected]
Message-ID: <[email protected]>
instead of using "ps:<nicprog>" for where we get nic-local stuff, we
ought to use a logical name. i propose NIC:
-------
24-Jan-87 13:57:56-PST,376;000000000001
Mail-From: IAN created at 24-Jan-87 13:57:55
Date: Sat 24 Jan 87 13:57:55-PST
From: Ian Macky <[email protected]>
Subject: stat.h and types.h
To: [email protected]
Message-ID: <[email protected]>
it used to be that stat.h needed types.h, but didn't include it itself.
for no good reason. so stat.h now includes types.h, so you don't have to.
-------
24-Jan-87 14:21:45-PST,911;000000000000
Mail-From: KLH created at 24-Jan-87 14:21:41
Date: Sat 24 Jan 87 14:21:40-PST
From: Ken Harrenstien <[email protected]>
Subject: Re: logical name for local nic sources, libraries, etc
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
It's true that a less specific name is desirable. However, a logical name
is no more portable than the current syntax. What I suggest is that
for nic-specific .H files, we use #include <nic/xxx.h>. This corresponds
to the location C:<.NIC>xxx.H. Libraries (real ones, made with MAKLIB) would
simply go in C:LIBxxx.REL so that they can be loaded with the -lxxx switch.
A universal logical name for the nicprog stuff is a good idea in general,
though. I don't think others would agree to NIC:; personally I use N:!
NICPROG:, I guess. Sigh.
-------
24-Jan-87 15:10:01-PST,1446;000000000000
Mail-From: CURRY created at 24-Jan-87 14:29:16
Date: 24 Jan 1987 1429:16-PST
From: CURRY at SRI-NIC.ARPA
Subject: File(s) not accessed since 1-Oct-86
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
C-ENV.H.8 2 14-Aug-86
C-ENV.H.9 2 7-Sep-86
CC.DOC.48 19 8-Aug-86
CC.DOC.51 20 8-Aug-86
CC.DOC.52 20 10-Sep-86
CTYPE.H.8 2 25-Sep-86
ERRNO.H.4 2 14-Aug-86
ERRNO.H.5 2 14-Aug-86
ERRNO.H.6 2 14-Aug-86
JSYS.H.47 2 30-Sep-86
LIBC.REL.5 55 19-Sep-86
LIBC.REL.7 56 23-Sep-86
LIBC.REL.8 56 25-Sep-86
LIBC.REL.9 57 26-Sep-86
LIBC.REL.10 56 26-Sep-86
LIBC.REL.11 57 27-Sep-86
LIBC.REL.12 57 27-Sep-86
LIBC.REL.13 57 27-Sep-86
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
SYSITS.H.4 1 29-Sep-86
Total of 543 pages in 28 files.
26-Jan-87 13:50:53-PST,619;000000000000
Mail-From: IAN created at 26-Jan-87 13:50:50
Date: Mon 26 Jan 87 13:50:50-PST
From: Ian Macky <[email protected]>
Subject: Re: logical name for local nic sources, libraries, etc
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
<nic/xxx.h> for nic local stuff sounds good. shall i go ahead and
move ifpack.h and whatever else we use over there?
is everyone paying attention so you'll remember to update your code next
time you're in there? no more "ps:<nicprog>ifpack.h", it'll be
<nic/ifpack.h> instead.
-------
30-Jan-87 22:02:12-PST,623;000000000000
Mail-From: KLH created at 30-Jan-87 22:02:11
Date: Fri 30 Jan 87 22:02:10-PST
From: Ken Harrenstien <[email protected]>
Subject: New CC installed
To: [email protected]
Message-ID: <[email protected]>
I've installed a new CC with the following changes, none of which
are really user-visible:
(1) string constants are now 9-bit byte strings instead of 7-bit.
(2) initialization of static data is now done almost entirely
at load time rather than run time. This will save some space and time
for things like large arrays of string pointers.
(3) a couple more optimization bugs fixed.
-------
24-Feb-87 22:47:21-PST,1142;000000000000
Mail-From: FMC created at 24-Feb-87 14:05:52
Date: 24 Feb 1987 1405:52-PST
From: FMC at SRI-NIC.ARPA
Subject: File(s) not accessed since 1-Nov-86
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
LIBC.REL.9 57 26-Sep-86
LIBC.REL.10 56 26-Sep-86
LIBC.REL.11 57 27-Sep-86
LIBC.REL.12 57 27-Sep-86
LIBC.REL.13 57 27-Sep-86
LIBC.REL.14 57 18-Oct-86
LIBC.REL.15 57 28-Oct-86
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
SYSITS.H.4 1 29-Sep-86
UIO.H.36 1 3-Oct-86
Total of 418 pages in 18 files.
25-Feb-87 21:01:14-PST,771;000000000000
Mail-From: IAN created at 25-Feb-87 21:01:08
Date: Wed 25 Feb 87 21:01:08-PST
From: Ian Macky <[email protected]>
Subject: Re: Labels
To: [email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I have grabbed all the CCMD sources off CU20B.COLUMBIA and started getting
them to work with KCC. It's a big hunky library that will need some work
to get going, but once done, I think we'll be real happy with it, and want
to use it in C programs as the general interface (when a non Unix-shell
type command interface isn't enough).
I'll let everyone know when it's ready for use.
--ian
ps CCMD is the COMND% simulation stuff
-------
26-Feb-87 14:34:26-PST,766;000000000000
Mail-From: IAN created at 26-Feb-87 14:34:08
Date: Thu 26 Feb 87 14:34:07-PST
From: Ian Macky <[email protected]>
Subject: New library
To: [email protected]
Message-ID: <[email protected]>
I just installed a new LIBC. The changes are:
tricky logical device following is done now, so that sys/foo.h
type filespecs will be found even if you have C: defined to be
a whole search path. NOTE that nic-specific headers (ifpack
etc) should be referred to as nic/foo.h, which equates to the
directory PS:<KCC.NIC>
there's a palloc() in case anyone wants to try it out. palloc(n)
allocates n pages of memory, returning the page# of the first
page. use pfree(n) to free the memory.
plus various bugfixes...
--ian
-------
3-Mar-87 19:52:16-PST,6513;000000000000
Mail-From: KLH created at 3-Mar-87 19:52:14
Date: Tue 3 Mar 87 19:52:14-PST
From: Ken Harrenstien <[email protected]>
Subject: New KCC available; test it out!
To: [email protected]
Message-ID: <[email protected]>
FINALLY, the new KCC is in shape for testing. I have installed it in
a directory identified by the system-wide logical name NEWC:, and I
would like all C programmers to use this by giving the command:
[@]DEFINE C: (as) NEWC:,C:
so that your job-wide definition of C: goes first to NEWC: and then to
the default C:. Then when you compile any code, use C:CC as the
program name instead of CC.
This is not as simple as it could be, but I could not think of
any other way that would not cause unpleasant surprises. The code
produced by this compiler is INCOMPATIBLE with that of the old
compiler. To enforce this, the linking loader will complain loudly if
you try to load incompatibly compiled modules.
On Friday, if no one has found problems, this new compiler and
library will become the default, and I will make them available to the
world by sending an announcement to INFO-KCC. I have tested them more
thoroughly than any other new version, so I don't expect trouble, but
one never knows.
There is a new CC.DOC in NEWC: for your perusal. A summary of
the changes is included here:
-------------------------------
03/03/87 KCC ???, LIBC ??: <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.
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.
malloc() no longer allocates pages 770-777 (non-extended) or
37770-37777 (extended), so that obsolete forms of DDT can be mapped therein.
-------
4-Mar-87 12:43:17-PST,451;000000000000
Mail-From: KLH created at 4-Mar-87 12:43:16
Date: Wed 4 Mar 87 12:43:15-PST
From: Ken Harrenstien <[email protected]>
Subject: QSORT
To: [email protected]
Message-ID: <[email protected]>
If you have any applications which use QSORT on large arrays I would be
interested in knowing whether they run faster with the new compiler.
Some code in there was significantly improved by the new pointer
arithmetic sequences.
-------
6-Mar-87 02:55:54-PST,412;000000000000
Mail-From: KLH created at 6-Mar-87 02:55:50
Date: Fri 6 Mar 87 02:55:50-PST
From: Ken Harrenstien <[email protected]>
Subject: New KCC installed
To: [email protected]
Message-ID: <[email protected]>
Time's up. The new KCC has been installed, and unless you already tried
compiling your stuff with NEWC:, you will start to get loading errors,
which means you should recompile.
-------
17-Mar-87 11:10:18-PST,576;000000000000
Mail-From: IAN created at 17-Mar-87 11:10:16
Date: Tue 17 Mar 87 11:10:16-PST
From: Ian Macky <[email protected]>
Subject: Re: [Ian Macky <[email protected]>: Re: logical name for local nic sources, libraries, etc]
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
this is a reminder that from now on you should be using nic/ in filespecs
to find nic-specific files like ifpack.h.
#include <nic/ifpack.h>
instead of
#include "ps:<nicprog>ifpack.h"
--ian
-------
24-Mar-87 15:00:33-PST,910;000000000000
Date: 24 Mar 1987 0922:03-PST
From: OPERATOR at SRI-NIC.ARPA
Subject: File(s) not accessed since 29-Nov-86
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
SYSITS.H.4 1 29-Sep-86
Total of 21 pages in 12 files.
21-Apr-87 16:19:38-PDT,298;000000000000
Mail-From: MIMI created at 21-Apr-87 16:19:37
Date: Tue 21 Apr 87 16:19:36-PDT
From: Mimi Recker <[email protected]>
Subject: NULL pointer
To: [email protected]
Message-ID: <[email protected]>
Why does KCC output "(null)" for a NULL char pointer? It looks silly.
-------
24-Apr-87 11:37:46-PDT,1133;000000000000
Date: 24 Apr 1987 1028:33-PDT
From: OPERATOR at SRI-NIC.ARPA
Subject: File(s) not accessed since 30-Dec-86
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
LIBC.REL.94 59 7-Dec-86
LIBC.REL.95 59 18-Dec-86
LIBC.REL.96 59 18-Dec-86
LIBC.REL.97 59 19-Dec-86
LIBC.REL.98 59 24-Dec-86
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
SYSITS.H.4 1 29-Sep-86
Total of 318 pages in 19 files.
29-Apr-87 17:52:37-PDT,845;000000000001
Mail-From: KLH created at 29-Apr-87 17:52:06
Date: Wed 29 Apr 87 17:52:06-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: NULL pointer
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
The reason why printf outputs "(null)" when 0 is given to a %s specification
is because that is what BSD does, and besides, can you think of anything
more reasonable to do? On the SUN, trying to access location 0 kills the
program with an illegal address reference violation (or whatever they call
it). When you see (null) appear in the output, that is YOUR BUG and you
should be grateful for the notification. Don't ever feed null pointers
to routines that are not explicitly documented to handle such arguments.
-------
13-May-87 11:41:35-PDT,319;000000000000
Mail-From: MIMI created at 13-May-87 11:41:26
Date: Wed 13 May 87 11:41:25-PDT
From: Mimi Recker <[email protected]>
Subject: CARM
To: [email protected]
Location: SRI International, Phone: (415) 859-2110
Message-ID: <[email protected]>
did someone borrow my CARM? Help, I NEED it!!!
-------
18-May-87 16:49:56-PDT,1536;000000000000
Mail-From: MIMI created at 18-May-87 16:49:54
Date: Mon 18 May 87 16:49:53-PDT
From: Mimi Recker <[email protected]>
Subject: New NIC C Library
To: [email protected]
Location: SRI International, Phone: (415) 859-2110
Message-ID: <[email protected]>
The NIC C library is finally ready for your consumption. Documentation
of each module can be found is LIBNIC:*.doc.
-----------------------------------------------------------------------------
[PS:<NICPROG.LIBNIC>LIB.MAP]
Map of NIC C library support packages containing frequently used routines
(LIBNIC: is defined here as PS:<NICPROG.NIC>).
TO USE:
Definition:
Include desired header files in C progs as "#include <nic/libxxx.h>"
Existing header files (declaring routines and preep values):
PS:<KCC.NIC>LIBIFP.H -- Routines reading/writing IFPACK databases
LIBIDB.H -- Routines reading/writing DB-ID: database.
This includes above library (<nic/libifp.h>)
and <nic/iditem.h>.
LIBGEN.H -- General (mostly string) support routines
To load:
Include library at load time:
LIBNIC:LIBNIC.REL
NOTE: LIBIFP and LIBIDB use CIFP (the C interface package to IFPACK
databases) so NICPROG:CIFP must also be loaded. The
modules themselves define "<nic/ifpack.h>".
SOURCE CODE: (Currently 3 modules: LIBGEN,LIBIDB,LIBIFP)
LIBNIC:LIBxxx.C -- source code
LIBNIC:LIBxxx.doc -- Documentation and routine description
LIBNIC:LIBxxx.rel -- .rel file
-------
19-May-87 13:35:46-PDT,586;000000000000
Mail-From: MIMI created at 19-May-87 13:35:38
Date: Tue 19 May 87 13:35:38-PDT
From: Mimi Recker <[email protected]>
Subject: Re: New NIC C Library
To: [email protected]
In-Reply-To: <[email protected]>
Location: SRI International, Phone: (415) 859-2110
Message-ID: <[email protected]>
Per Klh's request, I have included CIFP in the NIC C library (don't
have to load it) and moved it (LIBNIC.REL) to C:.
It would be very uplifting to Mimi's ego if people sent me bug
reports. That way I will know that it is actually being used.
-------
24-May-87 18:25:17-PDT,1133;000000000000
Date: 24 May 1987 1723:18-PDT
From: OPERATOR at SRI-NIC.ARPA
Subject: File(s) not accessed since 30-Jan-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
LIBC.REL.94 59 7-Dec-86
LIBC.REL.95 59 18-Dec-86
LIBC.REL.96 59 18-Dec-86
LIBC.REL.97 59 19-Dec-86
LIBC.REL.98 59 24-Dec-86
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
SYSITS.H.4 1 29-Sep-86
Total of 318 pages in 19 files.
28-May-87 16:56:24-PDT,600;000000000001
Mail-From: MIMI created at 28-May-87 16:56:20
Date: Thu 28 May 87 16:56:19-PDT
From: Mimi Recker <[email protected]>
Subject: Re: NULL pointer
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Location: SRI International, Phone: (415) 859-2110
Message-ID: <[email protected]>
i just tested outputting a NULL pointer via printf on blackjack (a
4.3 site) and it displays nothing, e.g.
printf("string = |%s|\n", NULL);
shows
string = ||
which seems to me the right thing to do, rather than "(null)"...
--ian
-------
28-May-87 17:42:58-PDT,600;000000000001
Mail-From: KLH created at 28-May-87 17:42:55
Date: Thu 28 May 87 17:42:55-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: NULL pointer
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Sorry. It should stay "(null)". Would you rather it said something like
"foobar: illegal address reference at 0x244120 - core dumped"?
That more or less is what happens on a 68000 machine. If it just printed
nothing you would have no indication that anything was wrong.
-------
28-May-87 17:46:40-PDT,944;000000000001
Mail-From: KLH created at 28-May-87 17:46:36
Date: Thu 28 May 87 17:46:36-PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: NULL pointer
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
On re-reading perhaps I was too cryptic. The point I was making is that
we should not encourage code to work that is known to be non-portable to
machines/systems that we know we will want to port our software to. Using
NULL as an argument to printf, or most other string routines, is known
to be a guaranteed way to crash your program on a SUN. If you don't
believe me, try it. Who knows, I might be wrong and they may have fixed
their library routines to check for address references of 0. But that
behavior is still undefined.
I would be willing to consider changing the string from "(null)" to "(NULL)".
-------
28-May-87 19:38:25-PDT,440;000000000001
Mail-From: IAN created at 28-May-87 19:38:22
Date: Thu 28 May 87 19:38:22-PDT
From: Ian Macky <[email protected]>
Subject: Re: NULL pointer
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
hmm, perhaps what i'm thinking of is a pointer to a null string (which
should of course display nothing) as opposed to an actual NULL pointer.
-------
1-Jun-87 22:48:05-PDT,979;000000000000
Mail-From: KLH created at 1-Jun-87 22:48:03
Date: Mon 1 Jun 87 22:48:03-PDT
From: Ken Harrenstien <[email protected]>
Subject: TERMCAP
To: [email protected]
Message-ID: <[email protected]>
I have cobbled together some code that purports to support the TERMCAP
functions. It isn't in shape for true release yet, but if anyone has
programs that they'd like to test it with, here is the current mechanism:
(0) You can either pre-declare the termcap functions yourself,
as per the UPM documentation, or include the file <trmcap.h>.
(1) the CC command line that loads your program must have the
switch "-ltrm" at the end.
This requests loading of C:LIBTRM.REL.
(2) If the translation of your TOPS-20 terminal type # into a
termcap terminal name is incorrect, you can define the
logical name "CENV-TERM:" to be whatever your termcap
terminal name should be.
I'd appreciate any news of successful tests or discovered bugs.
-------
1-Jun-87 22:54:34-PDT,603;000000000000
Mail-From: KLH created at 1-Jun-87 22:54:33
Date: Mon 1 Jun 87 22:54:33-PDT
From: Ken Harrenstien <[email protected]>
Subject: p.s. on termcap
To: [email protected]
Message-ID: <[email protected]>
Sigh, I just realized those instructions presuppose that some new
library functions are being used, which we haven't publicly installed
yet. It is still possible to use termcap, but you'll have to check
with me for additional temporary instructions. When the new library
is installed there will be another announcement and things will work
as previously advertised.
-------
24-Jun-87 11:40:44-PDT,1903;000000000000
Date: 24 Jun 1987 0910:04-PDT
From: OPERATOR at SRI-NIC.ARPA
Subject: File(s) not accessed since 1-Mar-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
C-ENV.H.8 2 11-Feb-87
C-ENV.H.9 2 11-Feb-87
C-ENV.H.13 3 22-Feb-87
C-ENV.H.14 3 26-Feb-87
C-ENV.H.15 3 26-Feb-87
CC.DOC.48 19 11-Feb-87
CC.DOC.51 20 11-Feb-87
CC.DOC.52 20 11-Feb-87
CTYPE.H.8 2 11-Feb-87
ERRNO.H.4 2 11-Feb-87
ERRNO.H.5 2 11-Feb-87
ERRNO.H.6 2 11-Feb-87
ERRNO.H.7 2 11-Feb-87
JSYS.H.48 2 11-Feb-87
JSYS.H.49 2 11-Feb-87
JSYS.H.50 2 11-Feb-87
JSYS.H.51 2 11-Feb-87
LIBC.REL.94 59 7-Dec-86
LIBC.REL.95 59 18-Dec-86
LIBC.REL.96 59 18-Dec-86
LIBC.REL.97 59 19-Dec-86
LIBC.REL.98 59 24-Dec-86
LIBC.REL.99 59 26-Feb-87
LIBC.REL.100 60 27-Feb-87
LIBC.REL.101 61 27-Feb-87
LIBC.REL.102 62 27-Feb-87
LIBCKX.REL.1 1 17-Feb-87
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDLIB.H.1 1 18-Feb-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
SYSITS.H.4 1 29-Sep-86
Total of 654 pages in 44 files.
26-Jul-87 18:39:45-PDT,1451;000000000000
Date: 24 Jul 1987 1751:56-PDT
From: [email protected]
Subject: File(s) not accessed since 1-Apr-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
LIBC.REL.96 59 18-Dec-86
LIBC.REL.97 59 19-Dec-86
LIBC.REL.98 59 24-Dec-86
LIBC.REL.99 59 26-Feb-87
LIBC.REL.100 60 27-Feb-87
LIBC.REL.101 61 27-Feb-87
LIBC.REL.102 62 27-Feb-87
LIBC.REL.103 61 6-Mar-87
LIBC.REL.123 58 6-Mar-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDLIB.H.1 1 18-Feb-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
Total of 567 pages in 29 files.
1-Aug-87 11:13:06-PDT,1678;000000000001
Mail-From: STEVE created at 1-Aug-87 10:36:55
Date: 1 Aug 1987 1036:55-PDT
From: [email protected]
Subject: File(s) not accessed since 8-Apr-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
LIBC.REL.96 59 18-Dec-86
LIBC.REL.97 59 19-Dec-86
LIBC.REL.98 59 24-Dec-86
LIBC.REL.99 59 26-Feb-87
LIBC.REL.100 60 27-Feb-87
LIBC.REL.101 61 27-Feb-87
LIBC.REL.102 62 27-Feb-87
LIBC.REL.103 61 6-Mar-87
LIBC.REL.123 58 6-Mar-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
MATH.H.3 1 7-Apr-87
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDLIB.H.1 1 18-Feb-87
STDLIB.H.2 1 8-Apr-87
STDLIB.H.5 2 7-Apr-87
STDLIB.H.6 2 7-Apr-87
STDLIB.H.7 2 8-Apr-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
TIME.H.6 1 2-Apr-87
Total of 576 pages in 35 files.
24-Aug-87 09:37:29-PDT,1664;000000000000
Date: 24 Aug 1987 0634:14-PDT
From: [email protected]
Subject: File(s) not accessed since 1-May-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
LIBC.REL.96 59 18-Dec-86
LIBC.REL.97 59 19-Dec-86
LIBC.REL.98 59 24-Dec-86
LIBC.REL.99 59 26-Feb-87
LIBC.REL.100 60 27-Feb-87
LIBC.REL.101 61 27-Feb-87
LIBC.REL.102 62 27-Feb-87
LIBC.REL.103 61 6-Mar-87
LIBC.REL.123 58 6-Mar-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
MATH.H.3 1 7-Apr-87
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDLIB.H.1 1 18-Feb-87
STDLIB.H.2 1 8-Apr-87
STDLIB.H.5 2 7-Apr-87
STDLIB.H.6 2 7-Apr-87
STDLIB.H.7 2 8-Apr-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
STRUNG.H.3 1 13-Apr-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
TIME.H.6 1 2-Apr-87
Total of 577 pages in 36 files.
11-Sep-87 01:03:24-PDT,832;000000000000
Mail-From: KLH created at 11-Sep-87 01:03:10
Date: Fri, 11 Sep 87 01:03:09 PDT
From: Ken Harrenstien <[email protected]>
Subject: New KCC and library installed
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Okay, this is it. As of now, the C compiler and library are both new
versions, incompatible with the old ones. When you build a program you'll
have to recompile all of your source modules, or you'll get LINK error
messages.
There are new doc files: CC.DOC, LIBC.DOC, and USYS.DOC.
This library should support ALL of the runtime library facilities described
in CARM V2. Not all of them have been thoroughly tested. If you try some
of the new routines and don't get quite the results you expected, let me
and Ian know ASAP.
-------
11-Sep-87 09:48:50-PDT,447;000000000011
Mail-From: SKAHN created at 11-Sep-87 09:48:12
Date: Fri, 11 Sep 87 09:48:11 PDT
From: Susan Kahn <[email protected]>
Subject: Re: New KCC and library installed
To: [email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I have re-compiled LIBGEN, LIBIFP, AND LIBIDP and made a new LIBNIC.REL.
Susan
-------
13-Sep-87 23:16:48-PDT,1613;000000000000
Mail-From: MIMI created at 13-Sep-87 23:16:34
Date: Sun, 13 Sep 87 23:16:34 PDT
From: Mimi Recker <[email protected]>
Subject: Re: New KCC and library installed
To: [email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Location: SRI International, Phone: (415) 859-2110
Message-ID: <[email protected]>
{Mail-From: SKAHN created at 11-Sep-87 09:48:12
Date: Fri, 11 Sep 87 09:48:11 PDT
From: Susan Kahn <[email protected]>
Subject: Re: New KCC and library installed
To: [email protected]
cc: [email protected], [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I have re-compiled LIBGEN, LIBIFP, AND LIBIDP and made a new LIBNIC.REL.
Susan
-------
Huh, are you sure? In fact, I thought I saw the new .rels on Sat
but they seem to be gone now (except for the one in C:).
Did someone delete 'em? for a reason?
[PHOTO: Recording initiated Sun 13-Sep-87 11:11pm]
[Synonym ON defined]
[Synonym OFF defined]
@v nicsup.rel.0
PS:<NICPROG>
NICSUP.REL.31;P777700 5 2289(36) 10-Sep-87 09:28:18 MIMI
Total of 5 pages in 1 file
@v ifpsup.rel.0
PS:<NICPROG>
IFPSUP.REL.22;P777700 4 2046(36) 14-Aug-87 14:24:24 HSS
Total of 4 pages in 1 file
@v c:libnic.rel.0
PS:<KCC>
LIBNIC.REL.7;P777752 46 23355(36) 11-Sep-87 09:42:20 SKAHN
Total of 46 pages in 1 file
@po
[PHOTO: Recording terminated Sun 13-Sep-87 11:12pm]
-------
17-Sep-87 16:13:48-PDT,404;000000000000
Mail-From: MIMI created at 17-Sep-87 16:13:45
Date: Thu, 17 Sep 87 16:13:44 PDT
From: Mimi Recker <[email protected]>
Subject: REGSRV
To: [email protected]
cc: [email protected]
Location: SRI International, Phone: (415) 859-2110
Message-ID: <[email protected]>
I recompiled REGSRV (new LIBC) and it seems to work fine now as a server.
Sources and binaries in <mimi>.
-------
24-Sep-87 09:32:23-PDT,1939;000000000000
Date: 24 Sep 1987 0757:16-PDT
From: [email protected]
Subject: File(s) not accessed since 1-Jun-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
LIBC.REL.96 59 18-Dec-86
LIBC.REL.97 59 19-Dec-86
LIBC.REL.98 59 24-Dec-86
LIBC.REL.99 59 26-Feb-87
LIBC.REL.100 60 27-Feb-87
LIBC.REL.101 61 27-Feb-87
LIBC.REL.102 62 27-Feb-87
LIBC.REL.103 61 6-Mar-87
LIBC.REL.123 58 6-Mar-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
MATH.H.3 1 7-Apr-87
MATH.H.4 1 18-May-87
SGTTY.H.1 1 22-May-87
SGTTY.H.2 1 23-May-87
SIGNAL.H.9 1 20-May-87
STDDEF.H.1 1 28-May-87
STDDEF.H.2 1 28-May-87
STDIO.H.9 2 14-Aug-86
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDIO.H.18 3 22-May-87
STDLIB.H.1 1 18-Feb-87
STDLIB.H.2 1 8-Apr-87
STDLIB.H.5 2 7-Apr-87
STDLIB.H.6 2 7-Apr-87
STDLIB.H.7 2 8-Apr-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRING.H.7 1 17-May-87
STRING.H.8 1 24-May-87
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
STRUNG.H.3 1 13-Apr-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
TIME.H.6 1 2-Apr-87
Total of 588 pages in 45 files.
24-Sep-87 13:13:43-PDT,702;000000000000
Mail-From: IAN created at 24-Sep-87 13:13:38
Date: Thu, 24 Sep 87 13:13:38 PDT
From: Ian Macky <[email protected]>
Subject: new libgen routine: getline()
To: [email protected]
Message-ID: <[email protected]>
i added a new routine to libgen, getline()
char *getline(s, size, prompt)
gets a line of text into buffer s (of size size) via RDTTY%. it types
out the prompt first, and gives the prompt to RDTTY, so ^R, ^U, etc
won't clobber it.
it returns NULL on error, else s. there is no ending newline in the
buffer, so a blank line returns s, but *s == '\0'
also, i removed the redundant atoi() routine, since there was already
one in LIBC.
--ian
-------
24-Sep-87 16:12:08-PDT,543;000000000000
Mail-From: IAN created at 24-Sep-87 16:12:07
Date: Thu, 24 Sep 87 16:12:07 PDT
From: Ian Macky <[email protected]>
Subject: COMND% jsys interface package
To: [email protected]
Message-ID: <[email protected]>
we have a working COMND% interface package now. it was decided to give up
on porting CCMD to T20, so we have a home-brew instead.
NICPROG:CCMD.DOC decribes it all.
with that and getline(), we should be in good shape for converting most of
the midas outside-user programs to C, eh wot?
--ian
-------
24-Sep-87 16:19:24-PDT,320;000000000000
Mail-From: IAN created at 24-Sep-87 16:19:21
Date: Thu, 24 Sep 87 16:19:21 PDT
From: Ian Macky <[email protected]>
Subject: Re: COMND% jsys interface package
To: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Make that NICPROG:COMND.DOC
-------
24-Sep-87 20:12:35-PDT,436;000000000000
Mail-From: IAN created at 24-Sep-87 20:12:34
Date: Thu, 24 Sep 87 20:12:34 PDT
From: Ian Macky <[email protected]>
Subject: lib[gen,idb,ifp]
To: [email protected]
Message-ID: <[email protected]>
is it necessary to have libnic broken down into three different header
files? the libraries are all kept together in libnic.rel, right? it
would be nice if there was a single libnic.h to go along with it.
-------
24-Sep-87 23:07:16-PDT,664;000000000000
Mail-From: MIMI created at 24-Sep-87 23:07:14
Date: Thu, 24 Sep 87 23:07:13 PDT
From: Mimi Recker <[email protected]>
Subject: Re: lib[gen,idb,ifp]
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Location: SRI International, Phone: (415) 859-2110
Message-ID: <[email protected]>
Well, conceivably you might just want to use the general routines
and not the DB stuff, or just the DB stuff and not the ID-DB:
stuff.
Isn't the compiler smart enough to just get what it needs as
determined by the .H files (otherwise, why have .h file at all
since we just have just one LIBC.REL).
-------
28-Sep-87 13:16:27-PDT,347;000000000000
Mail-From: IAN created at 28-Sep-87 13:16:22
Date: Mon, 28 Sep 87 13:16:22 PDT
From: Ian Macky <[email protected]>
Subject: libnic
To: [email protected]
Message-ID: <[email protected]>
since there were no objections, i am going to combine all three
lib[gen,idb,ifp] files into the single libnic.h in a day or two.
-------
28-Sep-87 13:32:43-PDT,447;000000000000
Mail-From: KLH created at 28-Sep-87 13:31:38
Date: Mon, 28 Sep 87 13:31:38 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: libnic
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I think Mimi's message qualifies as an objection, and I agree with her.
In fact more separation rather than less may be desirable.
-------
24-Oct-87 14:23:57-PDT,2165;000000000000
Date: 24 Oct 1987 1355:25-PDT
From: [email protected]
Subject: File(s) not accessed since 1-Jul-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
LIBC.REL.96 59 18-Dec-86
LIBC.REL.97 59 19-Dec-86
LIBC.REL.98 59 24-Dec-86
LIBC.REL.99 59 26-Feb-87
LIBC.REL.100 60 27-Feb-87
LIBC.REL.101 61 27-Feb-87
LIBC.REL.102 62 27-Feb-87
LIBC.REL.103 61 6-Mar-87
LIBC.REL.123 58 6-Mar-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
LIBNIC.REL.1 44 14-Jun-87
LIBTRM.REL.1 5 1-Jun-87
MATH.H.3 1 7-Apr-87
MATH.H.4 1 18-May-87
SGTTY.H.1 1 22-May-87
SGTTY.H.2 1 23-May-87
SIGNAL.H.9 1 20-May-87
SIGNAL.H.10 1 7-Jun-87
SIGNAL.H.11 2 7-Jun-87
SIGNAL.H.12 2 23-Jun-87
SIGNAL.H.13 2 28-Jun-87
STDDEF.H.1 1 28-May-87
STDDEF.H.2 1 28-May-87
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDIO.H.18 3 22-May-87
STDLIB.H.1 1 18-Feb-87
STDLIB.H.2 1 8-Apr-87
STDLIB.H.5 2 7-Apr-87
STDLIB.H.6 2 7-Apr-87
STDLIB.H.7 2 8-Apr-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRING.H.7 1 17-May-87
STRING.H.8 1 24-May-87
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
STRUNG.H.3 1 13-Apr-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
TIME.H.6 1 2-Apr-87
TRMCAP.H.1 1 1-Jun-87
TRMCAP.H.2 1 1-Jun-87
Total of 644 pages in 52 files.
30-Oct-87 10:49:30-PST,346;000000000000
Mail-From: MIMI created at 30-Oct-87 10:49:27
Date: Fri, 30 Oct 87 10:49:27 PST
From: Mimi Recker <[email protected]>
Subject: who done it?
To: [email protected]
Location: SRI International, Phone: (415) 859-2110
Message-ID: <[email protected]>
Who removed itoa() and reverse() from the NIC C library (libgen)?
-------
18-Nov-87 13:47:43-PST,2619;000000000000
Mail-From: KLH created at 18-Nov-87 13:47:40
Date: Wed, 18 Nov 87 13:47:40 PST
From: Ken Harrenstien <[email protected]>
Subject: [Steve Murphy <[email protected]>: the GNU debugger: GDB. My impressions]
To: [email protected]
Message-ID: <[email protected]>
Sounds like something we should get ahold of. I've NEVER seen a decent
UNIX debugger. If RMS has gotten around to writing one... (remember, this
is the same guy who hacked ITS DDT!)
---------------
Return-Path: <[email protected]>
Received: from BRL-SMOKE.ARPA by SRI-NIC.ARPA with TCP; Wed 18 Nov 87 13:12:13-PST
Received: from BRL-SMOKE.ARPA by SMOKE.BRL.ARPA id aa21235; 17 Nov 87 22:47 EST
Received: from brl-adm.arpa by SMOKE.BRL.ARPA id aa21171; 17 Nov 87 22:35 EST
Received: from USENET by ADM.BRL.ARPA id aa24482; 17 Nov 87 22:33 EST
From: Steve Murphy <[email protected]>
Newsgroups: comp.emacs,comp.lang.c
Subject: the GNU debugger: GDB. My impressions
Message-ID: <[email protected]>
Date: 15 Nov 87 07:25:05 GMT
Keywords: debuggers, C, dbx, GDB
To: [email protected]
I never really paid any attention to gdb. I just never really thought
to look it over. It comes with gnu emacs as a subdir, and is poorly advertised
by FSF. Without looking at it, I thought: eh, just a kludge most likely. Why
bother with it? The most said about in the install stuff is that you could
use it to debug gnu if the native debugger couldn't handle the size of
gnu emacs.
Well, desperate people do desperate things. Dbx as implemented by sun is neat,
but it gets lost, lies, crashes, and is a real pain at times. I was spending
so much time trying to get around dbx problems at one point that I sat back
and mused, there must be a better way. And gdb came to mind. I compiled it,
ran the on-line documentation, and dived back into debugging my program. None
of the weirdness that dbx exhibited. I found the bug quickly, with no crashes,
no aberrations, no problems. Then I TeX'd the manual and read it. WOW!
NICE! IMPRESSIVE! ELEGANT! NEAT!
Zoom thru linked lists. It'll search your PATH for the executable, if need
be. Only one thing it doesn't seem to be able to do that dbx can (at least on
Suns) --- attach to already running processes. But... there's a bunch of
nice features DBX doesn't have that GDB does.
Well, just thought I'd give something neat a plug.
Thanks for your attention.
--
Steve Murphy, CAECO, Inc., 7090 South Union Park Avenue,
Suite 200, Midvale, UT 84047
(801)255-8880
<WORLD>!{byuadam,utah-cs,nrc-ut,wicat}!caeco!murf
-------
26-Nov-87 12:55:09-PST,3008;000000000000
Mail-From: FMC created at 24-Nov-87 06:22:09
Date: 24 Nov 1987 0622:09-PST
From: [email protected]
Subject: File(s) not accessed since 1-Aug-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
C-ENV.H.8 2 17-Jul-87
C-ENV.H.9 2 17-Jul-87
C-ENV.H.12 2 17-Jul-87
C-ENV.H.13 3 17-Jul-87
C-ENV.H.14 3 17-Jul-87
C-ENV.H.15 3 17-Jul-87
C-ENV.H.16 3 17-Jul-87
CC.DOC.48 19 17-Jul-87
CC.DOC.51 20 17-Jul-87
CC.DOC.52 20 17-Jul-87
CC.DOC.76 26 17-Jul-87
CC.DOC.100 33 17-Jul-87
CTYPE.H.8 2 17-Jul-87
ERRNO.H.4 2 17-Jul-87
ERRNO.H.5 2 17-Jul-87
ERRNO.H.6 2 17-Jul-87
ERRNO.H.7 2 17-Jul-87
LIBC.REL.94 59 17-Jul-87
LIBC.REL.95 59 17-Jul-87
LIBC.REL.96 59 18-Dec-86
LIBC.REL.97 59 19-Dec-86
LIBC.REL.98 59 24-Dec-86
LIBC.REL.99 59 26-Feb-87
LIBC.REL.100 60 27-Feb-87
LIBC.REL.101 61 27-Feb-87
LIBC.REL.102 62 27-Feb-87
LIBC.REL.103 61 6-Mar-87
LIBC.REL.123 58 6-Mar-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
LIBTRM.REL.1 5 1-Jun-87
MATH.H.3 1 7-Apr-87
MATH.H.4 1 18-May-87
SETJMP.H.3 1 6-Jul-87
SGTTY.H.1 1 22-May-87
SGTTY.H.2 1 23-May-87
SIGNAL.H.9 1 20-May-87
SIGNAL.H.10 1 7-Jun-87
SIGNAL.H.11 2 7-Jun-87
SIGNAL.H.12 2 23-Jun-87
SIGNAL.H.13 2 28-Jun-87
SIGNAL.H.14 2 6-Jul-87
SIGNAL.H.15 2 8-Jul-87
SIGNAL.H.16 2 21-Jul-87
SIGNAL.H.17 2 21-Jul-87
SIGNAL.H.18 2 22-Jul-87
SIGNAL.H.19 2 22-Jul-87
SIGNAL.H.20 2 30-Jul-87
STDDEF.H.1 1 28-May-87
STDDEF.H.2 1 28-May-87
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDIO.H.18 3 22-May-87
STDLIB.H.1 1 18-Feb-87
STDLIB.H.2 1 8-Apr-87
STDLIB.H.5 2 7-Apr-87
STDLIB.H.6 2 7-Apr-87
STDLIB.H.7 2 8-Apr-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRING.H.7 1 17-May-87
STRING.H.8 1 24-May-87
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
STRUNG.H.3 1 13-Apr-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
TIME.H.6 1 2-Apr-87
TRMCAP.H.1 1 1-Jun-87
TRMCAP.H.2 1 1-Jun-87
Total of 879 pages in 78 files.
24-Dec-87 08:45:31-PST,3602;000000000000
Date: 24 Dec 1987 0750:03-PST
From: [email protected]
Subject: File(s) not accessed since 31-Aug-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
C-ENV.H.8 2 17-Jul-87
C-ENV.H.9 2 17-Jul-87
C-ENV.H.12 2 17-Jul-87
C-ENV.H.13 3 17-Jul-87
C-ENV.H.14 3 17-Jul-87
C-ENV.H.15 3 17-Jul-87
C-ENV.H.16 3 17-Jul-87
CC.DOC.48 19 17-Jul-87
CC.DOC.51 20 17-Jul-87
CC.DOC.52 20 17-Jul-87
CC.DOC.76 26 17-Jul-87
CC.DOC.100 33 17-Jul-87
CC.DOC.101 33 17-Aug-87
CTYPE.H.8 2 17-Jul-87
ERRNO.H.4 2 17-Jul-87
ERRNO.H.5 2 17-Jul-87
ERRNO.H.6 2 17-Jul-87
ERRNO.H.7 2 17-Jul-87
ERRNO.H.8 2 27-Aug-87
JSYS.H.81 4 10-Aug-87
JSYS.H.90 8 10-Aug-87
JSYS.H.91 8 13-Aug-87
JSYS.H.92 8 18-Aug-87
JSYS.H.93 8 24-Aug-87
JSYS.H.94 8 24-Aug-87
JSYS.H.95 8 25-Aug-87
JSYS.H.96 8 25-Aug-87
JSYS.H.97 9 30-Aug-87
LIBC.REL.103 61 6-Mar-87
LIBC.REL.123 58 6-Mar-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
LIBTRM.REL.1 5 1-Jun-87
MATH.H.3 1 7-Apr-87
MATH.H.4 1 18-May-87
NETDB.H.1 1 21-Aug-87
SETJMP.H.3 1 6-Jul-87
SETJMP.H.4 1 11-Aug-87
SETJMP.H.5 1 13-Aug-87
SETJMP.H.6 1 13-Aug-87
SGTTY.H.1 1 22-May-87
SGTTY.H.2 1 23-May-87
SGTTY.H.3 1 3-Aug-87
SGTTY.H.4 1 3-Aug-87
SIGNAL.H.9 1 20-May-87
SIGNAL.H.10 1 7-Jun-87
SIGNAL.H.11 2 7-Jun-87
SIGNAL.H.12 2 23-Jun-87
SIGNAL.H.13 2 28-Jun-87
SIGNAL.H.14 2 6-Jul-87
SIGNAL.H.15 2 8-Jul-87
SIGNAL.H.16 2 21-Jul-87
SIGNAL.H.17 2 21-Jul-87
SIGNAL.H.18 2 22-Jul-87
SIGNAL.H.19 2 22-Jul-87
SIGNAL.H.20 2 30-Jul-87
SIGNAL.H.21 2 4-Aug-87
SIGNAL.H.22 3 4-Aug-87
SIGNAL.H.23 3 9-Aug-87
SIGNAL.H.24 3 11-Aug-87
SIGNAL.H.25 3 13-Aug-87
SIGNAL.H.26 3 14-Aug-87
SIGNAL.H.27 3 14-Aug-87
SIGNAL.H.28 3 16-Aug-87
SIGNAL.H.29 3 18-Aug-87
STDDEF.H.1 1 28-May-87
STDDEF.H.2 1 28-May-87
STDDEF.H.3 1 27-Aug-87
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDIO.H.18 3 22-May-87
STDIO.H.19 3 17-Aug-87
STDLIB.H.1 1 18-Feb-87
STDLIB.H.2 1 8-Apr-87
STDLIB.H.5 2 7-Apr-87
STDLIB.H.6 2 7-Apr-87
STDLIB.H.7 2 8-Apr-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRING.H.7 1 17-May-87
STRING.H.8 1 24-May-87
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
STRUNG.H.3 1 13-Apr-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
TIME.H.6 1 2-Apr-87
TRMCAP.H.1 1 1-Jun-87
TRMCAP.H.2 1 1-Jun-87
URTSUD.H.5 1 18-Aug-87
URTSUD.H.6 1 18-Aug-87
Total of 484 pages in 99 files.
13-Jan-88 14:44:00-PST,571;000000000000
Mail-From: KLH created at 13-Jan-88 14:43:49
Date: Wed, 13 Jan 88 14:43:49 PST
From: Ken Harrenstien <[email protected]>
Subject: new KCC
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I installed a new version of KCC that fixes a couple bugs reported from
Utah. This also includes the fix for strange multi-dimensional char array
refs that was fixed a while ago but not installed (pending some mods to
the preprocessor, which I gave up on for the moment). Basically you
shouldn't notice any difference.
-------
24-Jan-88 14:43:18-PST,4611;000000000000
Date: 24 Jan 1988 1337:26-PST
From: [email protected]
Subject: File(s) not accessed since 1-Oct-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
C-ENV.H.8 2 17-Jul-87
C-ENV.H.9 2 17-Jul-87
C-ENV.H.12 2 17-Jul-87
C-ENV.H.13 3 17-Jul-87
C-ENV.H.14 3 17-Jul-87
C-ENV.H.15 3 17-Jul-87
C-ENV.H.16 3 17-Jul-87
CC.DOC.48 19 17-Jul-87
CC.DOC.51 20 17-Jul-87
CC.DOC.52 20 17-Jul-87
CC.DOC.76 26 17-Jul-87
CC.DOC.100 33 17-Jul-87
CC.DOC.101 33 17-Aug-87
CC.DOC.109 30 17-Sep-87
CTYPE.H.8 2 17-Jul-87
ERRNO.H.4 2 17-Jul-87
ERRNO.H.5 2 17-Jul-87
ERRNO.H.6 2 17-Jul-87
ERRNO.H.7 2 17-Jul-87
ERRNO.H.8 2 27-Aug-87
FCNTL.H.1 1 5-Sep-87
FCNTL.H.2 1 5-Sep-87
FRKXEC.H.1 1 31-Aug-87
FRKXEC.H.2 1 1-Sep-87
JSYS.H.81 4 10-Aug-87
JSYS.H.90 8 10-Aug-87
JSYS.H.91 8 13-Aug-87
JSYS.H.92 8 18-Aug-87
JSYS.H.93 8 24-Aug-87
JSYS.H.94 8 24-Aug-87
JSYS.H.95 8 25-Aug-87
JSYS.H.96 8 25-Aug-87
JSYS.H.97 9 30-Aug-87
JSYS.H.98 8 1-Sep-87
JSYS.H.99 8 2-Sep-87
JSYS.H.100 8 9-Sep-87
JSYS.H.101 8 21-Sep-87
JSYS.H.102 9 21-Sep-87
JSYS.H.103 9 24-Sep-87
JSYS.H.104 9 24-Sep-87
JSYS.H.105 9 24-Sep-87
JSYS.H.106 9 24-Sep-87
JSYS.H.107 9 25-Sep-87
LIBC.DOC.200 14 11-Sep-87
LIBC.DOC.201 14 17-Sep-87
LIBC.REL.103 61 6-Mar-87
LIBC.REL.123 58 6-Mar-87
LIBC.REL.124 58 10-Sep-87
LIBC.REL.200 84 11-Sep-87
LIBC.REL.201 84 13-Sep-87
LIBC.REL.202 84 14-Sep-87
LIBC.REL.203 84 15-Sep-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
LIBCKX.REL.3 1 15-Sep-87
LIBTRM.REL.1 5 1-Jun-87
MATH.H.3 1 7-Apr-87
MATH.H.4 1 18-May-87
NETDB.H.1 1 21-Aug-87
SETJMP.H.3 1 6-Jul-87
SETJMP.H.4 1 11-Aug-87
SETJMP.H.5 1 13-Aug-87
SETJMP.H.6 1 13-Aug-87
SGTTY.H.1 1 22-May-87
SGTTY.H.2 1 23-May-87
SGTTY.H.3 1 3-Aug-87
SGTTY.H.4 1 3-Aug-87
SIGNAL.H.9 1 20-May-87
SIGNAL.H.10 1 7-Jun-87
SIGNAL.H.11 2 7-Jun-87
SIGNAL.H.12 2 23-Jun-87
SIGNAL.H.13 2 28-Jun-87
SIGNAL.H.14 2 6-Jul-87
SIGNAL.H.15 2 8-Jul-87
SIGNAL.H.16 2 21-Jul-87
SIGNAL.H.17 2 21-Jul-87
SIGNAL.H.18 2 22-Jul-87
SIGNAL.H.19 2 22-Jul-87
SIGNAL.H.20 2 30-Jul-87
SIGNAL.H.21 2 4-Aug-87
SIGNAL.H.22 3 4-Aug-87
SIGNAL.H.23 3 9-Aug-87
SIGNAL.H.24 3 11-Aug-87
SIGNAL.H.25 3 13-Aug-87
SIGNAL.H.26 3 14-Aug-87
SIGNAL.H.27 3 14-Aug-87
SIGNAL.H.28 3 16-Aug-87
SIGNAL.H.29 3 18-Aug-87
STDDEF.H.1 1 28-May-87
STDDEF.H.2 1 28-May-87
STDDEF.H.3 1 27-Aug-87
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDIO.H.18 3 22-May-87
STDIO.H.19 3 17-Aug-87
STDIO.H.21 3 5-Sep-87
STDIO.H.22 3 5-Sep-87
STDIO.H.23 3 8-Sep-87
STDIO.H.24 3 10-Sep-87
STDIO.H.25 3 11-Sep-87
STDIO.H.26 3 11-Sep-87
STDLIB.H.1 1 18-Feb-87
STDLIB.H.2 1 8-Apr-87
STDLIB.H.5 2 7-Apr-87
STDLIB.H.6 2 7-Apr-87
STDLIB.H.7 2 8-Apr-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRING.H.7 1 17-May-87
STRING.H.8 1 24-May-87
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
STRUNG.H.3 1 13-Apr-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
TIME.H.6 1 2-Apr-87
TRMCAP.H.1 1 1-Jun-87
TRMCAP.H.2 1 1-Jun-87
URTSUD.H.5 1 18-Aug-87
URTSUD.H.6 1 18-Aug-87
USYS.DOC.29 6 11-Sep-87
USYS.DOC.30 7 12-Sep-87
USYS.DOC.31 7 11-Sep-87
Total of 1065 pages in 131 files.
3-Feb-88 20:33:09-PST,680;000000000000
Mail-From: IAN created at 3-Feb-88 20:33:05
Date: Wed, 3 Feb 88 20:33:04 PST
From: Ian Macky <[email protected]>
Subject: Re: cm_table_entry is changed
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
oh sorry, forgot to mention that.... after the key string now comes
the flag word, which for now should be 0 only.
for the rest of you seers, we're talking about cm_table_entry() in my
comnd package. it was just changed to take a new arg, now #2 in the
list, which is the table flags for that entry. this is placeholding,
it won't actually work yet.
--ian
-------
24-Feb-88 09:38:31-PST,1073;000000000000
Mail-From: IAN created at 24-Feb-88 09:37:04
Date: Wed, 24 Feb 88 09:37:01 PST
From: Ian Macky <[email protected]>
Subject: COMND package changes
To: [email protected]
Message-ID: <[email protected]>
Folks,
I've made another round of changes in the COMND package, which unfortunately
involves a minor change in the cm_table_begin/cm_table_end sequence. What
it gains, however, is the allowance of table flags, CM_INV, etc, which now
work.
The old sequence was:
cm_table_begin(name, iname)
table entries...
cm_table_end(name, iname)
where "name" is the name that is used in the cm_declare to associate a table
with a table-taking (e.g. keyword or switch) FDB.
The new sequence:
cm_table_begin(iname1)
table entries...
cm_table_end(name, iname1, iname2)
Yes, MORE gross manually-specified internal symbols are needed! For example:
cm_table_begin(_tt1)
cm_table_entry("foo", CM_INV, 0)
cm_table_end(top_tab, _tt1, _tt2)
and the table is referred to as "top_tab" in the cm_declare.
--ian
-------
25-Feb-88 00:18:10-PST,4769;000000000000
Date: 24 Feb 1988 1627:29-PST
From: [email protected]
Subject: File(s) not accessed since 2-Nov-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
C-ENV.H.8 2 17-Jul-87
C-ENV.H.9 2 17-Jul-87
C-ENV.H.12 2 17-Jul-87
C-ENV.H.13 3 17-Jul-87
C-ENV.H.14 3 17-Jul-87
C-ENV.H.15 3 17-Jul-87
C-ENV.H.16 3 17-Jul-87
CC.DOC.48 19 17-Jul-87
CC.DOC.51 20 17-Jul-87
CC.DOC.52 20 17-Jul-87
CC.DOC.76 26 17-Jul-87
CC.DOC.100 33 17-Jul-87
CC.DOC.101 33 17-Aug-87
CC.DOC.109 30 17-Sep-87
CTYPE.H.8 2 17-Jul-87
ERRNO.H.4 2 17-Jul-87
ERRNO.H.5 2 17-Jul-87
ERRNO.H.6 2 17-Jul-87
ERRNO.H.7 2 17-Jul-87
ERRNO.H.8 2 27-Aug-87
FCNTL.H.1 1 5-Sep-87
FCNTL.H.2 1 5-Sep-87
FRKXEC.H.1 1 31-Aug-87
FRKXEC.H.2 1 1-Sep-87
JSYS.H.81 4 10-Aug-87
JSYS.H.90 8 10-Aug-87
JSYS.H.91 8 13-Aug-87
JSYS.H.92 8 18-Aug-87
JSYS.H.93 8 24-Aug-87
JSYS.H.94 8 24-Aug-87
JSYS.H.95 8 25-Aug-87
JSYS.H.96 8 25-Aug-87
JSYS.H.97 9 30-Aug-87
JSYS.H.98 8 1-Sep-87
JSYS.H.99 8 2-Sep-87
JSYS.H.100 8 9-Sep-87
JSYS.H.101 8 21-Sep-87
JSYS.H.102 9 21-Sep-87
JSYS.H.103 9 24-Sep-87
JSYS.H.104 9 24-Sep-87
JSYS.H.105 9 24-Sep-87
JSYS.H.106 9 24-Sep-87
JSYS.H.107 9 25-Sep-87
LIBC.DOC.200 14 11-Sep-87
LIBC.DOC.201 14 17-Sep-87
LIBC.REL.103 61 6-Mar-87
LIBC.REL.123 58 6-Mar-87
LIBC.REL.124 58 10-Sep-87
LIBC.REL.200 84 11-Sep-87
LIBC.REL.201 84 13-Sep-87
LIBC.REL.202 84 14-Sep-87
LIBC.REL.203 84 15-Sep-87
LIBC.REL.204 84 27-Oct-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
LIBCKX.REL.3 1 15-Sep-87
LIBTRM.REL.1 5 1-Jun-87
LIBTRM.REL.2 5 7-Oct-87
MATH.H.3 1 7-Apr-87
MATH.H.4 1 18-May-87
NETDB.H.1 1 21-Aug-87
SETJMP.H.3 1 6-Jul-87
SETJMP.H.4 1 11-Aug-87
SETJMP.H.5 1 13-Aug-87
SETJMP.H.6 1 13-Aug-87
SGTTY.H.1 1 22-May-87
SGTTY.H.2 1 23-May-87
SGTTY.H.3 1 3-Aug-87
SGTTY.H.4 1 3-Aug-87
SIGNAL.H.9 1 20-May-87
SIGNAL.H.10 1 7-Jun-87
SIGNAL.H.11 2 7-Jun-87
SIGNAL.H.12 2 23-Jun-87
SIGNAL.H.13 2 28-Jun-87
SIGNAL.H.14 2 6-Jul-87
SIGNAL.H.15 2 8-Jul-87
SIGNAL.H.16 2 21-Jul-87
SIGNAL.H.17 2 21-Jul-87
SIGNAL.H.18 2 22-Jul-87
SIGNAL.H.19 2 22-Jul-87
SIGNAL.H.20 2 30-Jul-87
SIGNAL.H.21 2 4-Aug-87
SIGNAL.H.22 3 4-Aug-87
SIGNAL.H.23 3 9-Aug-87
SIGNAL.H.24 3 11-Aug-87
SIGNAL.H.25 3 13-Aug-87
SIGNAL.H.26 3 14-Aug-87
SIGNAL.H.27 3 14-Aug-87
SIGNAL.H.28 3 16-Aug-87
SIGNAL.H.29 3 18-Aug-87
STDDEF.H.1 1 28-May-87
STDDEF.H.2 1 28-May-87
STDDEF.H.3 1 27-Aug-87
STDIO.H.9 2 13-Oct-87
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDIO.H.18 3 22-May-87
STDIO.H.19 3 17-Aug-87
STDIO.H.21 3 5-Sep-87
STDIO.H.22 3 5-Sep-87
STDIO.H.23 3 8-Sep-87
STDIO.H.24 3 10-Sep-87
STDIO.H.25 3 11-Sep-87
STDIO.H.26 3 11-Sep-87
STDIO.H.27 3 26-Oct-87
STDIO.H.28 3 27-Oct-87
STDLIB.H.1 1 18-Feb-87
STDLIB.H.2 1 8-Apr-87
STDLIB.H.5 2 7-Apr-87
STDLIB.H.6 2 7-Apr-87
STDLIB.H.7 2 8-Apr-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRING.H.7 1 17-May-87
STRING.H.8 1 24-May-87
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
STRUNG.H.3 1 13-Apr-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
TIME.H.6 1 2-Apr-87
TRMCAP.H.1 1 1-Jun-87
TRMCAP.H.2 1 1-Jun-87
URTSUD.H.5 1 18-Aug-87
URTSUD.H.6 1 18-Aug-87
USYS.DOC.29 6 11-Sep-87
USYS.DOC.30 7 12-Sep-87
USYS.DOC.31 7 11-Sep-87
Total of 1162 pages in 136 files.
8-Mar-88 15:38:46-PST,967;000000000000
Mail-From: KLH created at 8-Mar-88 15:38:36
Date: Tue, 8 Mar 88 15:38:36 PST
From: Ken Harrenstien <[email protected]>
Subject: New time routine package - <timex.h>
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I have installed a new auxiliary library of time-hacking routines called
TIMEX (the library is called LIBTMX). Documentation is in C:LIBTMX.DOC
and you can use them by (1) putting #include <timex.h> in your program, and
(2) adding "-ltmx" at the end of your CC command line, just as for -lnic.
These routines are ones I wrote quite a while ago for other things and I
recently spiffed them up into a more formal library for distribution. They
basically consist of:
time_parse - parse a date/time string
time_make - make a UNIX time word from the result of a parse
time_lzone - get local timezone info (portably)
Please send me any bugs, comments, or suggestions.
--Ken
-------
11-Mar-88 09:18:55-PST,1364;000000000000
Mail-From: IAN created at 11-Mar-88 09:18:50
Date: Fri, 11 Mar 1988 09:18 PST
Message-ID: <IAN.12381512373.BABYL@SRI-NIC>
From: Ian Macky <Ian@SRI-NIC>
To: seers@SRI-NIC
Subject: COMND package changes
I changed the way you get back the return value from a parse. Formerly,
r_data in the state block contained the thing, whatever it was, and you
did gross casts to turn it into whatever it was supposed to be.
Now, it's a union. You select the member for whatever type of parse it
was, e.g. r_data.table_data for the RH of the matching table entry,
r_data.number for a _CMNUM parse, etc.
Also, the r_data word is no clobbered for parses which do not actually
return values. That is, after a keyword parse, a cm_confirm() will NOT
eat r_data, so you don't have to store it away before the confirm and
fetch it from storage; you can use it directly from r_data.
This is the union:
union {
int table_data; /* RH data from table entry (KEY,SWI) */
int number; /* number typed by user (NUM) */
FILE *stream; /* stream for file parses (FIL,OFI,IFI) */
int directory; /* directory number of dir (DIR) */
int user; /* user number for usr (USR) */
float float_number; /* floating-point value (FLT) */
} r_data;
Note that the FILE* stream is not yet quite done, so don't expect it to
contain anything.
--ian
11-Mar-88 18:40:45-PST,558;000000000000
Mail-From: SKAHN created at 11-Mar-88 18:40:42
Date: Fri, 11 Mar 88 18:40:42 PST
From: Susan Kahn <[email protected]>
Subject: Database item use
To: [email protected]
Message-ID: <[email protected]>
I have compiled a file of the C programs that use the database and which
items they use. This file will assist us in the conversion to a new
database. If you modify/write any programs that use the database,
please update the file as appropriate. The name of the file is
<NICPROG>DBITEM-USE.LIST.
Thanks,
Susan
-------
16-Mar-88 17:21:59-PST,464;000000000000
Mail-From: SKAHN created at 16-Mar-88 17:21:58
Date: Wed, 16 Mar 88 17:21:58 PST
From: Susan Kahn <[email protected]>
Subject: Clean-up of C programs
To: [email protected]
Message-ID: <[email protected]>
I am working on identifying tops-20 dependent code and programs that
use the ID database. I have been looking only at the <NICPROG> and <NAMSER>
directories. Are there any other directories I need to worry about?
Susan
-------
24-Mar-88 21:11:26-PST,2661;000000000000
Date: 24 Mar 1988 1112:15-PST
From: [email protected]
Subject: File(s) not accessed since 30-Nov-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<C.INCLUDE>
Pages Date
A.OUT.H.1 2 26-Jun-87
AR.H.1 1 31-Jul-86
ASSERT.H.1 1 31-Jul-86
BINTTY.H.2 1 31-Jul-86
C-ENV.H.8 2 27-Jul-86
C-ENV.H.9 2 30-Jul-86
C-H10X.FAI.7 2 22-Nov-86
C-HDR.FAI.17 1 22-Jul-86
C-HDR.FAI.18 1 31-Jul-86
CC.DOC.48 19 28-Jul-86
CC.DOC.49 20 28-Jul-86
CC.DOC.50 20 28-Jul-86
CC.DOC.51 20 30-Jul-86
CLB10X.REL.3 33 22-Nov-86
CLIB.REL.18 25 22-Jul-86
CLIB.REL.200 26 22-Jul-86
CLIB.REL.201 26 22-Jul-86
CLIB.REL.202 26 22-Jul-86
CLIB.REL.203 26 22-Jul-86
CLIB.REL.204 26 22-Jul-86
CLIB.REL.210 56 22-Jul-86
CLIB.REL.212 56 22-Jul-86
CLIB.REL.215 56 22-Jul-86
CLIB.REL.216 56 17-Jul-86
CLIB.REL.221 56 24-Jul-86
CLIB.REL.224 57 25-Jul-86
CLIB.REL.225 58 25-Jul-86
CLIB.REL.226 59 31-Jul-86
CLIB.SIERRA.127 25 22-Jul-86
CTYPE.H.5 1 27-Jul-86
CTYPE.H.8 2 31-Jul-86
CURSES.H.4 2 31-Jul-86
ERRNO.H.1 1 31-Jul-86
ERRNO.H.2 2 16-Dec-85
ERRNO.H.3 2 31-Jul-86
FCNTL.H.1 1 26-Jun-87
JSYS.H.34 2 30-Jul-86
JSYS.H.35 2 30-Jul-86
LIBCUR.REL.1 42 22-Jul-86
LIBTRM.REL.3 4 22-Jul-86
MATH.H.3 1 31-Jul-86
NETDB.H.1 1 25-Jul-86
PWD.H.5 1 22-Jul-86
REGEX.H.3 2 22-Jul-86
SETJMP.H.3 1 31-Jul-86
SGTTY.H.1 1 20-May-87
SIGNAL.H.3 1 31-Jul-86
SIGNAL.H.6 2 31-Jul-86
STAB.H.1 1 22-Jul-86
STDIO.H.6 1 14-Jun-86
STDIO.H.9 2 24-Jul-86
STDIO.H.11 2 25-Jul-86
STDIO.H.12 2 31-Jul-86
STRINGS.H.1 1 31-Jul-86
STRINGS.H.2 1 31-Jul-86
SYSITS.H.2 1 22-Jul-86
TERMCAP..1 48 22-Jul-86
TYPES.H.1 1 31-Jul-86
UIO.H.35 1 29-Jul-86
UPARM.H.1 1 31-Jul-86
URTIO.H.1 1 7-May-86
URTIO.H.3 1 27-Feb-86
URTIO.H.4 1 7-May-86
URTIO.H.21 1 22-Jul-86
UTMP.H.1 1 22-Jul-86
VARARGS.H.4 1 31-Jul-86
WHOAMI.H.2 1 30-Jul-86
YACCPAR..1 2 19-Jun-86
Total of 901 pages in 68 files.
24-Mar-88 21:15:45-PST,3370;000000000000
Date: 24 Mar 1988 1201:23-PST
From: [email protected]
Subject: File(s) not accessed since 30-Nov-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC>
Pages Date
CTYPE.H.8 2 17-Jul-87
ERRNO.H.4 2 17-Jul-87
ERRNO.H.5 2 17-Jul-87
ERRNO.H.6 2 17-Jul-87
ERRNO.H.7 2 17-Jul-87
ERRNO.H.8 2 27-Aug-87
FCNTL.H.1 1 5-Sep-87
FCNTL.H.2 1 5-Sep-87
FRKXEC.H.1 1 31-Aug-87
FRKXEC.H.2 1 1-Sep-87
JSYS.H.81 4 10-Aug-87
JSYS.H.90 8 10-Aug-87
JSYS.H.91 8 13-Aug-87
JSYS.H.92 8 18-Aug-87
JSYS.H.93 8 24-Aug-87
JSYS.H.94 8 24-Aug-87
JSYS.H.95 8 25-Aug-87
JSYS.H.96 8 25-Aug-87
JSYS.H.97 9 30-Aug-87
JSYS.H.98 8 1-Sep-87
JSYS.H.99 8 2-Sep-87
JSYS.H.100 8 9-Sep-87
JSYS.H.101 8 21-Sep-87
JSYS.H.102 9 21-Sep-87
JSYS.H.103 9 24-Sep-87
JSYS.H.104 9 24-Sep-87
JSYS.H.105 9 24-Sep-87
JSYS.H.106 9 24-Sep-87
JSYS.H.107 9 25-Sep-87
LIBC.REL.204 84 27-Oct-87
LIBCKX.REL.1 1 17-Feb-87
LIBCKX.REL.2 1 20-Mar-87
LIBCKX.REL.3 1 15-Sep-87
LIBTRM.REL.1 5 1-Jun-87
LIBTRM.REL.2 5 7-Oct-87
MATH.H.3 1 7-Apr-87
MATH.H.4 1 18-May-87
NETDB.H.1 1 21-Aug-87
SETJMP.H.3 1 6-Jul-87
SETJMP.H.4 1 11-Aug-87
SETJMP.H.5 1 13-Aug-87
SETJMP.H.6 1 13-Aug-87
SGTTY.H.1 1 22-May-87
SGTTY.H.2 1 23-May-87
SGTTY.H.3 1 3-Aug-87
SGTTY.H.4 1 3-Aug-87
STDDEF.H.1 1 28-May-87
STDDEF.H.2 1 28-May-87
STDDEF.H.3 1 27-Aug-87
STDIO.H.9 2 13-Oct-87
STDIO.H.11 2 14-Aug-86
STDIO.H.12 2 21-Sep-86
STDIO.H.14 3 27-Sep-86
STDIO.H.15 3 27-Sep-86
STDIO.H.16 2 27-Sep-86
STDIO.H.17 2 27-Sep-86
STDIO.H.18 3 22-May-87
STDIO.H.19 3 17-Aug-87
STDIO.H.20 3 9-Nov-87
STDIO.H.21 3 5-Sep-87
STDIO.H.22 3 5-Sep-87
STDIO.H.23 3 8-Sep-87
STDIO.H.24 3 10-Sep-87
STDIO.H.25 3 11-Sep-87
STDIO.H.26 3 11-Sep-87
STDIO.H.27 3 26-Oct-87
STDIO.H.28 3 27-Oct-87
STDLIB.H.1 1 18-Feb-87
STDLIB.H.2 1 8-Apr-87
STDLIB.H.5 2 7-Apr-87
STDLIB.H.6 2 7-Apr-87
STDLIB.H.7 2 8-Apr-87
STRING.H.1 1 25-Sep-86
STRING.H.2 1 25-Sep-86
STRING.H.3 1 17-Nov-86
STRING.H.4 1 17-Nov-86
STRING.H.5 1 7-Dec-86
STRING.H.6 1 19-Dec-86
STRING.H.7 1 17-May-87
STRING.H.8 1 24-May-87
STRUNG.H.1 1 9-Feb-87
STRUNG.H.2 1 9-Feb-87
STRUNG.H.3 1 13-Apr-87
SYSITS.H.4 1 29-Sep-86
TIME.H.5 1 31-Mar-87
TIME.H.6 1 2-Apr-87
TRMCAP.H.1 1 1-Jun-87
TRMCAP.H.2 1 1-Jun-87
URTSUD.H.5 1 18-Aug-87
URTSUD.H.6 1 18-Aug-87
USYS.DOC.29 6 11-Sep-87
USYS.DOC.30 7 12-Sep-87
Total of 370 pages in 92 files.
24-Mar-88 21:16:18-PST,1198;000000000000
Date: 24 Mar 1988 1201:46-PST
From: [email protected]
Subject: File(s) not accessed since 30-Nov-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<KCC-0.INCLUDE>
Pages Date
C-ENV.H.9 2 25-Aug-86
C-H10X.FAI.7 2 25-Aug-86
C-HDR.FAI.18 1 25-Aug-86
CC.DOC.52 20 27-Sep-86
CLB10X.REL.3 33 25-Aug-86
CLIB.REL.237 59 25-Aug-86
CTYPE.H.8 2 25-Aug-86
ERRNO.H.7 2 25-Aug-86
JSYS.H.37 2 25-Aug-86
MATH.H.3 1 25-Aug-86
PRINTF.H.1 1 25-Aug-86
REGEX.H.3 2 25-Aug-86
SETJMP.H.3 1 25-Aug-86
SIGNAL.H.9 1 25-Aug-86
STDIO.H.12 2 25-Aug-86
STRING.H.1 1 25-Aug-86
STRINGS.H.2 1 25-Aug-86
SYSITS.H.2 1 25-Aug-86
UIO.H.36 1 25-Aug-86
URTIO.H.21 1 25-Aug-86
VARARGS.H.4 1 25-Aug-86
Total of 137 pages in 21 files.
28-Mar-88 13:03:08-PST,410;000000000000
Mail-From: IAN created at 28-Mar-88 13:03:04
Date: Mon, 28 Mar 88 13:03:03 PST
From: Ian Macky <[email protected]>
Subject: ID_UPDOPN() usage?
To: [email protected]
Message-ID: <[email protected]>
I need to know which C programs, if any, are using ID_UPDOPN(). This is the
call which write-locks the database. Whose C programs out there do actual
database updates?
--ian
-------
1-Apr-88 22:22:41-PST,1507;000000000000
Mail-From: SAPPHO created at 1-Apr-88 22:18:19
Date: 1 Apr 1988 2218:19-PST
From: [email protected]
Subject: Archived files
To: seers
The following files have been archived on SRI-NIC.ARPA:
PS:<KCC-0.INCLUDE>C-ENV.H.9 File archived, contents deleted
PS:<KCC-0.INCLUDE>C-H10X.FAI.7 File archived, contents deleted
PS:<KCC-0.INCLUDE>C-HDR.FAI.18 File archived, contents deleted
PS:<KCC-0.INCLUDE>CC.DOC.52 File archived, contents deleted
PS:<KCC-0.INCLUDE>CLB10X.REL.3 File archived, contents deleted
PS:<KCC-0.INCLUDE>CLIB.REL.237 File archived, contents deleted
PS:<KCC-0.INCLUDE>CTYPE.H.8 File archived, contents deleted
PS:<KCC-0.INCLUDE>ERRNO.H.7 File archived, contents deleted
PS:<KCC-0.INCLUDE>JSYS.H.37 File archived, contents deleted
PS:<KCC-0.INCLUDE>MATH.H.3 File archived, contents deleted
PS:<KCC-0.INCLUDE>PRINTF.H.1 File archived, contents deleted
PS:<KCC-0.INCLUDE>REGEX.H.3 File archived, contents deleted
PS:<KCC-0.INCLUDE>SETJMP.H.3 File archived, contents deleted
PS:<KCC-0.INCLUDE>SIGNAL.H.9 File archived, contents deleted
PS:<KCC-0.INCLUDE>STDIO.H.12 File archived, contents deleted
PS:<KCC-0.INCLUDE>STRING.H.1 File archived, contents deleted
PS:<KCC-0.INCLUDE>STRINGS.H.2 File archived, contents deleted
PS:<KCC-0.INCLUDE>SYSITS.H.2 File archived, contents deleted
PS:<KCC-0.INCLUDE>UIO.H.36 File archived, contents deleted
PS:<KCC-0.INCLUDE>URTIO.H.21 File archived, contents deleted
PS:<KCC-0.INCLUDE>VARARGS.H.4 File archived, contents deleted
8-Apr-88 05:08:08-PDT,586;000000000000
Mail-From: KLH created at 8-Apr-88 05:08:05
Date: Fri, 8 Apr 88 05:08:05 PDT
From: Ken Harrenstien <[email protected]>
Subject: New KCC installed
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I have installed a new KCC which fixes a couple of bugs that came up recently.
This version has a new format for reporting errors, which is more compact
and more informative; the first line is also identical to the format of
Unix-based compiler error messages. If you are seriously unhappy with it,
let me know what you want.
-------
13-Apr-88 06:10:40-PDT,390;000000000000
Date: 13 Apr 1988 0607:49-PDT
From: [email protected]
Subject: Expunged Archive File(s)
To: seers
The Following Archived File(s) have been Expunged:
PS:<KCCDIST.INCLUDE>LIBC.REL.205 Tape 1:121,2,2920 Tape 2:122,2,2920
PS:<KCCDIST.INCLUDE>LIBTRM.REL.3 Tape 1:121,2,2922 Tape 2:122,2,2922
PS:<KCCDIST.INCLUDE>LIBCKX.REL.4 Tape 1:121,2,2921 Tape 2:122,2,2921
13-Apr-88 15:04:58-PDT,2021;000000000000
Mail-From: KLH created at 13-Apr-88 15:04:49
Date: Wed, 13 Apr 88 15:04:49 PDT
From: Ken Harrenstien <[email protected]>
Subject: replacing HALTF jsys
To: [email protected]
cc: [email protected], [email protected]
Message-ID: <[email protected]>
I have installed a new C library in which signal() handles SIGTSTP
correctly. Here is the relevant extract that I just added to C:SIGNAL.DOC
(you should read the entire file if you haven't seen it before).
-----------------------------
Process control with signals:
SIGTSTP and SIGCONT are partially supported. The recommended,
BSD-portable way for an inferior process to return temporarily to its
superior is by doing:
kill(getpid(), SIGTSTP); /* or raise(SIGTSTP) */
This will stop the process with a HALTF%. If it is continued, a SIGCONT
signal will automatically be generated, and will invoke a handler if any
exists.
It is possible for a program to use kill() to send signals to
its parent (superior) or its children (inferiors); the PID argument to
kill() should be that returned from a previous getpid() or fork().
This ability is limited however to just those signals which are
"supported" with specific PSI channels; the "miscellaneous" signals
cannot be triggered in another process.
The signals SIGKILL, SIGSTOP, SIGTSTP, and SIGCONT are interpreted
specially when applied to a child process. SIGKILL does a HFORK% to halt
the inferior; SIGSTOP and SIGTSTP do a FFORK% to freeze it; and SIGCONT
does a RFORK% to resume execution of a frozen child.
Note that SIGCONT cannot be fully implemented because TOPS-20
does not provide any general way for a process to know whether it has
been halted and continued. The current implementation does the best
that can be done, which is to artificially generate SIGCONT after
being continued from an explicit triggering of SIGTSTP.
SIGTSTP cannot at this time be generated by TTY input. If there
is a need for it this may be possible.
-------
15-Apr-88 04:26:43-PDT,1798;000000000000
Mail-From: KLH created at 15-Apr-88 04:26:41
Date: Fri, 15 Apr 88 04:26:41 PDT
From: Ken Harrenstien <[email protected]>
Subject: new C library
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I have installed a new C library which has one significant change.
When a new file is opened for writing (such as with fopen(path, "w")
or with I/O redirection), the file is immediately closed and then
re-opened. The most noticeable effect of this is that when a program
aborts for some reason, it will leave around a partial, possibly
empty, file.
Normally, on TOPS-20, any files opened by a program are actually
non-existent until they are gracefully closed; if a program halts
abnormally (such as by a ^C interrupt) and is reset, then all such
open files vanish utterly. The original intent of this was evidently
to ensure that only complete, good, versions of a file were actually
left on the disk.
But this is not the way things work on Unix, and causes problems with
"File busy" or "invalid simultaneous access" when more than one
process (or even the same process) tries to open another file of the
same name (even when you ask for a higher version number). The
simplest way to fix all of these problems, for what is expected to
be a very small cost, is to always force the system to grant the
file a permanent existence as soon as it is opened. If it is
important to make sure that only valid versions of a given file
exist, then other mechanisms are far preferable to relying on the TOPS-20
ghost file misfeature; for example, writing to a temporary filename and
doing a rename operation only when everything is complete.
This is not an irrevocable change; if you have any comments please
express them.
-------
18-Apr-88 18:58:45-PDT,550;000000000000
Mail-From: SKAHN created at 18-Apr-88 18:56:49
Date: Mon, 18 Apr 88 18:56:48 PDT
From: Susan Kahn <[email protected]>
Subject: Meeting to discuss NIC library of C functions
To: [email protected]
Message-ID: <[email protected]>
I would like to schedule a meeting to discuss policies for the NIC
library of C functions on Friday, April 22 at 2 P.M. Please let
me know if you cannot make it. I will be distributing a document
for your review tomorrow. Please read it by the Friday meeting.
Thanks.
Susan
-------
20-Apr-88 11:36:24-PDT,391;000000000000
Mail-From: SKAHN created at 20-Apr-88 11:35:40
Date: Wed, 20 Apr 88 11:35:39 PDT
From: Susan Kahn <[email protected]>
Subject: Friday meeting room EK242
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
The meeting on Friday at 2 P.M. will be in room EK242. Our
conference room was already reserved.
-------
21-Apr-88 02:24:06-PDT,991;000000000000
Mail-From: MKL created at 21-Apr-88 02:24:03
Date: Thu, 21 Apr 88 02:24:03 PDT
From: Mark Lottor <[email protected]>
Subject: ghost file stuff
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I just happened to read thru some old seers mail and came across
your changes to make unclosed files be permanent. I think this
is real bad. For instance I've got a batch job that runs once
a week and dumps out a new listing of TACs for the tacfnd program.
If there is an error and the program dies I don't expect the file
to be generated. In your new scheme an empty file will exist,
and the tacfnd program will start losing big. The program is run
with i/o redirection as in "tacdmp > tacdmp.out". So what am
I supposed to do to keep an empty file from appearing???
Can I do a call that says "delete redirected file"?
Or do I have to kludge up my batch job control file to notice the
error and delete the newest version?
-------
21-Apr-88 02:45:26-PDT,853;000000000000
Mail-From: MKL created at 21-Apr-88 02:45:24
Date: Thu, 21 Apr 88 02:45:23 PDT
From: Mark Lottor <[email protected]>
Subject: more ghost file stuff
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
And what if the system crashes during the program execution? You end
up with bogus empty files. If you use your 'temporary file then rename'
scheme, then you end up with bogus temporary files lying around.
That's why on Unix machines every time you boot the system a program
deletes all the temp files. Isn't having a good, complete file ALWAYS
a critical function?
Another way to solve the problem might be to set the
'file is deleted bit' when you create the bogus file,
and only undelete it when it is properly closed.
But can you write to a deleted file? I don't know offhand.
-------
21-Apr-88 15:21:26-PDT,2018;000000000000
Mail-From: KLH created at 21-Apr-88 15:21:05
Date: Thu, 21 Apr 88 15:21:05 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: ghost file stuff
To: [email protected]
cc: [email protected], [email protected]
Message-ID: <[email protected]>
Yes, the job control file (or whatever examines tacdmp.out) should be
able to deal with files that are incomplete or empty as a result of
errors. In practice such a thing would be done using a script
that wrote the file to a temporary name, and if there were no
problems, it would then rename the file to the official name, and then
flush any older temporary files.
Any sensible program that tries to guarantee the consistency of files
it creates must ALWAYS write to a temporary file and only when
complete should it rename that file to the desired real name. EMACS
does this, for example. (There is no monopoly on poor design -- on
Unix, "passwd" used not to do that, with the result that every so
often /etc/passwd would be trashed and no one could log in.)
What you didn't see was the debate over whether to go ahead with this
feature or not. On the negative side, programs which were written with
this TOPS-20 (mis)feature in mind may be surprised. On the positive side,
programs written with a UNIX model in mind will work much better. For
example, stat(), fstat(), access(), and open() now work properly when
given pathnames of files being written; before now there simply was no way
they could work at all. This problem even affects native TOPS-20 programs
when you try to run more than one of them at a time and they both want
something with the same name -- instead of getting a different version, one
of them will just die. C programs won't have these problems now.
I feel pretty strongly that the change to open() solves more problems
than it creates, and encourages the sort of conservative thinking that
we'll need if we are seriously going to transform our tools for a unix
environment.
-------
21-Apr-88 16:05:48-PDT,1400;000000000000
Mail-From: MKL created at 21-Apr-88 16:05:44
Date: Thu, 21 Apr 88 16:05:43 PDT
From: Mark Lottor <[email protected]>
Subject: Re: ghost file stuff
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
>This problem even affects native TOPS-20 programs when you try to run
>more than one of them at a time and they both want something with the
>same name -- instead of getting a different version, one of them will
>just die. C programs won't have these problems now.
I would consider the tops-20 case to be better then. If two programs start
up to do something like create a new host table, then you would want one
of them to die. Otherwise they both will think they won when in fact
the older file created will never be used. If you really want to do
it the Unix way, then both programs should open the SAME generation
of the output file, and both of them should write to it at the same time!
In fact opening a file for write should NEVER create a new generation,
it should always write over the existing file. It seems like you're just
picking and choosing which features of Unix and Tops-20 you want to use.
The reason "C programs won't have these problems now" is only
because you are using the Tops-20 feature of file generations.
Put them on Unix and they will die too.
-------
21-Apr-88 16:38:44-PDT,1487;000000000000
Mail-From: KLH created at 21-Apr-88 16:38:35
Date: Thu, 21 Apr 88 16:38:34 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: ghost file stuff
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
What happens on Unix if two programs try to write to the same file at
the same time depends on how they open() the file. In one case they
get the same file, in another the second attempt will fail.
You can request the same features on the TOPS-20 implementation of open()
by saying whether a new file should be created or not, and whether it
should fail if the file already exists. The default flags given to open()
by fopen(file,"w") always ask to create a new version since that is what
we want on TOPS-20 and it hurts nothing.
The main time you might have a conflict between two processes opening
the same file is when they are both trying to open the same temporary
file. It doesn't matter what the name is, only that it be unique. On
TOPS-20 the strange situation can arise where you ask for a new
version of a file (even a ;T file) and then when you try to open it
you get a mysterious failure, because someone else (perhaps even your
own process) already has that file open (but it's really a ghost file
so you can't see it...). This has caused problems for mktemp(),
tmpnam(), and tmpfile(). The fix to open() solves this, too.
-------
24-Apr-88 10:51:43-PDT,2662;000000000000
Date: 24 Apr 1988 1017:39-PDT
From: [email protected]
Subject: File(s) not accessed since 31-Dec-87
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<C.INCLUDE>
Pages Date
A.OUT.H.1 2 26-Jun-87
AR.H.1 1 31-Jul-86
ASSERT.H.1 1 31-Jul-86
BINTTY.H.2 1 31-Jul-86
C-ENV.H.8 2 27-Jul-86
C-H10X.FAI.7 2 22-Nov-86
C-HDR.FAI.17 1 22-Jul-86
C-HDR.FAI.18 1 31-Jul-86
CC.DOC.48 19 28-Jul-86
CC.DOC.49 20 28-Jul-86
CC.DOC.50 20 28-Jul-86
CC.DOC.51 20 30-Jul-86
CLB10X.REL.3 33 22-Nov-86
CLIB.REL.18 25 22-Jul-86
CLIB.REL.200 26 22-Jul-86
CLIB.REL.201 26 22-Jul-86
CLIB.REL.202 26 22-Jul-86
CLIB.REL.203 26 22-Jul-86
CLIB.REL.204 26 22-Jul-86
CLIB.REL.210 56 22-Jul-86
CLIB.REL.212 56 22-Jul-86
CLIB.REL.215 56 22-Jul-86
CLIB.REL.216 56 17-Jul-86
CLIB.REL.221 56 24-Jul-86
CLIB.REL.224 57 25-Jul-86
CLIB.REL.225 58 25-Jul-86
CLIB.REL.226 59 31-Jul-86
CLIB.SIERRA.127 25 22-Jul-86
CTYPE.H.5 1 27-Jul-86
CTYPE.H.8 2 31-Jul-86
CURSES.H.4 2 31-Jul-86
ERRNO.H.1 1 31-Jul-86
ERRNO.H.2 2 16-Dec-85
ERRNO.H.3 2 31-Jul-86
FCNTL.H.1 1 26-Jun-87
JSYS.H.34 2 30-Jul-86
JSYS.H.35 2 30-Jul-86
LIBCUR.REL.1 42 22-Jul-86
LIBTRM.REL.3 4 22-Jul-86
MATH.H.3 1 31-Jul-86
NETDB.H.1 1 25-Jul-86
PWD.H.5 1 22-Jul-86
REGEX.H.3 2 22-Jul-86
SETJMP.H.3 1 31-Jul-86
SGTTY.H.1 1 20-May-87
SIGNAL.H.3 1 31-Jul-86
SIGNAL.H.6 2 31-Jul-86
STAB.H.1 1 22-Jul-86
STDIO.H.6 1 14-Jun-86
STDIO.H.9 2 24-Jul-86
STDIO.H.11 2 25-Jul-86
STDIO.H.12 2 31-Jul-86
STRING.H.1 1 9-Dec-87
STRINGS.H.1 1 31-Jul-86
STRINGS.H.2 1 31-Jul-86
SYSITS.H.2 1 22-Jul-86
TERMCAP..1 48 22-Jul-86
TYPES.H.1 1 31-Jul-86
UIO.H.35 1 29-Jul-86
UPARM.H.1 1 31-Jul-86
URTIO.H.1 1 7-May-86
URTIO.H.3 1 27-Feb-86
URTIO.H.4 1 7-May-86
URTIO.H.21 1 22-Jul-86
UTMP.H.1 1 22-Jul-86
VARARGS.H.4 1 31-Jul-86
WHOAMI.H.2 1 30-Jul-86
YACCPAR..1 2 19-Jun-86
Total of 900 pages in 68 files.
25-Apr-88 20:46:40-PDT,982;000000000000
Mail-From: IAN created at 25-Apr-88 20:46:38
Date: Mon, 25 Apr 88 20:46:37 PDT
From: Ian Macky <[email protected]>
Subject: COMND package changes
To: [email protected]
Message-ID: <[email protected]>
i made some changes in the comnd package. you can now directly initialize
the data word of the cm_fdb with a pointer value, not just with an int as
before.
so it is no longer necessary to use the cm_declare thingy to match up
tables and fdbs. instead of the cm_declare, just define an array of
cm_fdb*s and list all the fdbs there, and give that array to cm_init().
example:
cm_def_fdb(normal_fdb, _CMKEY, CM_HPP, &void_commands,
str7("a VOID command,"), NULL, NULL, NULL)
assuming void_commands has been declared previously.
and:
cm_fdb *fdbs[] = {
&normal_fdb, &def_fdb, &deb_fdb, &mode_fdb, &comp_fdb, &show_fdb,
&show0_fdb, &time_fdb, &scr_fdb, &upd_fdb, &itm_fdb, &itm0_fdb,
. . .
NULL
};
--ian
-------
27-Apr-88 18:10:30-PDT,510;000000000000
Mail-From: SKAHN created at 27-Apr-88 18:10:26
Date: Wed, 27 Apr 88 18:10:26 PDT
From: Susan Kahn <[email protected]>
Subject: NIC library
To: [email protected], [email protected]
Message-ID: <[email protected]>
I will be distributing a document that records the policies for
the NIC library that we discussed at last week's programmers meeting.
Please send feedback to me and I will arrange another meeting if
it looks like further discussion is needed.
Thanks.
Susan
-------
29-Apr-88 12:24:23-PDT,371;000000000001
Mail-From: SKAHN created at 29-Apr-88 12:03:06
Date: Fri, 29 Apr 88 12:03:04 PDT
From: Susan Kahn <[email protected]>
Subject: Feedback about the library
To: [email protected], [email protected]
Message-ID: <[email protected]>
Please get your feedback to me about the NIC libraries document by next
Wednesday, May 4th. Thanks.
Susan
-------
24-May-88 09:52:08-PDT,2596;000000000000
Date: 24 May 1988 0638:51-PDT
From: [email protected]
Subject: File(s) not accessed since 30-Jan-88
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<C.INCLUDE>
Pages Date
A.OUT.H.1 2 26-Jun-87
AR.H.1 1 31-Jul-86
ASSERT.H.1 1 31-Jul-86
BINTTY.H.2 1 31-Jul-86
C-ENV.H.8 2 27-Jul-86
C-HDR.FAI.17 1 22-Jul-86
CC.DOC.48 19 28-Jul-86
CC.DOC.49 20 28-Jul-86
CC.DOC.50 20 28-Jul-86
CC.DOC.51 20 30-Jul-86
CLB10X.REL.3 33 22-Nov-86
CLIB.REL.18 25 22-Jul-86
CLIB.REL.200 26 22-Jul-86
CLIB.REL.201 26 22-Jul-86
CLIB.REL.202 26 22-Jul-86
CLIB.REL.203 26 22-Jul-86
CLIB.REL.204 26 22-Jul-86
CLIB.REL.210 56 22-Jul-86
CLIB.REL.212 56 22-Jul-86
CLIB.REL.215 56 22-Jul-86
CLIB.REL.216 56 17-Jul-86
CLIB.REL.221 56 24-Jul-86
CLIB.REL.224 57 25-Jul-86
CLIB.REL.225 58 25-Jul-86
CLIB.REL.226 59 31-Jul-86
CLIB.SIERRA.127 25 22-Jul-86
CTYPE.H.5 1 27-Jul-86
CTYPE.H.8 2 31-Jul-86
CURSES.H.4 2 31-Jul-86
ERRNO.H.1 1 31-Jul-86
ERRNO.H.2 2 16-Dec-85
ERRNO.H.3 2 31-Jul-86
FCNTL.H.1 1 26-Jun-87
JSYS.H.34 2 30-Jul-86
JSYS.H.35 2 30-Jul-86
LIBCUR.REL.1 42 22-Jul-86
LIBTRM.REL.3 4 22-Jul-86
MATH.H.3 1 31-Jul-86
NETDB.H.1 1 25-Jul-86
PWD.H.5 1 22-Jul-86
REGEX.H.3 2 22-Jul-86
SETJMP.H.3 1 31-Jul-86
SGTTY.H.1 1 20-May-87
SIGNAL.H.3 1 31-Jul-86
SIGNAL.H.6 2 31-Jul-86
STAB.H.1 1 22-Jul-86
STDIO.H.6 1 14-Jun-86
STDIO.H.9 2 24-Jul-86
STDIO.H.11 2 25-Jul-86
STDIO.H.12 2 31-Jul-86
STRING.H.1 1 9-Dec-87
STRINGS.H.1 1 31-Jul-86
STRINGS.H.2 1 31-Jul-86
SYSITS.H.2 1 22-Jul-86
TERMCAP..1 48 22-Jul-86
TYPES.H.1 1 31-Jul-86
UIO.H.35 1 29-Jul-86
UPARM.H.1 1 31-Jul-86
URTIO.H.1 1 7-May-86
URTIO.H.3 1 27-Feb-86
URTIO.H.4 1 7-May-86
URTIO.H.21 1 22-Jul-86
UTMP.H.1 1 22-Jul-86
VARARGS.H.4 1 31-Jul-86
WHOAMI.H.2 1 30-Jul-86
YACCPAR..1 2 19-Jun-86
Total of 897 pages in 66 files.
25-May-88 11:52:36-PDT,511;000000000000
Mail-From: SKAHN created at 25-May-88 11:52:29
Date: Wed, 25 May 88 11:52:29 PDT
From: Susan Kahn <[email protected]>
Subject: library function names
To: [email protected]
Message-ID: <[email protected]>
I am in the process of changing the names of the NIC library functions to
our agreed upon names. So, until further notice, please inform me of
any changes that you make in the NIC library functions so that I can
keep my working versions up-to-date.
Thanks,
Susan
-------
1-Jun-88 12:45:58-PDT,1664;000000000000
Mail-From: SKAHN created at 1-Jun-88 12:45:54
Date: Wed, 1 Jun 88 12:45:54 PDT
From: Susan Kahn <[email protected]>
Subject: NIC library function names changed
To: [email protected]
Message-ID: <[email protected]>
I have changed all the function names in the NIC library files,
LIBGEN (now called LIBNX), LIBIFP, and LIBIDB, in accordance with
the NIC function naming conventions as described in the document
ts:<skahn>conventions.ps (which is a laser printable file).
I have modified the header files for each library source file
(LIBNX.H, LIBIFP.H and LIBIDB.H) to include #defines for the old
function names so that existing C programs that use the library
functions will continue to compile and load without any change,
PROVIDING they have #include statements for the appropriate header
files. I modified the LIBGEN.H header file to consist of an #include
for LIBNX.H. The header files are in the <KCC.NIC> directory;
the library source files are in the <NICPROG.LIBNIC> directory.
Eventually, the plan is to change the function names in the calling
program and eliminate the #defines for the old names.
As far as I know, there are only two programs that will not compile
as a result of these changes. The are <NICPROG>NEX.C and <NICPROG>NP2.C.
Both of these need to be modified to include #include statements for
LIBNX.H and LIBIDB.H, or they must be modified to call the library
functions by their new names. These are Harry's programs and I assume
that he will take care of it. I will communicate directly with
Harry about this.
Please let me know if you run into any problems.
Susan
-------
1-Jun-88 15:47:49-PDT,437;000000000000
Mail-From: KLH created at 1-Jun-88 15:47:39
Date: Wed, 1 Jun 88 15:47:38 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: NIC library function names changed
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I thought LIBIDB was going to be changed to LIBDBI, and the routines
prefixed with dbid_.
-------
1-Jun-88 16:46:24-PDT,808;000000000000
Mail-From: SKAHN created at 1-Jun-88 16:46:01
Date: Wed, 1 Jun 88 16:46:01 PDT
From: Susan Kahn <[email protected]>
Subject: Re: NIC library function names changed
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I have changed the name of LIBIDB.C to be LIBDBI.C and have modified the
header file LIBIDB.H to consist of #include LIBDBI.C. The three NIC library
source and header files and the prefix for functions are:
source file header file function name prefix
LIBNX.C LIBNX.H nx_
LIBIFP.C LIBIFP.H ifp_
LIBDBI.C LIBDBI.H dbid_
Sorry for any inconvenience my error has caused.
Susan
-------
14-Jun-88 15:52:56-PDT,1460;000000000000
Mail-From: IAN created at 14-Jun-88 15:52:49
Date: Tue, 14 Jun 88 15:52:49 PDT
From: Ian Macky <[email protected]>
Subject: More changes in COMND package...
To: [email protected]
Message-ID: <[email protected]>
The COMND package is undergoing some transformations in preparation to Un*x
porting. The latest round of changes, effective immediately, are:
* You don't have to and shouldn't declare your own cm_state
state block. A single state block is allocated by the
comnd package itself, and that is the sole block now used.
* And so, in the cm_init() call, oimit the first arg, which
used to be the users state block.
* To fetch the "last FDB used" (r_used) and "last data" (r_data),
you should refer to them as cm_used and cm_data, instead of
fetching them as members of your own state block. That is,
if you used to have a state block "state", where you used to
do "state.r_used" you now do "cm_used", and where you used
to do "state.r_data.xxx" you now do "cm_data.xxx". xxx
continues to be the member of the union which r_data is,
one of "number", "table_data", etc.
* The cm_set_reparse() no longer needs to have the users state
block specified. It is an error to do so now.
Sorry for the inconvenience, folks - it's sucky for me too. Fortunately,
global replaces can effect these changes for you with the minimum of
manual fondling...
--ian
-------
16-Jun-88 13:56:37-PDT,1366;000000000000
Mail-From: IAN created at 16-Jun-88 13:56:33
Date: Thu, 16 Jun 88 13:56:32 PDT
From: Ian Macky <[email protected]>
Subject: Phase II of COMND switchover...
To: [email protected]
Message-ID: <[email protected]>
...the next group of changes to COMND follows. One day soon I will update
the COMND package documentation in NICPROG:COMND.DOC, which is now fairly
obsolete.
* Global error-restart. From now on, when a parse fails,
the COMND code will do a global error-restart via longjmp
to the state save by cm_set_error_trap(). Your code
should perform cleanup of any opened files, allocated-
during-parse memory, etc, immediately following the
error_trap.
* Use cm_start_parse() to start off the parse chain, not
parse(&cmini).
* Use cm_str() to construct strings for comnd functions
instead of using str7(). Likewise, use cm_char as the
type of storage for comnd strings, not char7.
* Use cm_set_prompt() to set the comnd state prompt, not
cm_prompt().
There will one more round of changes in the future, then the package will
be stable again. Any questions? In case you're all wondering why I'm
tormenting you like this, it's to provide a standardized command interface
that will work with both the T20 COMND% interface as well as Columbia's
CCMD package.
--ian
-------
30-Jun-88 10:12:33-PDT,364;000000000000
Mail-From: FRED created at 30-Jun-88 10:12:30
Date: Thu, 30 Jun 88 10:12:29 PDT
From: Fred Ostapik <[email protected]>
Subject: Credo
To: [email protected]
Message-ID: <[email protected]>
Programmers' credo - excerpted from a Hacker's bible
"I would understand life much better if someone would just show me the source
code."
-------
1-Jul-88 18:27:25-PDT,2626;000000000000
Date: 24 Jun 1988 1059:28-PDT
From: [email protected]
Subject: File(s) not accessed since 1-Mar-88
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<C.INCLUDE>
Pages Date
A.OUT.H.1 2 26-Jun-87
AR.H.1 1 31-Jul-86
ASSERT.H.1 1 31-Jul-86
BINTTY.H.2 1 31-Jul-86
C-ENV.H.8 2 27-Jul-86
C-HDR.FAI.17 1 22-Jul-86
CC.DOC.48 19 28-Jul-86
CC.DOC.49 20 28-Jul-86
CC.DOC.50 20 28-Jul-86
CC.DOC.51 20 30-Jul-86
CC.DOC.52 20 28-Feb-88
CLB10X.REL.3 33 22-Nov-86
CLIB.REL.18 25 22-Jul-86
CLIB.REL.200 26 22-Jul-86
CLIB.REL.201 26 22-Jul-86
CLIB.REL.202 26 22-Jul-86
CLIB.REL.203 26 22-Jul-86
CLIB.REL.204 26 22-Jul-86
CLIB.REL.210 56 22-Jul-86
CLIB.REL.212 56 22-Jul-86
CLIB.REL.215 56 22-Jul-86
CLIB.REL.216 56 17-Jul-86
CLIB.REL.221 56 24-Jul-86
CLIB.REL.224 57 25-Jul-86
CLIB.REL.225 58 25-Jul-86
CLIB.REL.226 59 31-Jul-86
CLIB.SIERRA.127 25 22-Jul-86
CTYPE.H.5 1 27-Jul-86
CTYPE.H.8 2 31-Jul-86
CURSES.H.4 2 31-Jul-86
ERRNO.H.1 1 31-Jul-86
ERRNO.H.2 2 16-Dec-85
ERRNO.H.3 2 31-Jul-86
FCNTL.H.1 1 26-Jun-87
JSYS.H.34 2 30-Jul-86
JSYS.H.35 2 30-Jul-86
LIBCUR.REL.1 42 22-Jul-86
LIBTRM.REL.3 4 22-Jul-86
MATH.H.3 1 31-Jul-86
NETDB.H.1 1 25-Jul-86
PWD.H.5 1 22-Jul-86
REGEX.H.3 2 22-Jul-86
SETJMP.H.3 1 31-Jul-86
SGTTY.H.1 1 20-May-87
SIGNAL.H.3 1 31-Jul-86
SIGNAL.H.6 2 31-Jul-86
STAB.H.1 1 22-Jul-86
STDIO.H.6 1 14-Jun-86
STDIO.H.9 2 24-Jul-86
STDIO.H.11 2 25-Jul-86
STDIO.H.12 2 31-Jul-86
STRING.H.1 1 9-Dec-87
STRINGS.H.1 1 31-Jul-86
STRINGS.H.2 1 31-Jul-86
SYSITS.H.2 1 22-Jul-86
TERMCAP..1 48 22-Jul-86
TYPES.H.1 1 31-Jul-86
UIO.H.35 1 29-Jul-86
UPARM.H.1 1 31-Jul-86
URTIO.H.1 1 7-May-86
URTIO.H.3 1 27-Feb-86
URTIO.H.4 1 7-May-86
URTIO.H.21 1 22-Jul-86
UTMP.H.1 1 22-Jul-86
VARARGS.H.4 1 31-Jul-86
WHOAMI.H.2 1 30-Jul-86
YACCPAR..1 2 19-Jun-86
Total of 917 pages in 67 files.
13-Jul-88 01:30:16-PDT,495;000000000000
Mail-From: MKL created at 13-Jul-88 01:30:02
Date: Wed, 13 Jul 88 01:30:01 PDT
From: Mark Lottor <[email protected]>
Subject: variable decls
To: [email protected]
Message-ID: <[email protected]>
The C book I have says to declare your function variables
as you list them, like "foo(int a)", apparently the ansi
standard. Yet most code I've looked at does the declaration
on the next few lines. Is there a prefered way? Will
the ansi style work most places?
-------
13-Jul-88 13:18:41-PDT,1089;000000000000
Mail-From: KLH created at 13-Jul-88 13:18:19
Date: Wed, 13 Jul 88 13:18:18 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: variable decls
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Which C book do you have? H&S v2 is quite clear on differentiating the
"foo(int a)" dpANS syntax from the actual current standard.
If you know that your code will NEVER be ported to anyplace that doesn't
have an ANSI C compiler, then you can PROBABLY use the dpANS syntax.
Otherwise, use the old syntax. I say "probably" because anything you might
find in any book is just a draft -- it will not become the actual standard
until at least one more review cycle is completed. In fact, just today
I received the latest draft, which has substantial changes from the
last one.
We don't have any compiler that groks any dpANS syntax, unless you are
thinking about using Gnu CC. I decided long ago not to bother trying to
make KCC track a moving target.
-------
13-Jul-88 13:38:27-PDT,429;000000000000
Mail-From: MKL created at 13-Jul-88 13:38:21
Date: Wed, 13 Jul 88 13:38:21 PDT
From: Mark Lottor <[email protected]>
Subject: Re: variable decls
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I'm using K&R second edition. It says "we strongly recommend you use
the new form when you have a compiler that supports it".
-------
13-Jul-88 14:14:40-PDT,2285;000000000000
Mail-From: KLH created at 13-Jul-88 14:14:27
Date: Wed, 13 Jul 88 14:14:26 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: variable decls
To: [email protected]
cc: [email protected], [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Aha! If you compare a copy of H&S vs K&R their relative sizes will
tell you something about which one is more comprehensive and complete.
Anyway, K&R is correct in a sense, because function prototypes do help
the compiler catch some simple errors.
I found K&R v2 to be rather interesting, though perhaps not in the way
the authors expected. They claim that "Modern compilers already
support most features of the standard". First, there is no Standard,
only a draft. Second, I can only assume they misleadingly used the
adjective "modern" to avoid complete falsehood -- by definition a
"modern" compiler supports these features, whereas an "old" compiler
doesn't. I would guess that the bulk of actual compilers in existence
are "old"; for example, the VAX and SUN compilers don't grok the dpANS
stuff.
As further evidence, they thank someone for providing them with an ANSI
C compiler for final testing. Why would they need a specially provided
compiler if there were indeed plenty of them going around? Doesn't AT&T
have any?
I also understand a little better now why Ritchie finally came out of
seclusion to attend his first X3J11 meeting in order to help shoot
down a recent addition to the draft (the great "noalias" war)...
ostensibly this was due to the technical problems with the new
keyword, but I wonder now if perhaps he also had some interest in
ensuring that this new book, already in press, would not be instantly
obsolete -- as it would have been, considering how many bridges they
burned in the wording and examples they've used.
So, take K&R v2 with a large quantity of salt. It may come to be
completely true. At the moment it is not. It is better than H&S as a
tutorial and introduction to C, and the appendices are straightforward
and more precise than the text. But there is just no way it can match H&S
v2 as a complete and accurate reference, especially for the library
functions.
--Ken
-------
14-Jul-88 18:50:06-PDT,422;000000000000
Mail-From: MKL created at 14-Jul-88 18:50:01
Date: Thu, 14 Jul 88 18:50:01 PDT
From: Mark Lottor <[email protected]>
Subject: signed char?
To: [email protected]
Message-ID: <[email protected]>
How come I can't seem to turn a char into a signed int.
I tried:
i=(signed) c
i=(int) c
i= c
and none of them worked. I want chars with the high bit set
to turn into negative numbers.
-------
14-Jul-88 19:09:21-PDT,1500;000000000000
Mail-From: KLH created at 14-Jul-88 19:09:13
Date: Thu, 14 Jul 88 19:09:13 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: signed char?
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
All of the things you tried are equivalent. I assume you had declared
"i" as "int" and "c" as "char".
Whether the "char" type is signed or unsigned is implementation dependent.
With KCC, it is unsigned. On other machines, especially 11s and variants,
it is signed.
If the compiler supports the type "signed char" (not all do yet) then
you can win. say "i = (signed char) c;". The reason it doesn't work to
use (signed) is because the type is really defaulting to (signed int). So
you are just doing the same conversion that "i = c" already does.
Note, by the way, that the size of a char is also implementation dependent.
So if you are merely trying to widen an integer value, you should have declared
"c" as "signed char" in the first place, so that its value would always
be considered a signed integer value and would be automatically widened
properly when converted to "int". Otherwise, if you are making an assumption
as to where the sign bit is, you are going to lose. It would be safer
to make an explicit test of the bit position you have in mind.
For a thorough treatment of all this, read 5.1.3 (p 86-89) and
all of chapter 6 in H&S v2.
-------
1-Aug-88 16:05:07-PDT,2656;000000000000
Date: 25 Jul 1988 0721:22-PDT
From: [email protected]
Subject: File(s) not accessed since 1-Apr-88
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<C.INCLUDE>
Pages Date
A.OUT.H.1 2 26-Jun-87
AR.H.1 1 31-Jul-86
ASSERT.H.1 1 31-Jul-86
BINTTY.H.2 1 31-Jul-86
C-ENV.H.8 2 27-Jul-86
C-ENV.H.9 2 25-Mar-88
C-HDR.FAI.17 1 22-Jul-86
CC.DOC.48 19 28-Jul-86
CC.DOC.49 20 28-Jul-86
CC.DOC.50 20 28-Jul-86
CC.DOC.51 20 30-Jul-86
CC.DOC.52 20 28-Feb-88
CLB10X.REL.3 33 22-Nov-86
CLIB.REL.18 25 22-Jul-86
CLIB.REL.200 26 22-Jul-86
CLIB.REL.201 26 22-Jul-86
CLIB.REL.202 26 22-Jul-86
CLIB.REL.203 26 22-Jul-86
CLIB.REL.204 26 22-Jul-86
CLIB.REL.210 56 22-Jul-86
CLIB.REL.212 56 22-Jul-86
CLIB.REL.215 56 22-Jul-86
CLIB.REL.216 56 17-Jul-86
CLIB.REL.221 56 24-Jul-86
CLIB.REL.224 57 25-Jul-86
CLIB.REL.225 58 25-Jul-86
CLIB.REL.226 59 31-Jul-86
CLIB.SIERRA.127 25 22-Jul-86
CTYPE.H.5 1 27-Jul-86
CTYPE.H.8 2 31-Jul-86
CURSES.H.4 2 31-Jul-86
ERRNO.H.1 1 31-Jul-86
ERRNO.H.2 2 16-Dec-85
ERRNO.H.3 2 31-Jul-86
FCNTL.H.1 1 26-Jun-87
JSYS.H.34 2 30-Jul-86
JSYS.H.35 2 30-Jul-86
LIBCUR.REL.1 42 22-Jul-86
LIBTRM.REL.3 4 22-Jul-86
MATH.H.3 1 31-Jul-86
NETDB.H.1 1 25-Jul-86
PWD.H.5 1 22-Jul-86
REGEX.H.3 2 22-Jul-86
SETJMP.H.3 1 31-Jul-86
SGTTY.H.1 1 20-May-87
SIGNAL.H.3 1 31-Jul-86
SIGNAL.H.6 2 31-Jul-86
STAB.H.1 1 22-Jul-86
STDIO.H.6 1 14-Jun-86
STDIO.H.9 2 24-Jul-86
STDIO.H.11 2 25-Jul-86
STDIO.H.12 2 31-Jul-86
STRING.H.1 1 9-Dec-87
STRINGS.H.1 1 31-Jul-86
STRINGS.H.2 1 31-Jul-86
SYSITS.H.2 1 22-Jul-86
TERMCAP..1 48 22-Jul-86
TYPES.H.1 1 31-Jul-86
UIO.H.35 1 29-Jul-86
UPARM.H.1 1 31-Jul-86
URTIO.H.1 1 7-May-86
URTIO.H.3 1 27-Feb-86
URTIO.H.4 1 7-May-86
URTIO.H.21 1 22-Jul-86
UTMP.H.1 1 22-Jul-86
VARARGS.H.4 1 31-Jul-86
WHOAMI.H.2 1 30-Jul-86
YACCPAR..1 2 19-Jun-86
Total of 919 pages in 68 files.
12-Aug-88 16:23:11-PDT,715;000000000000
Mail-From: KLH created at 12-Aug-88 16:23:08
Date: Fri, 12 Aug 88 16:23:08 PDT
From: Ken Harrenstien <[email protected]>
Subject: SUN/BSD compiler oddities
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Just posting this in case anyone else encounters similar problems. The
C compilers that come with the SUN and VAX will barf on:
(1) #elif
(2) #error
(3) #if when the expression contains a function-like macro.
Plain macros are OK but anything like foo() or foo(a) causes
an immediate "syntax error".
As we continue porting stuff from the KCC/T20 environment, other coding
problems will certainly come up. Feel free to post them too.
-------
15-Aug-88 13:41:27-PDT,482;000000000000
Mail-From: TODD created at 15-Aug-88 13:41:17
Date: Mon, 15 Aug 88 13:41:16 PDT
From: Todd Koumrian <[email protected]>
Subject: Anyone have int to octal
To: [email protected]
Location: SRI-International Room EJ286, Phone: (415)859-2774
Message-ID: <[email protected]>
Does anyone have an int-to-oct function handy (argument and result are
both of type int)? My attempts are failing to navigate the various
type conversions occurring.
Todd
-------
15-Aug-88 14:29:53-PDT,531;000000000000
Mail-From: KLH created at 15-Aug-88 14:29:41
Date: Mon, 15 Aug 88 14:29:39 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: Anyone have int to octal
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Huh? What do you mean by type "oct"? When you say that "arg and result are
both of type int" it sounds like you want something like this:
#define intooct(a) (a)
which is silly of course.
-------
15-Aug-88 15:38:10-PDT,512;000000000000
Mail-From: TODD created at 15-Aug-88 15:38:05
Date: Mon, 15 Aug 88 15:38:05 PDT
From: Todd Koumrian <[email protected]>
Subject: Re: Anyone have int to octal
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Location: SRI-International Room EJ286, Phone: (415)859-2774
Message-ID: <[email protected]>
Nevermind. Harry supplied a rediculously simple solution I hadn't
thought of. Namely sprintf'ing my int with the %o spec.
Todd
-------
31-Aug-88 15:13:49-PDT,1570;000000000000
Mail-From: IAN created at 31-Aug-88 15:13:40
Date: Wed, 31 Aug 88 15:13:40 PDT
From: Ian Macky <[email protected]>
Subject: DB programmers take heed!!
To: [email protected]
Message-ID: <[email protected]>
When you write DB code, you should NEVER use the internal magic item#s in
a static way. That is, a header file that says #define htype 1 is a gross
and evil sin!
Mary just came to me wanting to know how to renumber an item in a database.
Why? Because the TABLE program uses magic numbers which were incorrect for
the new little DB that she was trying to apply it to.
The CORRECT way to refer to DB items is by name: after loading the db, you
should run down your list of items-that-will-be-needed, look them up BY
NAME, and THEN use the resulting magic number.
Truly, this requires the names be the same, but there are always synonyms,
and a "phone" is a "phone" is a "phone", most likely.
That erroneous code should really be re-written, but I fear that the same
mistake has been made in a LOT of other code as well. After all, it's
the easy way out.
Somewhere there exists a header file of ID item numbers. That file should
be deleted, and programs that break when they can't find it can then be
fixed as needed.
The fix is easy: a structure at the beginning of the program, and a single
routine to do the lookups (written once, and then replicated forever
after)... the actual program code itself remains the same.
Mary's problem is EXACTLY why magic numbers are a crime...
--mumble ian
-------
31-Aug-88 15:15:56-PDT,485;000000000000
Mail-From: KLH created at 31-Aug-88 15:15:50
Date: Wed, 31 Aug 88 15:15:50 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: DB programmers take heed!!
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
True, with one exception. Item 0 is always a unique record identifier; whether
it is called the "Handle" or "NACC" or anything else doesn't matter.
-------
31-Aug-88 16:05:02-PDT,1056;000000000000
Mail-From: SKAHN created at 31-Aug-88 15:58:05
Date: Wed, 31 Aug 88 15:58:05 PDT
From: Susan Kahn <[email protected]>
Subject: [Susan Kahn <[email protected]>: Re: DB programmers take heed!!]
To: [email protected]
Message-ID: <[email protected]>
Mail-From: SKAHN created at 31-Aug-88 15:20:02
Date: Wed, 31 Aug 88 15:20:01 PDT
From: Susan Kahn <[email protected]>
Subject: Re: DB programmers take heed!!
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Yes. This criminal code exists in most of our programs. In most cases, this
has not caused any problems (which is NOT to imply that it is not criminal
none-the-less) because the programs are so specific for a particular database.
The LABEL program is an exception because it has the potential to be useful
for a variety of databases. By the way, Ken, this is the change to the LABEL
program that I was talking about in my earlier message.
Susan
-------
-------
31-Aug-88 16:17:41-PDT,454;000000000000
Mail-From: SKAHN created at 31-Aug-88 16:15:15
Date: Wed, 31 Aug 88 16:15:15 PDT
From: Susan Kahn <[email protected]>
Subject: warning: enumeration type clash
To: [email protected]
Message-ID: <[email protected]>
I vaguely remember a message about this warning message from the C compiler
on the SUN. It is not produced when the same program is compiled on the
TOPS-20. Why is this? And, can I ignore it?
Susan
-------
31-Aug-88 16:24:37-PDT,613;000000000001
Mail-From: KLH created at 31-Aug-88 16:22:27
Date: Wed, 31 Aug 88 16:22:27 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: warning: enumeration type clash
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
You can ignore it. See H&S 5.5 for an overview of enum types. The
SUN and BSD compilers date from a time when enum type checking was considered
a good thing. You can get rid of the warning messages by doing explicit
casts to (int) whenever you use an enum value.
-------
2-Sep-88 13:21:04-PDT,647;000000000001
Mail-From: KLH created at 2-Sep-88 13:20:56
Date: Fri, 2 Sep 88 13:20:56 PDT
From: Ken Harrenstien <[email protected]>
Subject: Another SUN bugaboo
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
Beware of using "toupper" and "tolower" (as per H&S 14.9). The BSD/SUN
C is one of those non-conformant implementations where toupper craps
out if given an argument that isn't a lowercase letter, and vice versa
for tolower. Thus you have to do "if (islower(c)) c = toupper(c);".
KCC of course does it right, but that doesn't help us with programs that
have to run on both systems.
-------
3-Sep-88 22:44:24-PDT,463;000000000001
Mail-From: TODD created at 3-Sep-88 22:44:20
Date: Sat, 3 Sep 88 22:44:19 PDT
From: Todd Koumrian <[email protected]>
Subject: Unix strstr()?
To: [email protected]
Location: SRI-International Room EJ286, Phone: (415)859-2774
Message-ID: <[email protected]>
Anyone want to code up a strstr() and maybe strSTR() for the Unixes?
Certainly would be helpful. Or would strstr() go against the intended
portability goals?
Todd
-------
4-Sep-88 09:57:31-PDT,360;000000000000
Mail-From: IAN created at 4-Sep-88 09:57:28
Date: Sun, 4 Sep 88 09:57:27 PDT
From: Ian Macky <[email protected]>
Subject: Re: Unix strstr()?
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
There is already a strSTR() in the strung library.
--ian
-------
4-Sep-88 11:01:01-PDT,552;000000000001
Mail-From: TODD created at 4-Sep-88 11:00:57
Date: Sun, 4 Sep 88 11:00:57 PDT
From: Todd Koumrian <[email protected]>
Subject: Re: Unix strstr()?
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Location: SRI-International Room EJ286, Phone: (415)859-2774
Message-ID: <[email protected]>
Ok, I see what you mean. I found it on the suns, (find was worthless),
but I can't find it on BJ, which was where I was trying to compile.
Could we have strung.h on BJ too?
Todd
-------
20-Sep-88 16:37:12-PDT,984;000000000000
Mail-From: MIMI created at 20-Sep-88 16:37:08
Date: Tue, 20 Sep 88 16:37:07 PDT
From: Mimi Recker <[email protected]>
Subject: rename()
To: [email protected], [email protected]
Message-ID: <[email protected]>
I have a routine which renames a temp file to the MAILB: directory, as in:
sprintf(str, "%s%s", logical, mailfile);
if (rename(mailfile, str) != 0) { /* rename to mailb directory */
fprintf(stderr, "?MAILDONE: Rename of '%s' to '%s' fails: %s\n", mailfile, str, strerror(-1));
exit(0);
}
}
Executing the program accross one device causes no errors. When I execute
the program using a file on another device, I get the error:
12:37:09 USER ?MAILDONE: Rename of '^V[--queued-bulk-mail--^V].new-notify-590787412' to 'MAILB:^V[--queued-bulk-mail--^V].new-notify-590787412' fails: Files are not on same device
I'd like the program to be able to bouild temp files on other devices.
Any suggestions?
-------
20-Sep-88 16:47:58-PDT,493;000000000000
Mail-From: MKL created at 20-Sep-88 16:47:35
Date: Tue, 20 Sep 88 16:47:35 PDT
From: Mark Lottor <[email protected]>
Subject: Re: rename()
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
The jsys call to rename only renames on the same structure. The EXEC
command rename does a COPY if they are on different structures.
You'll have to do a file copy if you want it to work right.
-------
20-Sep-88 16:48:37-PDT,1128;000000000000
Mail-From: KLH created at 20-Sep-88 16:48:11
Date: Tue, 20 Sep 88 16:48:10 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: rename()
To: [email protected], [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Yes, there are two options:
(1) Don't use rename(). Copy the file instead.
(2) Write the original file to the destination directory in the
first place. Naturally you have to ensure that this temporary name
is also (a) unique, and (b) ignored by the mailer.
The latter option is preferable (apart from efficiency considerations)
because the program might crash during the file copy, whereas rename() is
an atomic operation. If there are problems with aspect (b) then the
mailer needs to be fixed.
Note that rename() doesn't work on Unix either when you are trying to
rename a file across a disk structure. And it's considerably harder to
figure out on Unix if you're about to do something like that, since you
can mount a filesystem anywhere in the logical root tree.
-------
23-Sep-88 09:35:06-PDT,789;000000000000
Mail-From: FRED created at 23-Sep-88 09:35:01
Date: Fri, 23 Sep 88 09:35:01 PDT
From: Fred Ostapik <[email protected]>
Subject: Sun hotline
To: [email protected]
Message-ID: <[email protected]>
In case you missed the lastest Sun-Spots, the following is excerpted
for your info. I haven't tried it so I can't vouch for the responsiveness
or the quality of any replies to submitted queries.
Date: Wed 14 Sep 88 06:54:38-PDT
From: [email protected]
Subject: SUN hotline
> The next time you have to justify the net to your boss, tell him/her about
> sun!hotline.
Can anyone translate this into an address reachable from ARPA or MILNET?
Thanks, Mike
[email protected]
[[ Internet address: "[email protected]" --wnl ]]
-------
23-Sep-88 15:12:26-PDT,893;000000000000
Mail-From: KLH created at 23-Sep-88 15:12:21
Date: Fri, 23 Sep 88 15:12:21 PDT
From: Ken Harrenstien <[email protected]>
Subject: ANSI C standard questions?
To: [email protected]
Message-ID: <[email protected]>
Next week I'll be at the X3J11 (dpANS C) committee meeting in
Sunnyvale. If you have any questions about what they're doing or
about specific points in C, now is a good time to ask because if I
can't answer them I can pass them on.
The outlook isn't as good for feature suggestions since they consider
things to be just about done and are not willing to entertain new
ideas at this point. Problems with already-incorporated new ideas are
more likely to get a hearing.
Unfortunately I don't have an extra copy of the latest draft, but the
ANSI sections of H&S II and K&R II should give you a good enough picture
of what it looks like.
-------
28-Sep-88 12:12:58-PDT,2722;000000000000
Date: 26 Sep 1988 0743:37-PDT
From: [email protected]
Subject: File(s) not accessed since 3-Jun-88
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<C.INCLUDE>
Pages Date
A.OUT.H.1 2 26-Jun-87
AR.H.1 1 31-Jul-86
ASSERT.H.1 1 31-Jul-86
BINTTY.H.2 1 31-Jul-86
C-ENV.H.8 2 27-Jul-86
C-ENV.H.9 2 25-Mar-88
C-H10X.FAI.7 2 26-Apr-88
C-HDR.FAI.17 1 22-Jul-86
C-HDR.FAI.18 1 26-Apr-88
CC.DOC.48 19 28-Jul-86
CC.DOC.49 20 28-Jul-86
CC.DOC.50 20 28-Jul-86
CC.DOC.51 20 30-Jul-86
CC.DOC.52 20 28-Feb-88
CLB10X.REL.3 33 22-Nov-86
CLIB.REL.18 25 22-Jul-86
CLIB.REL.200 26 22-Jul-86
CLIB.REL.201 26 22-Jul-86
CLIB.REL.202 26 22-Jul-86
CLIB.REL.203 26 22-Jul-86
CLIB.REL.204 26 22-Jul-86
CLIB.REL.210 56 22-Jul-86
CLIB.REL.212 56 22-Jul-86
CLIB.REL.215 56 22-Jul-86
CLIB.REL.216 56 17-Jul-86
CLIB.REL.221 56 24-Jul-86
CLIB.REL.224 57 25-Jul-86
CLIB.REL.225 58 25-Jul-86
CLIB.REL.226 59 31-Jul-86
CLIB.SIERRA.127 25 22-Jul-86
CTYPE.H.5 1 27-Jul-86
CTYPE.H.8 2 31-Jul-86
CURSES.H.4 2 31-Jul-86
ERRNO.H.1 1 31-Jul-86
ERRNO.H.2 2 16-Dec-85
ERRNO.H.3 2 31-Jul-86
FCNTL.H.1 1 26-Jun-87
JSYS.H.34 2 30-Jul-86
JSYS.H.35 2 30-Jul-86
LIBCUR.REL.1 42 22-Jul-86
LIBTRM.REL.3 4 22-Jul-86
MATH.H.3 1 31-Jul-86
NETDB.H.1 1 25-Jul-86
PWD.H.5 1 22-Jul-86
REGEX.H.3 2 22-Jul-86
SETJMP.H.3 1 31-Jul-86
SGTTY.H.1 1 20-May-87
SIGNAL.H.3 1 31-Jul-86
SIGNAL.H.6 2 31-Jul-86
STAB.H.1 1 22-Jul-86
STDIO.H.6 1 14-Jun-86
STDIO.H.9 2 24-Jul-86
STDIO.H.11 2 25-Jul-86
STDIO.H.12 2 31-Jul-86
STRING.H.1 1 9-Dec-87
STRINGS.H.1 1 31-Jul-86
STRINGS.H.2 1 31-Jul-86
SYSITS.H.2 1 22-Jul-86
TERMCAP..1 48 22-Jul-86
TYPES.H.1 1 31-Jul-86
UIO.H.35 1 29-Jul-86
UPARM.H.1 1 31-Jul-86
URTIO.H.1 1 7-May-86
URTIO.H.3 1 27-Feb-86
URTIO.H.4 1 7-May-86
URTIO.H.21 1 22-Jul-86
UTMP.H.1 1 22-Jul-86
VARARGS.H.4 1 31-Jul-86
WHOAMI.H.2 1 30-Jul-86
YACCPAR..1 2 19-Jun-86
Total of 922 pages in 70 files.
6-Oct-88 18:42:08-PDT,389;000000000000
Mail-From: KLH created at 6-Oct-88 18:42:05
Date: Thu, 6 Oct 88 18:42:04 PDT
From: Ken Harrenstien <[email protected]>
Subject: X3J11 trip report
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I sent something about this meeting to the trip-reports bboard.
No specific changes to report, just thought you would be interested.
-------
24-Oct-88 13:45:06-PDT,2763;000000000000
Mail-From: FMC created at 24-Oct-88 06:33:10
Date: 24 Oct 1988 0633:10-PDT
From: [email protected]
Subject: File(s) not accessed since 1-Jul-88
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<C.INCLUDE>
Pages Date
A.OUT.H.1 2 26-Jun-87
AR.H.1 1 31-Jul-86
ASSERT.H.1 1 31-Jul-86
BINTTY.H.2 1 31-Jul-86
C-ENV.H.8 2 27-Jul-86
C-ENV.H.9 2 25-Mar-88
C-H10X.FAI.7 2 26-Apr-88
C-HDR.FAI.17 1 22-Jul-86
C-HDR.FAI.18 1 26-Apr-88
CC.DOC.48 19 28-Jul-86
CC.DOC.49 20 28-Jul-86
CC.DOC.50 20 28-Jul-86
CC.DOC.51 20 30-Jul-86
CC.DOC.52 20 28-Feb-88
CLB10X.REL.3 33 22-Nov-86
CLIB.REL.18 25 22-Jul-86
CLIB.REL.200 26 22-Jul-86
CLIB.REL.201 26 22-Jul-86
CLIB.REL.202 26 22-Jul-86
CLIB.REL.203 26 22-Jul-86
CLIB.REL.204 26 22-Jul-86
CLIB.REL.210 56 22-Jul-86
CLIB.REL.212 56 22-Jul-86
CLIB.REL.215 56 22-Jul-86
CLIB.REL.216 56 17-Jul-86
CLIB.REL.221 56 24-Jul-86
CLIB.REL.224 57 25-Jul-86
CLIB.REL.225 58 25-Jul-86
CLIB.REL.226 59 31-Jul-86
CLIB.SIERRA.127 25 22-Jul-86
CTYPE.H.5 1 27-Jul-86
CTYPE.H.8 2 31-Jul-86
CURSES.H.4 2 31-Jul-86
ERRNO.H.1 1 31-Jul-86
ERRNO.H.2 2 16-Dec-85
ERRNO.H.3 2 31-Jul-86
FCNTL.H.1 1 26-Jun-87
JSYS.H.34 2 30-Jul-86
JSYS.H.35 2 30-Jul-86
LIBCUR.REL.1 42 22-Jul-86
LIBTRM.REL.3 4 22-Jul-86
MATH.H.3 1 31-Jul-86
NETDB.H.1 1 25-Jul-86
PWD.H.5 1 22-Jul-86
REGEX.H.3 2 22-Jul-86
SETJMP.H.3 1 31-Jul-86
SGTTY.H.1 1 20-May-87
SIGNAL.H.3 1 31-Jul-86
SIGNAL.H.6 2 31-Jul-86
STAB.H.1 1 22-Jul-86
STDIO.H.6 1 14-Jun-86
STDIO.H.9 2 24-Jul-86
STDIO.H.11 2 25-Jul-86
STDIO.H.12 2 31-Jul-86
STRING.H.1 1 9-Dec-87
STRINGS.H.1 1 31-Jul-86
STRINGS.H.2 1 31-Jul-86
SYSITS.H.2 1 22-Jul-86
TERMCAP..1 48 22-Jul-86
TYPES.H.1 1 31-Jul-86
UIO.H.35 1 29-Jul-86
UPARM.H.1 1 31-Jul-86
URTIO.H.1 1 7-May-86
URTIO.H.3 1 27-Feb-86
URTIO.H.4 1 7-May-86
URTIO.H.21 1 22-Jul-86
UTMP.H.1 1 22-Jul-86
VARARGS.H.4 1 31-Jul-86
WHOAMI.H.2 1 30-Jul-86
YACCPAR..1 2 19-Jun-86
Total of 922 pages in 70 files.
9-Nov-88 17:40:37-PST,1298;000000000001
Mail-From: TODD created at 9-Nov-88 17:40:33
Date: Wed, 9 Nov 88 17:40:33 PST
From: Todd Koumrian <[email protected]>
Subject: _openw?
To: [email protected]
Location: SRI-International Room EJ274, Phone: (415)859-5905
Message-ID: <[email protected]>
Mmm. I've got a C program which was ported (ungracefully) to TOPS-20
in early 1986. The culprits are BILLW and KOLK. Their code contains
the functions _openw, _nextw, and _namew, which are unknown to me.
Interestingly, KCC only objects to _openw, but neither of the others.
Further, IDDT examination of the resulting code shows that there are
indeed routines named .NEXTW and .NAMEW, though I thought it strange
that they came just before MAIN.
The C code is uncommented, of course, and I'm only able to tell that
I think these functions may have something to do with looking at filename
strings straight out of the directory, but I really don't know.
Does anyone know what these functions are? They certainly weren't mentioned
in any of the include files. The linker gave me 2 of them, but I still
need the third. How might I be able to get it?
The code fragment is too long for the purposes of this message, but I can
send it out to anyone who might need more information.
Todd
-------
10-Nov-88 15:57:53-PST,763;000000000000
Mail-From: KLH created at 10-Nov-88 15:57:47
Date: Thu, 10 Nov 88 15:57:47 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: _openw?
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Those are functions having to do with wild-card filenames. They are
internal to the KCC implementation and user programs shouldn't be calling
them. This is true for anything starting with "_"; those names are
always reserved for the C implementation. I suspect that program dates
from a time before we took over KCC development, and it may be unportable
in some other ways as well. If you want more help, tell me where the
program is.
-------
21-Nov-88 23:57:45-PST,509;000000000000
Mail-From: IAN created at 21-Nov-88 23:57:44
Date: Mon, 21 Nov 88 23:57:43 PST
From: Ian Macky <[email protected]>
Subject: NICPROG:PROG-7935.MAP
To: [email protected]
Message-ID: <[email protected]>
I went over this file and updated the stuff that had to do with me. Everyone
else is encouraged to do same...
It looks like this file and PROG.MAP need to be merged? Who is responsible
for this now that mimi isn't around much? If noone else is, I volunteer...
--ian
-------
22-Nov-88 00:02:21-PST,390;000000000000
Mail-From: MIMI created at 22-Nov-88 00:01:40
Date: Tue, 22 Nov 88 00:01:40 PST
From: Mimi Recker <[email protected]>
Subject: Re: NICPROG:PROG-7935.MAP
To: [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
I believe nicprog:prog.map is obsolete.
prog-7935.map is the official list.
-------
25-Nov-88 18:03:22-PST,1518;000000000000
Date: 24 Nov 1988 1319:00-PST
From: [email protected]
Subject: File(s) not accessed since 1-Aug-88
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<C.INCLUDE>
Pages Date
C-ENV.H.8 2 27-Jul-86
C-HDR.FAI.17 1 22-Jul-86
CC.DOC.48 19 28-Jul-86
CC.DOC.49 20 28-Jul-86
CC.DOC.50 20 28-Jul-86
CC.DOC.51 20 30-Jul-86
CLIB.REL.18 25 22-Jul-86
CLIB.REL.200 26 22-Jul-86
CLIB.REL.201 26 22-Jul-86
CLIB.REL.202 26 22-Jul-86
CLIB.REL.203 26 22-Jul-86
CLIB.REL.204 26 22-Jul-86
CLIB.REL.210 56 22-Jul-86
CLIB.REL.212 56 22-Jul-86
CLIB.REL.215 56 22-Jul-86
CLIB.REL.216 56 17-Jul-86
CLIB.REL.221 56 24-Jul-86
CLIB.REL.224 57 25-Jul-86
CLIB.REL.225 58 25-Jul-86
CTYPE.H.5 1 27-Jul-86
ERRNO.H.1 1 31-Jul-86
ERRNO.H.2 2 16-Dec-85
JSYS.H.34 2 30-Jul-86
SIGNAL.H.3 1 31-Jul-86
STDIO.H.6 1 14-Jun-86
STDIO.H.9 2 24-Jul-86
STDIO.H.11 2 25-Jul-86
STRINGS.H.1 1 31-Jul-86
URTIO.H.1 1 7-May-86
URTIO.H.3 1 27-Feb-86
URTIO.H.4 1 7-May-86
Total of 648 pages in 31 files.
30-Nov-88 11:47:28-PST,746;000000000000
Mail-From: IAN created at 30-Nov-88 11:47:23
Date: Wed, 30 Nov 88 11:47:23 PST
From: Ian Macky <[email protected]>
Subject: sscanf feature i didn't know about
To: [email protected]
Message-ID: <[email protected]>
I just discovered (in someone elses code) a scanf feature that i thought was
sorely needed but actually was already available:
you can, in the format string, specify something like "%.*s" which means
you want to read a string, but it reads TWO args; the first is the precision
and the second is the string pointer.
in this way, you can specify the max field width which sscanf will slurp
as an arg, instead of having to build a format string manually, etc.
does that make sense?
--ian
-------
30-Nov-88 12:19:12-PST,451;000000000000
Mail-From: KLH created at 30-Nov-88 12:18:44
Date: Wed, 30 Nov 88 12:18:44 PST
From: Ken Harrenstien <[email protected]>
Subject: Re: sscanf feature i didn't know about
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
The same syntax exists in printf, by the way. You can dynamically
specify how large your field should be.
-------
24-Jan-89 10:19:40-PST,1559;000000000000
Mail-From: FMC created at 24-Jan-89 06:29:05
Date: 24 Jan 1989 0629:05-PST
From: [email protected]
Subject: File(s) not accessed since 1-Oct-88
To: seers
The following file(s) have not been accessed since the date mentioned
above. They will be archived if you do not access them. If you no longer
need them please delete them. Type HELP ARCHIVE to the EXEC for information
about the archive system. HELP EXCEPTED will show the list of directories
on the forced archive exception list.
PS:<C.INCLUDE>
Pages Date
C-ENV.H.8 2 27-Jul-86
C-HDR.FAI.17 1 22-Jul-86
CC.DOC.48 19 28-Jul-86
CC.DOC.49 20 28-Jul-86
CC.DOC.50 20 28-Jul-86
CC.DOC.51 20 30-Jul-86
CLIB.REL.18 25 22-Jul-86
CLIB.REL.200 26 22-Jul-86
CLIB.REL.201 26 22-Jul-86
CLIB.REL.202 26 22-Jul-86
CLIB.REL.203 26 22-Jul-86
CLIB.REL.204 26 22-Jul-86
CLIB.REL.210 56 22-Jul-86
CLIB.REL.212 56 22-Jul-86
CLIB.REL.215 56 22-Jul-86
CLIB.REL.216 56 17-Jul-86
CLIB.REL.221 56 24-Jul-86
CLIB.REL.224 57 25-Jul-86
CLIB.REL.225 58 25-Jul-86
CTYPE.H.5 1 27-Jul-86
ERRNO.H.1 1 31-Jul-86
ERRNO.H.2 2 16-Dec-85
JSYS.H.34 2 30-Jul-86
SIGNAL.H.3 1 31-Jul-86
STDIO.H.6 1 14-Jun-86
STDIO.H.9 2 24-Jul-86
STDIO.H.11 2 25-Jul-86
STRINGS.H.1 1 31-Jul-86
URTIO.H.1 1 7-May-86
URTIO.H.3 1 27-Feb-86
URTIO.H.4 1 7-May-86
Total of 648 pages in 31 files.
21-Feb-89 18:18:37-PST,381;000000000000
Date: 21 Feb 1989 1815:44-PST
From: [email protected]
Subject: Expunged Archive File(s)
To: seers
The Following Archived File(s) have been Expunged:
PS:<KCC-0.INCLUDE>C-HDR.FAI.18 Tape 1:121,2,2045 Tape 2:122,2,2045
PS:<KCC-0.INCLUDE>C-H10X.FAI.7 Tape 1:121,2,2044 Tape 2:122,2,2044
PS:<KCC-0.INCLUDE>C-ENV.H.9 Tape 1:121,2,2043 Tape 2:122,2,2043