Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_FS_1_19910112
-
c/x3j11/request.mail
There is 1 other file named request.mail in the archive. Click here to see a list.
15-Jun-89 17:46:16-PDT,1265;000000000000
Return-Path: <[email protected]>
Received: from SMOKE.BRL.MIL by SRI-NIC.ARPA with TCP; Thu, 15 Jun 89 17:45:58 PDT
Date: Thu, 15 Jun 89 20:10:18 EDT
From: BRL Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa08384)
To: [email protected]
Message-ID: <[email protected]>
After 3 days (70 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 8 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
[email protected] (host: vgr.brl.mil) (queue: brlnet)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from SRI-NIC.ARPA by SMOKE.BRL.MIL id aa08384; 12 Jun 89 21:16 EDT
Date: Mon, 12 Jun 89 12:15:53 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: X3J11 mailing list.
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Hi... I'm not sure, but I'll check and let you know.
-------
...
15-Jun-89 17:57:37-PDT,1758;000000000000
Return-Path: <[email protected]>
Received: from SMOKE.BRL.MIL by SRI-NIC.ARPA with TCP; Thu, 15 Jun 89 17:57:27 PDT
Date: Thu, 15 Jun 89 20:10:22 EDT
From: BRL Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa06081)
To: [email protected]
Message-ID: <[email protected]>
After 4 days (73 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 8 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
[email protected] (host: vgr.brl.mil) (queue: brlnet)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from SRI-NIC.ARPA by SMOKE.BRL.MIL id aa06081; 12 Jun 89 18:26 EDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Mon, 12 Jun 89 09:49:37 PDT
Received: from hp4nl.nluug.nl by uunet.uu.net (5.61/1.14) with SMTP
id AA13784; Mon, 12 Jun 89 12:49:16 -0400
Received: from star.cs.vu.nl by hp4nl.nluug.nl with SMTP
id AA13491 (5.58.1.14/2.14); Mon, 12 Jun 89 16:00:41 MET
Received: from tornado.cs.vu.nl by star.cs.vu.nl id aa22105;
12 Jun 89 16:01 MET DST
Received: from pequod.cs.vu.nl by tornado.cs.vu.nl id aa00609;
12 Jun 89 16:01 MET DST
Date: Mon, 12 Jun 89 16:01:09 MET DST
From: Keizer E G <[email protected]>
To: [email protected]
Subject: X3J11 mailing list.
Message-Id: <[email protected]>
Hello, I received your confirmation of my message of few months back.
I duly sent back the confirmation you asked me for.
...
15-Jun-89 23:07:06-PDT,1830;000000000000
Date: Thu, 15 Jun 89 23:06:46 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 5-Jun-89 15:18:51
Message undeliverable and dequeued after 10 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Mon, 5 Jun 89 15:04:05 PDT
Received: from stellar.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA03670; Mon, 5 Jun 89 15:25:28 -0400
Received: from capricorn.stellar.COM
by stellar.Stellar.COM (4.0/smail2.5/01-28-89)
id AA06998; Mon, 5 Jun 89 15:17:53 EDT
Received: by capricorn.stellar.COM (4.0/SMI-3.2)
id AA02260; Mon, 5 Jun 89 15:17:51 EDT
From: [email protected] (Peter Darnell @stellar)
Message-Id: <[email protected]>
To: Ken Harrenstien <[email protected]>
Cc: [email protected]
Subject: ANSI request for clarification.
Date: Mon, 05 Jun 89 15:17:49 -0400
There has been much discussion of "Miranda Rules" for function
argument behavior in the absence of prototypes. As I understand it,
a function call can be thought of as causing a prototype
to be built that corresponds to widened actual argument types. What
has been implied in non-ANSI literature is that the "Miranda" prototype is
constructed for the initial reference and retained for the rest of the
file.
My understanding of ANSI function prototyping is that, for
non-prototyped functions, a prototype is constructed anew for each function call.
This is actually a request from Larry Rosenthal who doesn not have
access to this mailing list.
Thanks,
Pete Darnell
-------
16-Jun-89 07:49:09-PDT,2482;000000000000
Date: Fri, 16 Jun 89 07:46:57 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 7-Jun-89 12:30:21
Message undeliverable and dequeued after 8 days:
[email protected]: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Wed, 7 Jun 89 12:29:45 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA26895; Wed, 7 Jun 89 15:30:06 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-051
Date: Wed Jun 7 07:59:54 1989
.X3 89-051 "Administrative notices" "06 Jun 89"
.LP
Jim Brodie, P J Plauger, and I are still trying to determine the
exact state of affairs with our X3 approval.
We have finally decided to send out this mailing without
a full status report;
that will have to wait for another mailing soon.
.LP
Very briefly, everything is still in the X3 office in Washington.
Our understanding is that Mr Hansberry has asked for a full formal
appeal process.
We will send further information as it becomes available.
.LP
Please do not inundate us with telephone calls asking what
news we have next week.
We are attempting to create a quick-notification network,
and will also send another mailing soon.
.LP
Potentially helpful things for the next stages:
.IP o
If you have not already done so,
please try to obtain access to an e-mail facility that can be
reached through Usenet.
.IP o
If you have information about "portal" services which can connect
Usenet to other existing networks, please telephone me
or send email to [email protected] .
.IP o
If you have a new or changed net-address to report,
please send email to Ken Harrenstien, [email protected] .
.IP o
I would very much appreciate the services of a volunteer to
integrate the ordinary-mail mailing list with the Usenet list.
That is, if every voting member of the committee either
had a net-address, or had someone with a net-address willing
to send quick photocopies,
we would be better prepared for our next phases.
If you can help with this please contact me.
.IP o
If, on the other hand,
you have a net-address but already know that it would be unrealistic
for you to make copies of your mail for a few other members,
please let me know via email.
.LP
Our thanks to everyone who has worked so long and hard on this project.
We will keep you posted.
-------
16-Jun-89 13:14:33-PDT,8563;000000000000
Date: Fri, 16 Jun 89 13:05:23 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 10-Jun-89 18:47:09
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Sat, 10 Jun 89 18:46:44 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA08395; Sat, 10 Jun 89 21:46:35 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-052
Date: Sat Jun 10 21:34:33 1989
BY MY RECORDS, THESE ARE THE VOTING PRINCIPALS (2 OF RECENT 3 MEETINGS).
*** PLEASE CALL OR EMAIL PLUM IF YOU HAVE ANY CHANGES OR ADDITIONS ***
E = has e-mail address registered with [email protected]
I = expressed interest in interpretation phase
S = company was represented at Seattle meeting
X = company is represented on X3
------- "North" Boston -------
M806 Meyers, Randy; Digital Equipment Corp; 110 Spit Brook Rd MS ZK02-3/N30;
## EISX Nashua, NH 03062;; 603-881-2743; [email protected] P-J11
E269 Peyton, John; Apollo Computer; 330 Billerica Rd MS CHF01RD; Chelmsford, MA 01824;
## -I-X 617-256-6600; P-J11
P366 Van Leewwen, Lucy; Concurrent (formerly Masscomp); 1 Technology Pk;
## -I-X Westford, MA 01886; 508-392-2849; A-J11
N213 Brosnan, Kevin; Alliant Computer Systems; 1 Monarch Drive; Littleton, MA 01460;
## -I-X 617-486-1345;; P-J11
8238 Blodgett, Bruce; Honeywell Information Systems; 300 Concord Rd MS MA30/843A;
## -ISX Billerica, MA 01821;; 617-671-2029; P-J11
8249 Rozakis, Fred T; Wang Labs; 1 Industrial Av; Lowell, MA 01851;
## -ISX 508-967-7002;; P-J11
------- "South" Boston --------
4224 Johnson, Andrew; Prime Computer; 500 Old Connecticut Path ; MS 10C17-3;
## EISX Framingham, MA 01701;; 508-879-2960 x4045; [email protected] P-J11
P359 Plauger, P J; 398 Main St; Concord, MA 01742; 508-369-8489; P-J11
## -IS- [email protected] (?)
0156 Colligan, Terry; Rational Systems; 102 Union St; POB 480; Natick, MA 01760;
## ---- 508-653-6006;; P-J11
E989 Hudson, Randy; Intermetrics; 733 Concord Av; Cambridge, MA 02138;
## EIS- 617-661-1840;; [email protected] P-J11
4218 Darnell, Peter; Stellar Computer; 95 Wells Av; Newton, MA 02159;
## EIS- 617-964-1000x260; "stellar!pete"@UCBVAX.BERKELEY.EDU" P-J11
------- NY/NJ -------
H233 Prosser, David; AT&T; 190 River Rd; Summit, NJ 07901; 201-522-6227;
## EISX ; [email protected] P-J11
5049 Plum, Thomas; Plum Hall; 1 Spruce Av; Cardiff, NJ 08232; 808-879-4449;
## EIS- ; [email protected] P-J11
H383 Adamczyk, J Stephen Edison Design Group; 907 Timber Oaks Rd; Edison, NJ 08820;
## --S- 201-769-8262;; [email protected] P-J11
G820 Bordelon, Craig; Bellcore; RRC-1B218; 444 Hoes Lane; Piscataway, NJ 08854;
## -IS- ; 201-699-6732; P-J11
8195 Farance, Frank; Farance Inc; 555 Main St; New York , NY 10044;
## -IS- 212-486-4700; P-J11
------- MD/VA/NC -------
1140 Gwyn, Douglas A; US Army Ballistic Research Lab; ATTN: SLCBR-VL-V;
## EISX Aberdeen Proving Gr, MD 21005;; 301-278-6647; [email protected] P-J11
E235 Williams, James; Naval Research Laboratory; 55 Joyceton Wy; Upper Marlboro, MD 20772;
## E--- 202-767-9035(w);; [email protected] P-J11
B085 Jaeschke, Rex; DEC Professional; 1810 Michael Faraday Dr #101; Reston, VA 22090;
## E-S- ; 703-860-0091; [email protected] P-J11
4226 Meissner, Michael; Data General; 62 Alexander Drive; Research Triangle, NC 22709;
## --S- ; 919-248-6250; [email protected] (?) P-J11
E056 Bradley, Oliver; SAS Institute; SAS Circle; Box 8000; Cary, NC 27512;
## ---- 919-467-8000;; P-J11
------- FL -------
G311 Davies, Steve; Concurrent Computer Corp; 2486 Sand Lake Rd; Orlando, FL 32809;
## E-S- 407-850-1040; [email protected] P-J11
4232 Jeter, Gary; Harris Computer Systems; 2101 W Cypress Creek Rd MS 161;
## -IS- Ft Lauderdale, FL 33309;; 305-973-5230; P-J11
N867 Bennett, Mike; Encore Computers; 6901 W Sunrise Blvd; Ft Lauderdale, FL 33569;
## E-S- ; 305-587-2900x4834; [email protected] P-J11
------- OH -------
1333 Jones, Larry; SDRC; 2000 Eastman Dr; Milford, OH 45150; 513-576-2070;
## EIS- [email protected] P-J11
H817 Mickey, Daniel; Chemical Abstracts Serv; 2540 Olentangy River Rd;
## --S- POB 3012; Columbus, OH 43210;; 614-421-3600; P-J11
M344 Saks, Daniel; Saks & Associates; 287 W McCreight Av; Springfield, OH 45504;
## -IS- 513-324-8669;; P-J11
------- MN/IL -------
5716 MacDonald, Tom; Cray Research; 1345 Northland Dr; Mendota Hts, MN 55120;
## EIS- 612-681-5818;; [email protected] P-J11
H337 Bixler, Don; Unisys; POB 64942 MS WE3B; St Paul, MN 55164; 612-635-2062;
## -ISX P-J11
7259 Ness, Steve; Mark Williams Co; 601 N Skokie Hwy; Lake Bluff, IL 60044;
## ---- 415-821-1235(CA);; P-J11
------- TX/UT/S.CA -------
M878 Terrazas, Mike; DECUS Representative; c/o LDS Church; 50 E North Temple St 27 Fl;
## -ISX Salt Lake City,; UT 84150; 801-531-3246; P-J11
D278 Ohmes, Leonard; Datapoint; 9725 Datapoint Dr #S25; San Antonio, TX 78284;
## --S- 512-699-7336;; P-J11
H234 Khushf, Monika; Tymlabs; 811 Barton Springs Rd #511; Austin, TX 78759;
## -IS- 512-478-0611;; P-J11
4217 Brodie, Jim; J Brodie & Associates; 106 S Terrace; Chandler, AZ 85226;
## --S- 602-863-5462;; P-J11
D306 Schubert, Rick; NCR; 9900 Old Grove Rd; San Diego, CA 92131; 619-693-5717;
## -ISX ; P-J11
------- Greater Bay area -------
N220 Stanberry, Linda; Lawrence Livermore Labs; 7000 East Av; POB 808 L300;
## EISX Livermore, CA 94550;; 415-422-1100; [email protected] P-J11
K425 Rasbold, Chuck; Supercomputer Systems Inc; 1404 Concannon Blvd;
## EIS- Livermore, CA 94550; 415-449-9392;; [email protected] P-J11
8240 Pennello, Tom; Metaware; 903 Pacific Av #201; Santa Cruz, CA 95060;
## ---- 408-429-6382;; P-J11
K220 Jervis, Bob; Borland International; 4585 Scotts Valley Dr; Scotts Valley, CA 95066;
## --S- ; 408-438-8400x460; P-J11
J026 Relph, Richard; EPI; 3707 Williams Rd; San Jose, CA 95117; 408-244-7900;
## --S- P-J11
------- Silicon Valley -------
M149 Crockett, Elizabeth Apple Computers; MS 22-AE; 20525 Mariani Av;
## EISX Cupertino, CA 95014;; 408-974-5084; [email protected] P-J11
N438 Murray, Walter J; Hewlett Packard; 19447 Pruneridge Av; Cupertino, CA 95014;
## EISX 408-447-6129;; [email protected] P-J11
N871 Walcott, Zona; Pyramid Technology; 1295 Charleston Rd; POB 7295;
## EIS- Mountain View, CA 94039; 415-965-7200; [email protected] P-J11P-J11
K375 Meissen, Courtney; Sun Microsystems; MS/1-40; 2550 Garcia Av; Mountain View, CA 94043;
## EISX ; 415-336-7397; [email protected] P-J11
B088 Weidenhofer, Neal; Amdahl; MS 316; 1250 E Arques; Sunnyvale, CA 94088;
## EIS- 408-737-5007;; [email protected] P-J11
H237 Hausman, John M; Tandem Computers; 10555 Ridgeview Court; Cupertino, CA 95014;
## --S- 408-996-6555; P-J11
------- OR/WA -------
4792 Weil, David F; Microsoft; 16011 NE 36 Wy; POB 97017; Redmond, WA 98073;
## EIS- 206-882-8516;; [email protected] P-J11
K915 Sutton, Carl; Tektronix; POB 500 MS 19-333; Beaverton, OR 97077;
## ---- 503-627-7111;; [email protected] P-J11
M708 Nelson, Clark; Intel; 5200 Elam Young Pkwy MS HF280; Hillsboro, OR 97124;
## EIS- ; 503-681-2018; [email protected] P-J11
N403 Ryan, Ralph; Chiron Systems; 14486 NE 58 St; Bellevue, WA 98007;
## EIS- 206-869-0141(W); [email protected] P-J11
------- Ontario -------
5680 Elliott, Shawn; IBM; Dept 31/827; 844 Don Mills Rd; North York, Ontario M3C 1V7;
## E-SX ; CANADA; 416-448-2172; [email protected] P-J11
M146 Fosbury, Don; Control Data; Canadian Development Division; 1855 Minnesota Court;
## --SX ; Mississauga, ON L5N 1K7; CANADA; 416-826-8640x3608; P-J11
D276 Kelly, Thomas; HCR Corporation; 130 Bloor St W; Toronto , Ontario M5S 1N5;
## -IS- CANADA;; 416-922-1937; P-J11
J738 Crigger, Fred; Watcom Systems; 415 Phillip St; Waterloo, Ontario N2L 3X2;
## EIS- CANADA;; 519-886-3700; [email protected] P-J11
-------
16-Jun-89 13:14:38-PDT,667;000000000000
Date: Fri, 16 Jun 89 13:06:02 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 10-Jun-89 20:09:29
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Sat, 10 Jun 89 20:09:18 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA00969; Sat, 10 Jun 89 23:09:05 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected], [email protected], [email protected]
Date: Sat Jun 10 22:52:46 1989
Welcome to XENIX!
-------
16-Jun-89 20:23:44-PDT,765;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Fri, 16 Jun 89 20:23:30 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA27966; Thu, 15 Jun 89 20:11:35 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: addresses
Date: Thu Jun 15 20:09:09 1989
Thanks for "more names" (14 Jun 15:02 PDT).
Here are two new ones, and a change:
Ed Keizer uunet!cs.vu.nl!keie
Jim Blondeau [email protected]
Carl Sutton [email protected]
Thanks for the careful work.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
17-Jun-89 22:09:14-PDT,1325;000000000000
Mail-From: VIVIAN created at 17-Jun-89 22:07:36
Date: Sat, 17 Jun 89 22:07:36 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 12-Jun-89 09:51:34
Message undeliverable and dequeued after 6 days:
[email protected]: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Mon, 12 Jun 89 09:49:37 PDT
Received: from hp4nl.nluug.nl by uunet.uu.net (5.61/1.14) with SMTP
id AA13784; Mon, 12 Jun 89 12:49:16 -0400
Received: from star.cs.vu.nl by hp4nl.nluug.nl with SMTP
id AA13491 (5.58.1.14/2.14); Mon, 12 Jun 89 16:00:41 MET
Received: from tornado.cs.vu.nl by star.cs.vu.nl id aa22105;
12 Jun 89 16:01 MET DST
Received: from pequod.cs.vu.nl by tornado.cs.vu.nl id aa00609;
12 Jun 89 16:01 MET DST
Date: Mon, 12 Jun 89 16:01:09 MET DST
From: Keizer E G <[email protected]>
To: [email protected]
Subject: X3J11 mailing list.
Message-Id: <[email protected]>
Hello, I received your confirmation of my message of few months back.
I duly sent back the confirmation you asked me for.
I never received anything after that first message, although messages
seem to have gone out. At least, that is what Rex Jaeschke tells me.
What happened?
Ed Keizer
-------
17-Jun-89 22:19:16-PDT,660;000000000000
Mail-From: VIVIAN created at 17-Jun-89 22:15:05
Date: Sat, 17 Jun 89 22:15:05 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 12-Jun-89 12:27:28
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Date: Mon, 12 Jun 89 12:15:53 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: X3J11 mailing list.
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Hi... I'm not sure, but I'll check and let you know.
-------
-------
22-Jun-89 10:51:01-PDT,1141;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Thu, 22 Jun 89 10:50:49 PDT
Received: from snail.Sun.COM (snail.Corp.Sun.COM) by Sun.COM (4.1/SMI-4.1)
id AA15718; Thu, 22 Jun 89 10:46:37 PDT
Received: from ringworld.sun.com by snail.Sun.COM (4.1/SMI-4.1)
id AA29873; Thu, 22 Jun 89 10:45:01 PDT
Received: by ringworld.sun.com (4.0/SMI-4.0)
id AA15420; Thu, 22 Jun 89 10:46:47 PDT
Date: Thu, 22 Jun 89 10:46:47 PDT
From: [email protected] (Mike Eager)
Message-Id: <[email protected]>
To: [email protected], [email protected], [email protected], [email protected],
[email protected], [email protected],
[email protected], [email protected], [email protected],
[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected], [email protected], [email protected],
[email protected], [email protected]
Change of address:
Michael J. Eager
Eager Consulting
481 Century Drive
Campbell, CA 95008
(408) 378-8820
UUCP: [email protected] <=== new e-mail address
Thanks,
-- Mike
23-Jun-89 05:27:40-PDT,3226;000000000000
Date: Fri, 23 Jun 89 05:23:25 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 16-Jun-89 13:54:52
Message undeliverable and dequeued after 7 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Fri, 16 Jun 89 13:53:14 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA13949; Thu, 15 Jun 89 16:48:47 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-054
Date: Thu Jun 15 16:45:28 1989
INFORMATION PROCESSING SYSTEMS Doc No: X3J11/89-054
American National Standards Committee Date: 15 Jun 89
Operating under the procedures of the Project: 381-D
American National Standards Institute Ref Doc:
Reply to: Thomas Plum
Status______ of__ X3J11_____ Proposed________ Standard________
The following information comes from telephone conversations with
Marilyn Kornfeld, Manager of Projects and Standards, X3 Secre-
tariat:
In April, Mr Russell Hansberry filed a 27-page appeal to the
X3 Secretariat. The appeal deals with procedural questions
and contains threats of legal actions. The Secretariat's
lawyers have recommended that the Secretariat not send a
copy to X3J11, or at least not yet.
Mr Hansberry appealed the X3 procedure that allowed him only
30 days to file his appeal. A decision was made at the
Secretariat to allow him until 1 July to draft his detailed
appeal.
The operative procedure here is Section 11 (Appeals Procedure) in
X3/SD-2 (Organization and Procedures):
The Secretariat must respond to the appeal within 30 days,
i.e. by 1 August.
If, after that, the appellant and the Secretariat are unable
to resolve the complaint, the Secretariat "shall" [must?]
schedule an three-person appeals panel: one selected by
appellant, one by Secretariat, one jointly. There are no
mandated time limits on the panel selection.
The panel shall render a decision in 30 days. Section 11.5
indicates that further appeals may be made to ANSI.
Plum has communicated the following question to the Secretariat:
What criteria does the Secretariat follow in determining whether
to grant an appeals panel to an appellant?
X3J11 members from organizations with X3 representation will pro-
bably want to discuss this situation with their representative.
Brodie summarized X3J11's position in his cover letter 89-028: Mr
Hansberry received a fair hearing, and the committee did not
adopt any of his proposals.
__________
X3 Secretariat: Computer and Business Equipment Manufacturers Association
311 First Street NW, Suite 500, Washington DC 20001 202/737-8888
- 1 -
-------
23-Jun-89 18:37:24-PDT,1131;000000000000
Return-Path: <[email protected]>
Received: from SMOKE.BRL.MIL by SRI-NIC.ARPA with TCP; Fri, 23 Jun 89 18:37:14 PDT
Date: Fri, 23 Jun 89 20:10:48 EDT
From: BRL Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Failed mail (msg.aa08384)
To: [email protected]
Message-ID: <[email protected]>
After 11 days (262 hours), your message could not be
fully delivered.
It failed to be received by the following address(es):
[email protected] (host: vgr.brl.mil) (queue: brlnet)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message follows:
Received: from SRI-NIC.ARPA by SMOKE.BRL.MIL id aa08384; 12 Jun 89 21:16 EDT
Date: Mon, 12 Jun 89 12:15:53 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: X3J11 mailing list.
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Hi... I'm not sure, but I'll check and let you know.
-------
23-Jun-89 18:37:39-PDT,1796;000000000000
Return-Path: <[email protected]>
Received: from SMOKE.BRL.MIL by SRI-NIC.ARPA with TCP; Fri, 23 Jun 89 18:37:19 PDT
Date: Fri, 23 Jun 89 20:11:32 EDT
From: BRL Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Failed mail (msg.aa06081)
To: [email protected]
Message-ID: <[email protected]>
After 12 days (265 hours), your message could not be
fully delivered.
It failed to be received by the following address(es):
[email protected] (host: vgr.brl.mil) (queue: brlnet)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message follows:
Received: from SRI-NIC.ARPA by SMOKE.BRL.MIL id aa06081; 12 Jun 89 18:26 EDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Mon, 12 Jun 89 09:49:37 PDT
Received: from hp4nl.nluug.nl by uunet.uu.net (5.61/1.14) with SMTP
id AA13784; Mon, 12 Jun 89 12:49:16 -0400
Received: from star.cs.vu.nl by hp4nl.nluug.nl with SMTP
id AA13491 (5.58.1.14/2.14); Mon, 12 Jun 89 16:00:41 MET
Received: from tornado.cs.vu.nl by star.cs.vu.nl id aa22105;
12 Jun 89 16:01 MET DST
Received: from pequod.cs.vu.nl by tornado.cs.vu.nl id aa00609;
12 Jun 89 16:01 MET DST
Date: Mon, 12 Jun 89 16:01:09 MET DST
From: Keizer E G <[email protected]>
To: [email protected]
Subject: X3J11 mailing list.
Message-Id: <[email protected]>
Hello, I received your confirmation of my message of few months back.
I duly sent back the confirmation you asked me for.
I never received anything after that first message, although messages
seem to have gone out. At least, that is what Rex Jaeschke tells me.
What happened?
Ed Keizer
4-Jul-89 19:32:07-PDT,3286;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Tue, 4 Jul 89 19:32:01 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AA26469; Tue, 4 Jul 89 19:31:57 PDT
Date: Tue, 4 Jul 89 19:31:57 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
Connected to ringworld:
>>> RCPT To:<eager@ringworld>
<<< 550 eager@ringworld... User unknown
550 eager@ringworld... User unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA26467; Tue, 4 Jul 89 19:31:57 PDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Tue, 4 Jul 89 19:02:41 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02085; Tue, 4 Jul 89 22:02:07 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-055.1
Date: Tue Jul 4 12:42:19 1989
89-055 PRELIMINARY DRAFT #1
04 Jul 1989
Current status of X3J11 standard
Thomas Plum 609-927-3770 Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
On 29 June, X3 received an 8(?)-page addendum from Russell Hansberry,
adding to the 26-page appeal received previously. Copies of both
documents are being expressed to X3J11 officers, to be received
Wednesday 05 July.
There will be an all-day meeting at the X3 Secretariat Friday 07 July,
with officers from J11, X3, SPARC (Standards Planning and Requirements
Committee), and SMC (Secretariat Management Committee). J11 will be
represented by Plauger (Secretary) and Plum (Vice-Chair). Brodie
(Chair) concurs with this representation.
We have been asked to provide a chronology of J11's interactions with
Hansberry. I believe he makes a claim that he did not receive an
adequate hearing. Therefore, the e-mail distribution of this paper
is accompanied by my rough draft of the chronology (89-056.1). The main
focus is "Who talked with Hansberry, and for how long?".
Three requests:
(1) Please check this chronology for accuracy and completeness; it needs
more details. By noon Thursday (06 July), please e-mail or phone with
any changes for the chronology.
(2) (Referring to 89-052, the list of current voting members) If you
know of someone in your local region, who does not receive e-mail, and
was involved in this chronology, please telephone them to see if they
can add any details.
(3) If your company has X3 representation, please discuss this
upcoming Friday meeting with your X3 representative. If they feel that
it is appropriate, suggest that they telephone any of the X3, SPARC, or
SMC Chair or Vice-Chair people, so that they have some sense of how
their constituents feel about this Hansberry delay.
The officers of J11 believe that an overwhelming consensus of J11
desire that the current Proposed standard should be ratified with the
minimum amount of further delay, and that the officers' responsibility
to the J11 membership is to pursue all legal means to minimize any
further delay. (If you disagree with this assessment, please let me
know.)
4-Jul-89 20:06:31-PDT,3805;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Tue, 4 Jul 89 20:06:24 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AA26686; Tue, 4 Jul 89 19:47:13 PDT
Date: Tue, 4 Jul 89 19:47:13 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
Connected to ringworld:
>>> RCPT To:<eager@ringworld>
<<< 550 eager@ringworld... User unknown
550 eager@ringworld... User unknown
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA26683; Tue, 4 Jul 89 19:47:13 PDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Tue, 4 Jul 89 19:05:14 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA03144; Tue, 4 Jul 89 22:04:51 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-056.1
Date: Tue Jul 4 12:42:28 1989
PRELIMINARY DRAFT - Please e-mail corrections and additions ASAP.
Chronology of X3J11 discussions with Russell Hansberry
Thomas Plum
03 July 1989
Date Duration From / To
Synopsis
1986:
09/__ Letter Russell Hansberry to Rex Jaeschke:
How do I comment to J11?
09/__ Letter Jaeschke to Hansberry:
Send your comments to ANSI BSR and X3 at CBEMA.
1989:
03/06 Letter Hansberry to Jaeschke:
No responses yet, what do I do?
03/__ FAX'es Jaeschke to J11 officers:
We have a problem, letter was lost; FAX'ed copy of his letter.
03/14 18min Jaeschke + Hansberry (206-743-7695):
"I sent your letter to J11 officers." Some technical discussion.
03/21 Letter Hansberry to Jaeschke:
Thanks for your help, some progress.
03/__ 30-45m Hansberry to Tom MacDonald:
Technical. "Most of your points already have been discussed."
03/__ e-mail MacDonald to Dennis Ritchie:
"Should we consider changing precedence?"
03/__ e-mail Ritchie to MacDonald:
"Not at this point in the maturity of C."
03/__ 15-20m MacDonald to Hansberry:
Tried to convince Hansberry to drop his proposals, unlikely
that the committee would have adopted even last year.
03/__ -- Jim Brodie called Hansberry, left message.
03/__ 30-45m Hansberry + Brodie:
Suggest you discuss your points with several C experts on J11.
03/28 25min Jaeschke + Hansberry:
Technical discussion. "Realistic assessment:
very little likelihood of changes at this point."
04/__ ______ P J Plauger to Hansberry:
________
04/03? FAX Hansberry FAX'ed paper to Tom Plum.
04/03? 60-90m Plum to Hansberry:
Technical discussion of points. Committee is willing to
correct errors, but unlikely to make changes on preferences.
04/__ 15-30m Brodie to Hansberry: We will follow procedures and
give you a hearing, but little likelihood. Please consider
withdrawing your proposal.
04/06 Letter Dave Weil FedEx'ed Hansberry the J11 responses to 1st and
2nd public reviews (about 1 1/2 inches of paper), so he could see
that we had been responding to public input, his case was unique.
04/10 60-75m Seattle meeting, morning session. Subgroup:
Full-time: Gwyn, Meissner, Adamski, Ryan.
Part-time: Rosler, Wiedenhofer, ...
04/10 2hr? Afternoon session, subgroup.
04/11 30m? Morning session, subgroup, prepared 3 points for full J11
04/11 45m J11 full committee, discussed 3 points. Votes 31/0,
28/1, 27/3.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
5-Jul-89 09:59:50-PDT,3830;000000000000
Return-Path: <intelhf!medusa!intelhf!uucp%[email protected]>
Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Wed, 5 Jul 89 09:59:36 PDT
Received: from [128.215.97.4] by RELAY.CS.NET id aa22610; 5 Jul 89 12:38 EDT
Return-path: [email protected]
Received: from ihf1.intel.com by sc.intel.com; Wed, 28 Jun 89 17:00 PDT
Received: by ihf1.intel.com (/\=-/\ Smail3.1.4.3 #4.4) id
<[email protected]>; Wed, 28 Jun 89 17:02 PDT
Received: by intelhf.hf.intel.com (smail2.5s1); 28 Jun 89 16:44:40 PDT (Wed)
Received: by medusa.intel.com (/\=-/\ Smail3.1.4.3 #4.3) id
<[email protected]>; Wed, 28 Jun 89 16:40 PDT
Received: by intelhf.hf.intel.com (smail2.5s1); 7 Jun 89 17:13:22 PDT (Wed)
Date: 7 Jun 89 17:13:22 PDT (Wed)
From: intelhf_OpenNET_mailer%[email protected]
Subject: OpenNET mail delivery problem
To: sri-nic.arpa!X3J11-RELAY%[email protected]
Message-Id: <[email protected]>
Trouble sending OpenNET Mail to `langlab1'
============ Transcript follows ============
mail.onet: Network connection broke...data lost
============== Message follows =============
From medusa!sri-nic.arpa!X3J11-RELAY Wed Jun 7 17:13:11 1989 remote from intelhf
Received: by intelhf.hf.intel.com (smail2.5s1); 7 Jun 89 17:13:11 PDT (Wed)
Received: by medusa.intel.com (/\=-/\ Smail3.1.4.3 #4.3)
id <[email protected]>; Wed, 7 Jun 89 17:13 PDT
Return-path: X3J11-RELAY%[email protected]
Received: from SRI-NIC.ARPA by sc.intel.com; Wed, 7 Jun 89 17:15 PDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Wed, 7 Jun 89 12:29:45 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA26895;
Wed, 7 Jun 89 15:30:06 -0400
Date: Wed Jun 7 07:59:54 1989
From: plumhall!plum%[email protected]
Subject: 89-051
To: [email protected]
Message-Id: <[email protected]>
..X3 89-051 "Administrative notices" "06 Jun 89"
..LP
Jim Brodie, P J Plauger, and I are still trying to determine the
exact state of affairs with our X3 approval.
We have finally decided to send out this mailing without
a full status report;
that will have to wait for another mailing soon.
..LP
Very briefly, everything is still in the X3 office in Washington.
Our understanding is that Mr Hansberry has asked for a full formal
appeal process.
We will send further information as it becomes available.
..LP
Please do not inundate us with telephone calls asking what
news we have next week.
We are attempting to create a quick-notification network,
and will also send another mailing soon.
..LP
Potentially helpful things for the next stages:
..IP o
If you have not already done so,
please try to obtain access to an e-mail facility that can be
reached through Usenet.
..IP o
If you have information about "portal" services which can connect
Usenet to other existing networks, please telephone me
or send email to [email protected] .
..IP o
If you have a new or changed net-address to report,
please send email to Ken Harrenstien, [email protected] .
..IP o
I would very much appreciate the services of a volunteer to
integrate the ordinary-mail mailing list with the Usenet list.
That is, if every voting member of the committee either
had a net-address, or had someone with a net-address willing
to send quick photocopies,
we would be better prepared for our next phases.
If you can help with this please contact me.
..IP o
If, on the other hand,
you have a net-address but already know that it would be unrealistic
for you to make copies of your mail for a few other members,
please let me know via email.
..LP
Our thanks to everyone who has worked so long and hard on this project.
We will keep you posted.
5-Jul-89 10:00:55-PDT,10083;000000000000
Return-Path: <intelhf!medusa!intelhf!root%[email protected]>
Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Wed, 5 Jul 89 10:00:22 PDT
Received: from [128.215.97.4] by RELAY.CS.NET id ab22610; 5 Jul 89 12:38 EDT
Return-path: [email protected]
Received: from ihf1.intel.com by sc.intel.com; Wed, 28 Jun 89 17:08 PDT
Received: by ihf1.intel.com (/\=-/\ Smail3.1.4.3 #4.4) id
<[email protected]>; Wed, 28 Jun 89 17:10 PDT
Received: by intelhf.hf.intel.com (smail2.5s1); 28 Jun 89 16:53:30 PDT (Wed)
Received: by medusa.intel.com (/\=-/\ Smail3.1.4.3 #4.3) id
<[email protected]>; Wed, 28 Jun 89 16:44 PDT
Received: by intelhf.hf.intel.com (smail2.5s1); 15 Jun 89 04:40:29 PDT (Thu)
Date: 15 Jun 89 04:40:29 PDT (Thu)
From: intelhf.hf.intel.com!Postmaster%[email protected]
Subject: SWCAD netmail delivery problem
To: sri-nic.arpa!X3J11-RELAY%[email protected]
Message-Id: <[email protected]>
Trouble sending SWCAD Netmail to ' clark ' on 'langlab1':
(NOTE: If there are multiple Transcript sections,
check the last one, as it will be the most
useful to you.)
============ Transcript follows ============
Message in queue more than 24 hours, returning
============== Message follows =============
From medusa!sri-nic.arpa!X3J11-RELAY Wed Jun 14 04:03:48 1989 remote from intelhf
Received: by intelhf.hf.intel.com (smail2.5s1); 14 Jun 89 04:03:48 PDT (Wed)
Received: by medusa.intel.com (/\=-/\ Smail3.1.4.3 #4.3)
id <[email protected]>; Wed, 14 Jun 89 04:02 PDT
Return-path: X3J11-RELAY%[email protected]
Received: from SRI-NIC.ARPA by sc.intel.com; Wed, 14 Jun 89 04:03 PDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Sat, 10 Jun 89 18:46:44
PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA08395;
Sat, 10 Jun 89 21:46:35 -0400
Date: Sat Jun 10 21:34:33 1989
From: plumhall!root%[email protected]
Subject: 89-052
To: voting%[email protected]
Message-Id: <[email protected]>
BY MY RECORDS, THESE ARE THE VOTING PRINCIPALS (2 OF RECENT 3 MEETINGS).
*** PLEASE CALL OR EMAIL PLUM IF YOU HAVE ANY CHANGES OR ADDITIONS ***
E = has e-mail address registered with [email protected]
I = expressed interest in interpretation phase
S = company was represented at Seattle meeting
X = company is represented on X3
------- "North" Boston -------
M806 Meyers, Randy; Digital Equipment Corp; 110 Spit Brook Rd MS ZK02-3/N30;
## EISX Nashua, NH 03062;; 603-881-2743; [email protected] P-J11
E269 Peyton, John; Apollo Computer; 330 Billerica Rd MS CHF01RD; Chelmsford, MA 01824;
## -I-X 617-256-6600; P-J11
P366 Van Leewwen, Lucy; Concurrent (formerly Masscomp); 1 Technology Pk;
## -I-X Westford, MA 01886; 508-392-2849; A-J11
N213 Brosnan, Kevin; Alliant Computer Systems; 1 Monarch Drive; Littleton, MA 01460;
## -I-X 617-486-1345;; P-J11
8238 Blodgett, Bruce; Honeywell Information Systems; 300 Concord Rd MS MA30/843A;
## -ISX Billerica, MA 01821;; 617-671-2029; P-J11
8249 Rozakis, Fred T; Wang Labs; 1 Industrial Av; Lowell, MA 01851;
## -ISX 508-967-7002;; P-J11
------- "South" Boston --------
4224 Johnson, Andrew; Prime Computer; 500 Old Connecticut Path ; MS 10C17-3;
## EISX Framingham, MA 01701;; 508-879-2960 x4045; [email protected] P-J11
P359 Plauger, P J; 398 Main St; Concord, MA 01742; 508-369-8489; P-J11
## -IS- [email protected] (?)
0156 Colligan, Terry; Rational Systems; 102 Union St; POB 480; Natick, MA 01760;
## ---- 508-653-6006;; P-J11
E989 Hudson, Randy; Intermetrics; 733 Concord Av; Cambridge, MA 02138;
## EIS- 617-661-1840;; [email protected] P-J11
4218 Darnell, Peter; Stellar Computer; 95 Wells Av; Newton, MA 02159;
## EIS- 617-964-1000x260; "stellar!pete"@UCBVAX.BERKELEY.EDU" P-J11
------- NY/NJ -------
H233 Prosser, David; AT&T; 190 River Rd; Summit, NJ 07901; 201-522-6227;
## EISX ; [email protected] P-J11
5049 Plum, Thomas; Plum Hall; 1 Spruce Av; Cardiff, NJ 08232; 808-879-4449;
## EIS- ; [email protected] P-J11
H383 Adamczyk, J Stephen Edison Design Group; 907 Timber Oaks Rd; Edison, NJ 08820;
## --S- 201-769-8262;; [email protected] P-J11
G820 Bordelon, Craig; Bellcore; RRC-1B218; 444 Hoes Lane; Piscataway, NJ 08854;
## -IS- ; 201-699-6732; P-J11
8195 Farance, Frank; Farance Inc; 555 Main St; New York , NY 10044;
## -IS- 212-486-4700; P-J11
------- MD/VA/NC -------
1140 Gwyn, Douglas A; US Army Ballistic Research Lab; ATTN: SLCBR-VL-V;
## EISX Aberdeen Proving Gr, MD 21005;; 301-278-6647; [email protected] P-J11
E235 Williams, James; Naval Research Laboratory; 55 Joyceton Wy; Upper Marlboro, MD 20772;
## E--- 202-767-9035(w);; [email protected] P-J11
B085 Jaeschke, Rex; DEC Professional; 1810 Michael Faraday Dr #101; Reston, VA 22090;
## E-S- ; 703-860-0091; [email protected] P-J11
4226 Meissner, Michael; Data General; 62 Alexander Drive; Research Triangle, NC 22709;
## --S- ; 919-248-6250; [email protected] (?) P-J11
E056 Bradley, Oliver; SAS Institute; SAS Circle; Box 8000; Cary, NC 27512;
## ---- 919-467-8000;; P-J11
------- FL -------
G311 Davies, Steve; Concurrent Computer Corp; 2486 Sand Lake Rd; Orlando, FL 32809;
## E-S- 407-850-1040; [email protected] P-J11
4232 Jeter, Gary; Harris Computer Systems; 2101 W Cypress Creek Rd MS 161;
## -IS- Ft Lauderdale, FL 33309;; 305-973-5230; P-J11
N867 Bennett, Mike; Encore Computers; 6901 W Sunrise Blvd; Ft Lauderdale, FL 33569;
## E-S- ; 305-587-2900x4834; [email protected] P-J11
------- OH -------
1333 Jones, Larry; SDRC; 2000 Eastman Dr; Milford, OH 45150; 513-576-2070;
## EIS- [email protected] P-J11
H817 Mickey, Daniel; Chemical Abstracts Serv; 2540 Olentangy River Rd;
## --S- POB 3012; Columbus, OH 43210;; 614-421-3600; P-J11
M344 Saks, Daniel; Saks & Associates; 287 W McCreight Av; Springfield, OH 45504;
## -IS- 513-324-8669;; P-J11
------- MN/IL -------
5716 MacDonald, Tom; Cray Research; 1345 Northland Dr; Mendota Hts, MN 55120;
## EIS- 612-681-5818;; [email protected] P-J11
H337 Bixler, Don; Unisys; POB 64942 MS WE3B; St Paul, MN 55164; 612-635-2062;
## -ISX P-J11
7259 Ness, Steve; Mark Williams Co; 601 N Skokie Hwy; Lake Bluff, IL 60044;
## ---- 415-821-1235(CA);; P-J11
------- TX/UT/S.CA -------
M878 Terrazas, Mike; DECUS Representative; c/o LDS Church; 50 E North Temple St 27 Fl;
## -ISX Salt Lake City,; UT 84150; 801-531-3246; P-J11
D278 Ohmes, Leonard; Datapoint; 9725 Datapoint Dr #S25; San Antonio, TX 78284;
## --S- 512-699-7336;; P-J11
H234 Khushf, Monika; Tymlabs; 811 Barton Springs Rd #511; Austin, TX 78759;
## -IS- 512-478-0611;; P-J11
4217 Brodie, Jim; J Brodie & Associates; 106 S Terrace; Chandler, AZ 85226;
## --S- 602-863-5462;; P-J11
D306 Schubert, Rick; NCR; 9900 Old Grove Rd; San Diego, CA 92131; 619-693-5717;
## -ISX ; P-J11
------- Greater Bay area -------
N220 Stanberry, Linda; Lawrence Livermore Labs; 7000 East Av; POB 808 L300;
## EISX Livermore, CA 94550;; 415-422-1100; [email protected] P-J11
K425 Rasbold, Chuck; Supercomputer Systems Inc; 1404 Concannon Blvd;
## EIS- Livermore, CA 94550; 415-449-9392;; [email protected] P-J11
8240 Pennello, Tom; Metaware; 903 Pacific Av #201; Santa Cruz, CA 95060;
## ---- 408-429-6382;; P-J11
K220 Jervis, Bob; Borland International; 4585 Scotts Valley Dr; Scotts Valley, CA 95066;
## --S- ; 408-438-8400x460; P-J11
J026 Relph, Richard; EPI; 3707 Williams Rd; San Jose, CA 95117; 408-244-7900;
## --S- P-J11
------- Silicon Valley -------
M149 Crockett, Elizabeth Apple Computers; MS 22-AE; 20525 Mariani Av;
## EISX Cupertino, CA 95014;; 408-974-5084; [email protected] P-J11
N438 Murray, Walter J; Hewlett Packard; 19447 Pruneridge Av; Cupertino, CA 95014;
## EISX 408-447-6129;; [email protected] P-J11
N871 Walcott, Zona; Pyramid Technology; 1295 Charleston Rd; POB 7295;
## EIS- Mountain View, CA 94039; 415-965-7200; [email protected] P-J11P-J11
K375 Meissen, Courtney; Sun Microsystems; MS/1-40; 2550 Garcia Av; Mountain View, CA 94043;
## EISX ; 415-336-7397; [email protected] P-J11
B088 Weidenhofer, Neal; Amdahl; MS 316; 1250 E Arques; Sunnyvale, CA 94088;
## EIS- 408-737-5007;; [email protected] P-J11
H237 Hausman, John M; Tandem Computers; 10555 Ridgeview Court; Cupertino, CA 95014;
## --S- 408-996-6555; P-J11
------- OR/WA -------
4792 Weil, David F; Microsoft; 16011 NE 36 Wy; POB 97017; Redmond, WA 98073;
## EIS- 206-882-8516;; [email protected] P-J11
K915 Sutton, Carl; Tektronix; POB 500 MS 19-333; Beaverton, OR 97077;
## ---- 503-627-7111;; [email protected] P-J11
M708 Nelson, Clark; Intel; 5200 Elam Young Pkwy MS HF280; Hillsboro, OR 97124;
## EIS- ; 503-681-2018; [email protected] P-J11
N403 Ryan, Ralph; Chiron Systems; 14486 NE 58 St; Bellevue, WA 98007;
## EIS- 206-869-0141(W); [email protected] P-J11
------- Ontario -------
5680 Elliott, Shawn; IBM; Dept 31/827; 844 Don Mills Rd; North York, Ontario M3C 1V7;
## E-SX ; CANADA; 416-448-2172; [email protected] P-J11
M146 Fosbury, Don; Control Data; Canadian Development Division; 1855 Minnesota Court;
## --SX ; Mississauga, ON L5N 1K7; CANADA; 416-826-8640x3608; P-J11
D276 Kelly, Thomas; HCR Corporation; 130 Bloor St W; Toronto , Ontario M5S 1N5;
## -IS- CANADA;; 416-922-1937; P-J11
J738 Crigger, Fred; Watcom Systems; 415 Phillip St; Waterloo, Ontario N2L 3X2;
## EIS- CANADA;; 519-886-3700; [email protected] P-J11
5-Jul-89 11:49:56-PDT,2202;000000000000
Return-Path: <intelhf!medusa!intelhf!root%[email protected]>
Received: from RELAY.CS.NET by SRI-NIC.ARPA with TCP; Wed, 5 Jul 89 11:48:28 PDT
Received: from [128.215.97.4] by RELAY.CS.NET id ac22610; 5 Jul 89 12:38 EDT
Return-path: [email protected]
Received: from ihf1.intel.com by sc.intel.com; Wed, 28 Jun 89 17:12 PDT
Received: by ihf1.intel.com (/\=-/\ Smail3.1.4.3 #4.4) id
<[email protected]>; Wed, 28 Jun 89 17:14 PDT
Received: by intelhf.hf.intel.com (smail2.5s1); 28 Jun 89 17:02:38 PDT (Wed)
Received: by medusa.intel.com (/\=-/\ Smail3.1.4.3 #4.3) id
<[email protected]>; Wed, 28 Jun 89 16:45 PDT
Received: by intelhf.hf.intel.com (smail2.5s1); 15 Jun 89 04:42:53 PDT (Thu)
Date: 15 Jun 89 04:42:53 PDT (Thu)
From: intelhf.hf.intel.com!Postmaster%[email protected]
Subject: SWCAD netmail delivery problem
To: sri-nic.arpa!X3J11-RELAY%[email protected]
Message-Id: <[email protected]>
Trouble sending SWCAD Netmail to ' clark ' on 'langlab1':
(NOTE: If there are multiple Transcript sections,
check the last one, as it will be the most
useful to you.)
============ Transcript follows ============
Message in queue more than 24 hours, returning
============== Message follows =============
From medusa!sri-nic.arpa!X3J11-RELAY Wed Jun 14 04:09:02 1989 remote from intelhf
Received: by intelhf.hf.intel.com (smail2.5s1); 14 Jun 89 04:09:02 PDT (Wed)
Received: by medusa.intel.com (/\=-/\ Smail3.1.4.3 #4.3)
id <[email protected]>; Wed, 14 Jun 89 04:04 PDT
Return-path: X3J11-RELAY%[email protected]
Received: from SRI-NIC.ARPA by sc.intel.com; Wed, 14 Jun 89 04:05 PDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Sat, 10 Jun 89 20:09:18
PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA00969;
Sat, 10 Jun 89 23:09:05 -0400
Date: Sat Jun 10 22:52:46 1989
From: plumhall!root%[email protected]
To: [email protected], eec1%[email protected],
pete%[email protected]
Message-Id: <[email protected]>
Welcome to XENIX!
5-Jul-89 21:30:29-PDT,3720;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Wed, 5 Jul 89 21:28:41 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA00983; Thu, 6 Jul 89 00:27:55 -0400
Date: Thu, 6 Jul 89 00:09:14 EST
From: [email protected] (Rex Jaeschke)
Subject: Re: 89-057
Message-Id: <8907060009.0.UUL1.3#[email protected]>
To: [email protected]
In-Reply-To: Your message of Wed Jul 5 11:09:33 1989
> Claim that our membership does not contain members competent to make
> decisions about embedded systems.
Plauger + Whitesmiths affiliates (Maurice Fathi & company + ADC in
Japan) all went over the draft from this perspective. Also, I assume
did Dan Lau from Intel and his affiliates Anders Rundgren in Sweeden
and they did the Intel 8051C (I think that's its name) embedded
system compiler. Motorola and Zilog were also involved at various
times. Carl Sutton from Tecktronix. Also, Computer Innovations who
offer rommable stuff.
Of course, Plauger's role as Tech Editor of Embedded Systems
Programming should not be taken lightly.
> Claim that the formation of a Numerical Extensions Group indicates that
> numerical users believe that C is still not a suitable language for
> numerical work.
I don't see what this has to do with anything. This is the first I've
heard that he was interested in numerical applications. Besides,
numerical and embedded are not necessarily related. In fact, I suggest
that most embedded C stuff is NOT numerically related. NCEG is
initially interested in vector/parallel, complex, IEEE, and the like
issues. Now Digital Signal Processing embedded systems might well
involve these issues but that has not been the mainstream embedded
application of the past. Besides, numerical extensions was not within
the agreed framework of the original committee's work definition. The
fact that NCEG exists meand we are prepared to continue on from where
the Stnadard left off. It by no means should be interpreted as a bad
mark against X3J11. In fact, I started NCEG and I have no expertise or
direct interest in numerical programming; I simply wanted such
extensions to be done in a uniform manner. It was NOT the numerical
community complaining about X3J11's inaction in this area.
> Claim that the failure to adopt Hansberry's proposals in Seattle will
> make his work as an embedded-systems programmer significantly more
> difficult, thus causing him damage and giving him the standing to
> initiate a formal appeal.
I don't see how. const and volatile help out as does pinning down
stuff on sequence points, sig_atomic_t. Also, so does prototypes as
gives better quality assurance before burning proms. So does
assignment-compatibility checking. void * probably helps too as does
spec of minimum library, limits.h and float.h. locale.h may well play
a role here too in future workstations.
I don't recall his ever supporting his arguments with concrete
examples of problems in any environment let alone embedded systems
programming. Sounds like a last ditched effort as far as I can see.
Rex
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
6-Jul-89 04:11:46-PDT,1569;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Thu, 6 Jul 89 04:11:37 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA06518; Thu, 6 Jul 89 07:01:52 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: delete Yost
Date: Wed Jul 5 18:45:22 1989
>From uunet!attunix.att.com!dfp Wed Jul 5 18:08:53 1989
Received: from arpa.att.com by uunet.uu.net (5.61/1.14) with SMTP
id AA16269; Wed, 5 Jul 89 16:22:12 -0400
Message-Id: <[email protected]>
>From: uunet!attunix.att.com!dfp
Date: Wed, 5 Jul 89 15:45 EDT
To: plumhall!plum
Subject: forwarded anti-mailing request
From attunix!arpa!cmcl2.NYU.EDU!esquire!yost Wed Jul 05 09:33:35 0400 1989
Received: by cmcl2.NYU.EDU (5.61/1.34)
id AA16533; Wed, 5 Jul 89 09:46:20 -0400
Received: from info8 by ESQUIRE.DPW. id aa10097; 5 Jul 89 9:32 EDT
Received: from localhost by info8. (4.0/SMI-4.0)
id AA00898; Wed, 5 Jul 89 09:33:37 EDT
Message-Id: <8907051333.AA00898@info8.>
To: [email protected]@dpw.NYU.EDU
Cc: [email protected]
Subject: Please take me off the X3J11 lists
Reply-To: [email protected]
Date: Wed, 05 Jul 89 09:33:35 -0400
From: [email protected]
I unsubscribed to X3J11 over a year ago, and yet
I keep getting mailings and my name keeps showing
up on the list of observers (David Yost, LaurelArts).
Who keeps that list? Can I be removed?
Thanks.
--dave
Dave
6-Jul-89 16:27:31-PDT,2951;000000000000
Return-Path: <[email protected]>
Received: from rutgers.edu by SRI-NIC.ARPA with TCP; Thu, 6 Jul 89 16:27:03 PDT
Received: from ogccse.UUCP by rutgers.edu (5.59/SMI4.0/RU1.1/3.04) with UUCP
id AA00511; Thu, 6 Jul 89 19:26:21 EDT
Received: by cse.ogc.edu (5.61+OGC_1.5 (named)/OGC_6.0a)
id AA14334 ; Thu, 6 Jul 89 15:49:51 -0700
Received: by littlei.hf.intel.com (smail2.5a); 6 Jul 89 13:35:13 PDT (Thu)
Received: by intelhf.hf.intel.com (smail2.5s1); 5 Jul 89 21:27:56 PDT (Wed)
Received: by medusa.intel.com (/\=-/\ Smail3.1.4.3 #4.3)
id <[email protected]>; Wed, 5 Jul 89 21:23 PDT
Received: by intelhf.hf.intel.com (smail2.5s1); 5 Jul 89 21:24:26 PDT (Wed)
To: [email protected]
Subject: OpenNET mail delivery problem
Message-Id: <[email protected]>
Date: 5 Jul 89 21:24:26 PDT (Wed)
From: [email protected]
Trouble sending OpenNET Mail to `langlab1'
============ Transcript follows ============
mail.onet: Network connection broke...data lost
============== Message follows =============
>From medusa!relay.cs.net!sri-nic.arpa!X3J11-RELAY Wed Jul 5 21:24:17 1989 remote from intelhf
Received: by intelhf.hf.intel.com (smail2.5s1); 5 Jul 89 21:24:17 PDT (Wed)
Received: by medusa.intel.com (/\=-/\ Smail3.1.4.3 #4.3)
id <[email protected]>; Wed, 5 Jul 89 21:19 PDT
Return-path: X3J11-RELAY%[email protected]
Received: from SRI-NIC.ARPA by sc.intel.com; Wed, 5 Jul 89 21:20 PDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Wed, 5 Jul 89 13:20:30 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP id AA16070;
Wed, 5 Jul 89 16:20:27 -0400
Date: Wed Jul 5 11:09:33 1989
From: plumhall!root%[email protected]
Subject: 89-057
To: x3j11%[email protected]
Message-Id: <[email protected]>
89-057
Request for further information
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
We have received copies of Hansberry's protests. There are a number of
claims that involve J11:
Claim that our membership does not contain members competent to make
decisions about embedded systems.
Claim that the formation of a Numerical Extensions Group indicates that
numerical users believe that C is still not a suitable language for
numerical work.
Claim that the failure to adopt Hansberry's proposals in Seattle will
make his work as an embedded-systems programmer significantly more
difficult, thus causing him damage and giving him the standing to
initiate a formal appeal.
Please discuss these with the other voting members in your local area
(refer to 89-052). Please by noon Thursday (tomorrow) phone or e-mail
any information which helps to refute these claims, all three of which
I believe to be incorrect.
I will keep you posted on developments.
11-Jul-89 03:32:49-PDT,3043;000000000000
Date: Tue, 11 Jul 89 03:28:29 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 4-Jul-89 19:03:30
Message undeliverable and dequeued after 6 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected]: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Tue, 4 Jul 89 19:02:41 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02085; Tue, 4 Jul 89 22:02:07 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-055.1
Date: Tue Jul 4 12:42:19 1989
89-055 PRELIMINARY DRAFT #1
04 Jul 1989
Current status of X3J11 standard
Thomas Plum 609-927-3770 Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
On 29 June, X3 received an 8(?)-page addendum from Russell Hansberry,
adding to the 26-page appeal received previously. Copies of both
documents are being expressed to X3J11 officers, to be received
Wednesday 05 July.
There will be an all-day meeting at the X3 Secretariat Friday 07 July,
with officers from J11, X3, SPARC (Standards Planning and Requirements
Committee), and SMC (Secretariat Management Committee). J11 will be
represented by Plauger (Secretary) and Plum (Vice-Chair). Brodie
(Chair) concurs with this representation.
We have been asked to provide a chronology of J11's interactions with
Hansberry. I believe he makes a claim that he did not receive an
adequate hearing. Therefore, the e-mail distribution of this paper
is accompanied by my rough draft of the chronology (89-056.1). The main
focus is "Who talked with Hansberry, and for how long?".
Three requests:
(1) Please check this chronology for accuracy and completeness; it needs
more details. By noon Thursday (06 July), please e-mail or phone with
any changes for the chronology.
(2) (Referring to 89-052, the list of current voting members) If you
know of someone in your local region, who does not receive e-mail, and
was involved in this chronology, please telephone them to see if they
can add any details.
(3) If your company has X3 representation, please discuss this
upcoming Friday meeting with your X3 representative. If they feel that
it is appropriate, suggest that they telephone any of the X3, SPARC, or
SMC Chair or Vice-Chair people, so that they have some sense of how
their constituents feel about this Hansberry delay.
The officers of J11 believe that an overwhelming consensus of J11
desire that the current Proposed standard should be ratified with the
minimum amount of further delay, and that the officers' responsibility
to the J11 membership is to pursue all legal means to minimize any
further delay. (If you disagree with this assessment, please let me
know.)
-------
11-Jul-89 03:32:51-PDT,3562;000000000000
Date: Tue, 11 Jul 89 03:32:02 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 4-Jul-89 19:05:56
Message undeliverable and dequeued after 6 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected]: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Tue, 4 Jul 89 19:05:14 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA03144; Tue, 4 Jul 89 22:04:51 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-056.1
Date: Tue Jul 4 12:42:28 1989
PRELIMINARY DRAFT - Please e-mail corrections and additions ASAP.
Chronology of X3J11 discussions with Russell Hansberry
Thomas Plum
03 July 1989
Date Duration From / To
Synopsis
1986:
09/__ Letter Russell Hansberry to Rex Jaeschke:
How do I comment to J11?
09/__ Letter Jaeschke to Hansberry:
Send your comments to ANSI BSR and X3 at CBEMA.
1989:
03/06 Letter Hansberry to Jaeschke:
No responses yet, what do I do?
03/__ FAX'es Jaeschke to J11 officers:
We have a problem, letter was lost; FAX'ed copy of his letter.
03/14 18min Jaeschke + Hansberry (206-743-7695):
"I sent your letter to J11 officers." Some technical discussion.
03/21 Letter Hansberry to Jaeschke:
Thanks for your help, some progress.
03/__ 30-45m Hansberry to Tom MacDonald:
Technical. "Most of your points already have been discussed."
03/__ e-mail MacDonald to Dennis Ritchie:
"Should we consider changing precedence?"
03/__ e-mail Ritchie to MacDonald:
"Not at this point in the maturity of C."
03/__ 15-20m MacDonald to Hansberry:
Tried to convince Hansberry to drop his proposals, unlikely
that the committee would have adopted even last year.
03/__ -- Jim Brodie called Hansberry, left message.
03/__ 30-45m Hansberry + Brodie:
Suggest you discuss your points with several C experts on J11.
03/28 25min Jaeschke + Hansberry:
Technical discussion. "Realistic assessment:
very little likelihood of changes at this point."
04/__ ______ P J Plauger to Hansberry:
________
04/03? FAX Hansberry FAX'ed paper to Tom Plum.
04/03? 60-90m Plum to Hansberry:
Technical discussion of points. Committee is willing to
correct errors, but unlikely to make changes on preferences.
04/__ 15-30m Brodie to Hansberry: We will follow procedures and
give you a hearing, but little likelihood. Please consider
withdrawing your proposal.
04/06 Letter Dave Weil FedEx'ed Hansberry the J11 responses to 1st and
2nd public reviews (about 1 1/2 inches of paper), so he could see
that we had been responding to public input, his case was unique.
04/10 60-75m Seattle meeting, morning session. Subgroup:
Full-time: Gwyn, Meissner, Adamski, Ryan.
Part-time: Rosler, Wiedenhofer, ...
04/10 2hr? Afternoon session, subgroup.
04/11 30m? Morning session, subgroup, prepared 3 points for full J11
04/11 45m J11 full committee, discussed 3 points. Votes 31/0,
28/1, 27/3.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
-------
11-Jul-89 15:53:42-PDT,2066;000000000000
Date: Tue, 11 Jul 89 12:05:24 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 5-Jul-89 13:22:05
Message undeliverable and dequeued after 6 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected]: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Wed, 5 Jul 89 13:20:30 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA16070; Wed, 5 Jul 89 16:20:27 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-057
Date: Wed Jul 5 11:09:33 1989
89-057
Request for further information
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
We have received copies of Hansberry's protests. There are a number of
claims that involve J11:
Claim that our membership does not contain members competent to make
decisions about embedded systems.
Claim that the formation of a Numerical Extensions Group indicates that
numerical users believe that C is still not a suitable language for
numerical work.
Claim that the failure to adopt Hansberry's proposals in Seattle will
make his work as an embedded-systems programmer significantly more
difficult, thus causing him damage and giving him the standing to
initiate a formal appeal.
Please discuss these with the other voting members in your local area
(refer to 89-052). Please by noon Thursday (tomorrow) phone or e-mail
any information which helps to refute these claims, all three of which
I believe to be incorrect.
I will keep you posted on developments.
-------
13-Jul-89 00:21:49-PDT,792;000000000000
Mail-From: KLH created at 13-Jul-89 00:21:36
Date: Thu, 13 Jul 89 00:21:36 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: delete Yost
To: [email protected], [email protected]
cc: [email protected]
In-Reply-To: <[email protected]>
Message-ID: <[email protected]>
Was on vacation for awhile, catching up now.
- Dave Yost was never on the X3J11 e-mail list, so that's OK.
- John Peyton was added as [email protected].
A few people are still failing to get their mail, e.g. [email protected] appears
to be unreachable... at least from here. After I have time to gather up
some examples, I'll let you know who they are, in case you have other
ways of contacting them and perhaps getting a better address.
--Ken
-------
14-Jul-89 23:13:42-PDT,2049;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Fri, 14 Jul 89 23:13:32 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AB25501; Fri, 14 Jul 89 23:12:22 PDT
Date: Fri, 14 Jul 89 23:12:22 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA19090; Tue, 11 Jul 89 12:05:10 PDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Wed, 5 Jul 89 13:20:30 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA16070; Wed, 5 Jul 89 16:20:27 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-057
Date: Wed Jul 5 11:09:33 1989
89-057
Request for further information
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
We have received copies of Hansberry's protests. There are a number of
claims that involve J11:
Claim that our membership does not contain members competent to make
decisions about embedded systems.
Claim that the formation of a Numerical Extensions Group indicates that
numerical users believe that C is still not a suitable language for
numerical work.
Claim that the failure to adopt Hansberry's proposals in Seattle will
make his work as an embedded-systems programmer significantly more
difficult, thus causing him damage and giving him the standing to
initiate a formal appeal.
Please discuss these with the other voting members in your local area
(refer to 89-052). Please by noon Thursday (tomorrow) phone or e-mail
any information which helps to refute these claims, all three of which
I believe to be incorrect.
I will keep you posted on developments.
15-Jul-89 00:14:24-PDT,1942;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Sat, 15 Jul 89 00:14:09 PDT
Received: from ukc.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA15435; Sat, 15 Jul 89 03:14:20 -0400
Message-Id: <[email protected]>
To: [email protected]
From: UKC FTP Daemon <[email protected]>
Subject: Failure of your mail.
Date: Sat, 15 Jul 89 08:06:50
Your mail to uk.co.bt.axion failed when the file was transferred.
The mail at this host was to be sent to the follow addresses.
neil%uucp.bsiqa%[email protected]
This was due to an error at uk.co.bt.axion.
The reason given was:
Repeated temporary MMDF failure after 2 attempts [FIO]
The body of your mail follows.
Received: from mcvax by kestrel.Ukc.AC.UK via EUnet with authorised UUCP
id aa28132; 15 Jul 89 8:04 BST
Received: by mcvax.cwi.nl via EUnet; Sat, 15 Jul 89 08:57:49 +0200 (MET)
Received: from SRI-NIC.ARPA by uunet.uu.net (5.61/1.14) with SMTP
id AA07569; Sat, 15 Jul 89 02:41:33 -0400
Received: from vgr.brl.mil by SRI-NIC.ARPA with TCP; Fri, 14 Jul 89 21:29:56 PDT
Date: Sat, 15 Jul 89 0:22:09 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: recursive main()? (and invisible prototype query)
Message-Id: <[email protected]>
Sender: [email protected]
Programmers who need to recurse can do so without using main() as the
name of the recursive function. main() has some special attributes
that could (and apparently do, on VMS at least) require special
treatment for the main() function. We have practically guaranteed
that some implementations will have to handle main() specially, due
to permitting it to be validly defined both with and without
parameters.
I think you're right about old-style function definitions needing to
create an equivalent prototype.
16-Jul-89 01:29:37-PDT,2619;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Sun, 16 Jul 89 01:29:30 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AA12718; Sun, 16 Jul 89 01:28:35 PDT
Date: Sun, 16 Jul 89 01:28:35 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA14501; Thu, 13 Jul 89 00:48:35 PDT
Date: Thu, 13 Jul 89 00:11:12 PDT
From: Ken Harrenstien <[email protected]>
Subject: [[email protected] (Rex Jaeschke): Pls foreward to X3J11 dist list]
To: [email protected]
Message-Id: <[email protected]>
Forwarding at Rex's request:
---------------
Date: Wed, 12 Jul 89 16:01:25 EST
From: [email protected] (Rex Jaeschke)
Subject: Pls foreward to X3J11 dist list
----
Dear X3J11 member,
In my first official act as your (acting) International Rep I need
your input on something, and it's not even C-related.
I need to cast a vote on a ballot re ALGOL 60. Since the US has no
standards group dealing with this, ANSI is asking all other language
groups to provide input. You have three choices:
Either ALGOL 60 ISO 1538:1984 should be:
A) confirmed
B) Revised
C) Withdrawn
If you feel at all qualified in this matter PLEASE contact me
immediately. Due to the limited time I have left to respond and my
travel schedule, I can only accept email responses (to
uunet!aussie!rex) that arrive here by mid-Sunday July 16th. After
that (or instead of email) phone me on (703) 860-0091. I work out of
home so weekends is fine. There's an answering machine too.
Thanks in advance.
----
BTW, does anyone out there believe an ANSI-conformant implementation
requires that main be able to be called reliably, recursively? This is
a serious issue.
----
Rex
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
16-Jul-89 02:33:01-PDT,1235;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Sun, 16 Jul 89 02:32:56 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AA15256; Sun, 16 Jul 89 02:32:03 PDT
Date: Sun, 16 Jul 89 02:32:03 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA16282; Thu, 13 Jul 89 01:33:59 PDT
Received: from vgr.brl.mil by SRI-NIC.ARPA with TCP; Thu, 13 Jul 89 00:58:52 PDT
Date: Thu, 13 Jul 89 3:57:50 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: Ken Harrenstien <[email protected]>
Cc: [email protected]
Subject: Re: [[email protected] (Rex Jaeschke): Pls foreward to X3J11 dist list]
Message-Id: <[email protected]>
I don't think main() can be used recursively, because the nested call
would violate the specification with regard to how the parameters are
set up upon entry to main(), i.e. would conflict with what we say for
normal functions.
18-Jul-89 00:47:46-PDT,1501;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Tue, 18 Jul 89 00:47:38 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AD09528; Tue, 18 Jul 89 00:46:19 PDT
Date: Tue, 18 Jul 89 00:46:19 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA04008; Fri, 14 Jul 89 23:39:18 PDT
Received: from vgr.brl.mil by SRI-NIC.ARPA with TCP; Fri, 14 Jul 89 21:29:56 PDT
Date: Sat, 15 Jul 89 0:22:09 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: Ken Harrenstien <[email protected]>
Cc: [email protected]
Subject: Re: recursive main()? (and invisible prototype query)
Message-Id: <[email protected]>
Programmers who need to recurse can do so without using main() as the
name of the recursive function. main() has some special attributes
that could (and apparently do, on VMS at least) require special
treatment for the main() function. We have practically guaranteed
that some implementations will have to handle main() specially, due
to permitting it to be validly defined both with and without
parameters.
I think you're right about old-style function definitions needing to
create an equivalent prototype.
19-Jul-89 02:47:01-PDT,2455;000000000000
Mail-From: VIVIAN created at 19-Jul-89 02:44:41
Date: Wed, 19 Jul 89 02:44:41 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Jul-89 00:11:20
Message undeliverable and dequeued after 6 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Date: Thu, 13 Jul 89 00:11:12 PDT
From: Ken Harrenstien <[email protected]>
Subject: [[email protected] (Rex Jaeschke): Pls foreward to X3J11 dist list]
To: [email protected]
Message-ID: <[email protected]>
Forwarding at Rex's request:
---------------
Date: Wed, 12 Jul 89 16:01:25 EST
From: [email protected] (Rex Jaeschke)
Subject: Pls foreward to X3J11 dist list
----
Dear X3J11 member,
In my first official act as your (acting) International Rep I need
your input on something, and it's not even C-related.
I need to cast a vote on a ballot re ALGOL 60. Since the US has no
standards group dealing with this, ANSI is asking all other language
groups to provide input. You have three choices:
Either ALGOL 60 ISO 1538:1984 should be:
A) confirmed
B) Revised
C) Withdrawn
If you feel at all qualified in this matter PLEASE contact me
immediately. Due to the limited time I have left to respond and my
travel schedule, I can only accept email responses (to
uunet!aussie!rex) that arrive here by mid-Sunday July 16th. After
that (or instead of email) phone me on (703) 860-0091. I work out of
home so weekends is fine. There's an answering machine too.
Thanks in advance.
----
BTW, does anyone out there believe an ANSI-conformant implementation
requires that main be able to be called reliably, recursively? This is
a serious issue.
----
Rex
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
-------
19-Jul-89 02:47:04-PDT,1087;000000000000
Mail-From: VIVIAN created at 19-Jul-89 02:44:44
Date: Wed, 19 Jul 89 02:44:44 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Jul-89 00:58:59
Message undeliverable and dequeued after 6 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from vgr.brl.mil by SRI-NIC.ARPA with TCP; Thu, 13 Jul 89 00:58:52 PDT
Date: Thu, 13 Jul 89 3:57:50 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: Ken Harrenstien <[email protected]>
cc: [email protected]
Subject: Re: [[email protected] (Rex Jaeschke): Pls foreward to X3J11 dist list]
Message-ID: <[email protected]>
I don't think main() can be used recursively, because the nested call
would violate the specification with regard to how the parameters are
set up upon entry to main(), i.e. would conflict with what we say for
normal functions.
-------
19-Jul-89 02:52:32-PDT,2234;000000000000
Date: Wed, 19 Jul 89 02:52:08 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Jul-89 06:47:11
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
fwc%[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
------------
Received: from arpa.att.com by SRI-NIC.ARPA with TCP; Thu, 13 Jul 89 06:46:28 PDT
From: [email protected]
Date: Thu, 13 Jul 89 09:36 EDT
To: [email protected]
Subject: Re: recursive main()?
Rex Jaeschke asks:
> BTW, does anyone out there believe an ANSI-conformant implementation
> requires that main be able to be called reliably, recursively? This is
> a serious issue.
To which Doug Gwyn replies:
> I don't think main() can be used recursively, because the nested call
> would violate the specification with regard to how the parameters are
> set up upon entry to main(), i.e. would conflict with what we say for
> normal functions.
I disagree. I see nothing in the description of main() that disallows
a strictly conforming program from calling its own main(). There are
requirements on the startup call's arguments to main(), and requirements
about the return from this initial call, but these do not apply to any
subsequent calls.
I would say that a conforming implementation must allow main() to be
called by a program...subject to the normal function call rules, limits
on stack space, and so on. Putting it another way, the following should
be a strictly conforming program that always prints "Hello world" and
terminates successfully:
#include <stdio.h>
int
main(int argc, char **argv)
{
if (argc > 0)
return 32767 - main(0, (char **)0);
(void)printf("Hello world\n");
return 32767;
}
Dave Prosser
-------
19-Jul-89 03:32:49-PDT,1566;000000000000
Mail-From: VIVIAN created at 19-Jul-89 03:32:06
Date: Wed, 19 Jul 89 03:32:06 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Jul-89 14:03:28
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Date: Thu, 13 Jul 89 14:03:00 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: recursive main()? (and invisible prototype query)
To: [email protected]
cc: [email protected]
In-Reply-To: Message from "[email protected]" of Thu, 13 Jul 89 06:55:05 PDT
Message-ID: <[email protected]>
I agree with Dave Prosser, there isn't anything I can see that prohibits
recursion on main() -- something that actually can be useful in at least
one real program I know of. Why would this be a problem?
By the way, as long as I'm writing, here's a different question that
I'm wondering about. What happens when you have an old-style function
definition followed later by a new-style (prototype) reference? The
discussion of compatibility in 3.5.4.3 (p.69, l.12-25) doesn't
distinguish between the ordering. This appears to imply that every
old-style function definition, even though it doesn't declare a
prototype, must still create and carry around a prototype which is
totally invisible EXCEPT for this single solitary special case. Ugh!
--Ken
-------
-------
19-Jul-89 20:47:11-PDT,2158;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Wed, 19 Jul 89 20:47:03 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AB27378; Wed, 19 Jul 89 20:45:52 PDT
Date: Wed, 19 Jul 89 20:45:52 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA19093; Sun, 16 Jul 89 16:19:30 PDT
Message-Id: <[email protected]>
Received: from arpa.att.com by SRI-NIC.ARPA with TCP; Thu, 13 Jul 89 06:46:28 PDT
From: [email protected]
Date: Thu, 13 Jul 89 09:36 EDT
To: [email protected]
Subject: Re: recursive main()?
Rex Jaeschke asks:
> BTW, does anyone out there believe an ANSI-conformant implementation
> requires that main be able to be called reliably, recursively? This is
> a serious issue.
To which Doug Gwyn replies:
> I don't think main() can be used recursively, because the nested call
> would violate the specification with regard to how the parameters are
> set up upon entry to main(), i.e. would conflict with what we say for
> normal functions.
I disagree. I see nothing in the description of main() that disallows
a strictly conforming program from calling its own main(). There are
requirements on the startup call's arguments to main(), and requirements
about the return from this initial call, but these do not apply to any
subsequent calls.
I would say that a conforming implementation must allow main() to be
called by a program...subject to the normal function call rules, limits
on stack space, and so on. Putting it another way, the following should
be a strictly conforming program that always prints "Hello world" and
terminates successfully:
#include <stdio.h>
int
main(int argc, char **argv)
{
if (argc > 0)
return 32767 - main(0, (char **)0);
(void)printf("Hello world\n");
return 32767;
}
Dave Prosser
19-Jul-89 23:15:36-PDT,1730;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Wed, 19 Jul 89 23:15:28 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AA03406; Wed, 19 Jul 89 23:14:18 PDT
Date: Wed, 19 Jul 89 23:14:18 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA02928; Sun, 16 Jul 89 22:49:14 PDT
Date: Thu, 13 Jul 89 14:03:00 PDT
From: Ken Harrenstien <[email protected]>
Subject: Re: recursive main()? (and invisible prototype query)
To: [email protected]
Cc: [email protected]
In-Reply-To: Message from "[email protected]" of Thu, 13 Jul 89 06:55:05 PDT
Message-Id: <[email protected]>
I agree with Dave Prosser, there isn't anything I can see that prohibits
recursion on main() -- something that actually can be useful in at least
one real program I know of. Why would this be a problem?
By the way, as long as I'm writing, here's a different question that
I'm wondering about. What happens when you have an old-style function
definition followed later by a new-style (prototype) reference? The
discussion of compatibility in 3.5.4.3 (p.69, l.12-25) doesn't
distinguish between the ordering. This appears to imply that every
old-style function definition, even though it doesn't declare a
prototype, must still create and carry around a prototype which is
totally invisible EXCEPT for this single solitary special case. Ugh!
--Ken
-------
21-Jul-89 21:51:54-PDT,1488;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Fri, 21 Jul 89 21:51:26 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA03872; Sat, 22 Jul 89 00:51:19 -0400
Date: Fri, 21 Jul 89 23:48:22 EST
From: [email protected] (Rex Jaeschke)
Subject: Re: recursive main()? (and invisible prototype query)
Message-Id: <8907212348.0.UUL1.3#[email protected]>
To: [email protected]
In-Reply-To: Your message of Thu, 13 Jul 89 14:03:00 PDT
> I agree with Dave Prosser, there isn't anything I can see that prohibits
> recursion on main() -- something that actually can be useful in at least
> one real program I know of. Why would this be a problem?
>
Consider an (existing) implementation in which main actually calls
the startup code, not vice versa. Subsequent calls to main then also
call the startup code causing the program to crash and burn.
Rex
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL |1810 Michael Faraday Drive, Suite 101
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22090, USA
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
24-Jul-89 01:06:50-PDT,2263;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by SRI-NIC.ARPA with TCP; Mon, 24 Jul 89 01:06:40 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AA29585; Mon, 24 Jul 89 01:05:51 PDT
Date: Mon, 24 Jul 89 01:05:51 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA23730; Fri, 21 Jul 89 01:04:21 PDT
Message-Id: <[email protected]>
Received: from arpa.att.com by SRI-NIC.ARPA with TCP; Mon, 17 Jul 89 07:28:50 PDT
From: [email protected]
Date: Mon, 17 Jul 89 10:18 EDT
To: attunix!arpa!SRI-NIC.ARPA!KLH, [email protected]
Subject: Re: recursive main()? (and invisible prototype query)
> I agree with Dave Prosser, there isn't anything I can see that prohibits
> recursion on main() -- something that actually can be useful in at least
> one real program I know of. Why would this be a problem?
>
> By the way, as long as I'm writing, here's a different question that
> I'm wondering about. What happens when you have an old-style function
> definition followed later by a new-style (prototype) reference? The
> discussion of compatibility in 3.5.4.3 (p.69, l.12-25) doesn't
> distinguish between the ordering. This appears to imply that every
> old-style function definition, even though it doesn't declare a
> prototype, must still create and carry around a prototype which is
> totally invisible EXCEPT for this single solitary special case. Ugh!
>
> --Ken
> -------
I agree with Ken and Doug--each old-style function definition that has
so far appeared in a compilation unit must retain some information about
its parameters. Not enough so as to cause any modification in argument
passing, but enough to give a diagnostic should a mismatching prototype
occur (at file scope) for one of these functions. Of course, a "quality"
implementation will make use of this information to give diagnostics
about any misshaped calls to the function, but that's not required.
Dave
24-Jul-89 13:43:01-PDT,1285;000000000000
Date: Mon, 24 Jul 89 13:33:21 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 14-Jul-89 21:30:06
Message undeliverable and dequeued after 10 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
------------
Received: from vgr.brl.mil by SRI-NIC.ARPA with TCP; Fri, 14 Jul 89 21:29:56 PDT
Date: Sat, 15 Jul 89 0:22:09 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: Ken Harrenstien <[email protected]>
cc: [email protected]
Subject: Re: recursive main()? (and invisible prototype query)
Message-ID: <[email protected]>
Programmers who need to recurse can do so without using main() as the
name of the recursive function. main() has some special attributes
that could (and apparently do, on VMS at least) require special
treatment for the main() function. We have practically guaranteed
that some implementations will have to handle main() specially, due
to permitting it to be validly defined both with and without
parameters.
I think you're right about old-style function definitions needing to
create an equivalent prototype.
-------
3-Aug-89 12:22:29-PDT,1760;000000000000
Date: Thu, 3 Aug 89 12:05:57 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 28-Jul-89 11:30:27
Message undeliverable and dequeued after 6 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
fwc%[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from RELAY.CS.NET ([192.31.103.4]) by SRI-NIC.ARPA with TCP; Fri, 28 Jul 89 11:28:31 PDT
Received: from relay2.cs.net by RELAY.CS.NET id ac17209; 28 Jul 89 14:25 EDT
Received: from ncr.com by RELAY.CS.NET id ae09268; 28 Jul 89 14:21 EDT
To: [email protected]
From: rns%[email protected]
Date: Fri, 28 Jul 89 14:02:03 -0400 (at ncrlnk.Dayton.NCR.COM)
Can this mailing list be used to keep us up-to-date on the Hansberry
situation? I, for one, would be interested in what has been happening.
I would also like to keep my X3 representative informed as far as he
may be involved, although I realize that there may be some discussion
we may want to keep within X3J11.
Which of Hansberry's issues is he still pursuing? I have a copy of
89-017 which has 20 points.
Thanks.
-- Rick Schubert ([email protected])
-------
4-Aug-89 16:29:15-PDT,4627;000000000000
Date: Fri, 4 Aug 89 16:28:22 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 1-Aug-89 10:23:20
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Tue, 1 Aug 89 10:07:36 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA28723; Tue, 1 Aug 89 13:05:50 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-058.1
Date: Tue Aug 1 13:00:21 1989
.X3 89-058 "Current status, and cancellation of meeting" \
"01 Aug 89" "Jim Brodie"
This is a formal notice that the meeting scheduled for Salt Lake
City on September 21st and 22nd, 1989 has been CANCELLED.
Let me give you a little background on our current status to help
explain why the meeting has been cancelled.
We submitted the draft standard and our responses to Mr.
Hansberry's comments to the X3 Secretariat following the April
X3J11 meeting. This was done on the timetable discussed at that
meeting.
Mr. Hansberry, however, did not accept our responses and has
written a formal appeal to X3, challenging the work of X3J11.
The appeal is fairly lengthy, raising about 40 different
technical and procedural issues. It also threatens legal action
if he is not satisfied with the results.
According to the X3 rules only procedural issues can be addressed
in an appeal. The technical issues will be considered closed if
no negative X3 votes arise during the reconsideration ballot
which is currently being conducted. (Mr Hansberry's letter and
our responses were, after a delay because of the appeal,
distributed to the X3 members and they have been given an
opportunity to change their vote based solely on the issues
raised in his paper). This reconsideration ballot will close
August 2, 1989.
The procedural issues are not so easily addressed. Each appeal
issue must be responded to by X3. Tom Plum and Bill Plauger met
with the X3 leadership, in Washington D.C., to help organize,
supply information for, and expedite the X3 response to the
appeal. The formal procedures for the appeal process,
unfortunately, take a considerable amount of time.
A response to Mr Hansberry's appeal has been prepared and sent
out by X3 (with a lot of help from Tom Plum). The X3 position is
that appeal is unwarranted and that no additional remedial action
is required.
If Mr. Hansberry accepts the X3 response (or does not respond by
August 15, 1989 ) and there are no ballot changes during the
reconsideration ballot, the proposed draft C standard will be
forwarded up to ANSI for consideration during August.
If Mr. Hansberry does not accept the X3 response to his appeal,
then a formal appeal board must be formed. The process for
forming and convening this board will probably take a least two
months. The findings of this board will govern what further
steps must be taken.
If the board finds in favor of X3J11 (as we currently believe
that they should), the standard will be forwarded on to ANSI at
the conclusion of their work.
The ANSI committee, BSR, that reviews draft proposed standards
meets in the middle of October and the middle of December. If by
some outside chance we get the draft proposed C standard to them
in time to be considered during the October meeting, we would, if
there are no further problems, have a standard by November, 1989.
If we miss October and make the December meeting, it will
probably be January, 1990 before we formally have an approved
standard.
If still not satisfied, Mr Hansberry has the option of appealing
yet again at the ANSI level. However, in most cases, this appeal
is processed after the draft proposed standard receives the
American National Standard status.
The bottom line on all of this is that we don't have a C standard
yet. We, therefore, are not in a position to begin the process
of doing interpretations. This makes a September meeting of very
limited value. Since it seems our time and travel budgets are
always strained, the officers believed that it was better to
simply cancel this meeting and aim for the March, 1990 meeting in
New York.
If you have any questions, please feel free to give me a call. I
have recently accepted a position with Honeywell Inc in Phoenix.
My new phone number is (602) 863-5462.
[A POSTSCRIPT DATED AUGUST 02 OR 03 WILL GO HERE, WITH RESULTS OF
X3 RECONSIDERATION BALLOT. - T Plum. ]
-------
6-Aug-89 19:13:33-PDT,4775;000000000000
Date: Sun, 6 Aug 89 19:11:20 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 1-Aug-89 10:23:20
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Tue, 1 Aug 89 10:07:36 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA28723; Tue, 1 Aug 89 13:05:50 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-058.1
Date: Tue Aug 1 13:00:21 1989
.X3 89-058 "Current status, and cancellation of meeting" \
"01 Aug 89" "Jim Brodie"
This is a formal notice that the meeting scheduled for Salt Lake
City on September 21st and 22nd, 1989 has been CANCELLED.
Let me give you a little background on our current status to help
explain why the meeting has been cancelled.
We submitted the draft standard and our responses to Mr.
Hansberry's comments to the X3 Secretariat following the April
X3J11 meeting. This was done on the timetable discussed at that
meeting.
Mr. Hansberry, however, did not accept our responses and has
written a formal appeal to X3, challenging the work of X3J11.
The appeal is fairly lengthy, raising about 40 different
technical and procedural issues. It also threatens legal action
if he is not satisfied with the results.
According to the X3 rules only procedural issues can be addressed
in an appeal. The technical issues will be considered closed if
no negative X3 votes arise during the reconsideration ballot
which is currently being conducted. (Mr Hansberry's letter and
our responses were, after a delay because of the appeal,
distributed to the X3 members and they have been given an
opportunity to change their vote based solely on the issues
raised in his paper). This reconsideration ballot will close
August 2, 1989.
The procedural issues are not so easily addressed. Each appeal
issue must be responded to by X3. Tom Plum and Bill Plauger met
with the X3 leadership, in Washington D.C., to help organize,
supply information for, and expedite the X3 response to the
appeal. The formal procedures for the appeal process,
unfortunately, take a considerable amount of time.
A response to Mr Hansberry's appeal has been prepared and sent
out by X3 (with a lot of help from Tom Plum). The X3 position is
that appeal is unwarranted and that no additional remedial action
is required.
If Mr. Hansberry accepts the X3 response (or does not respond by
August 15, 1989 ) and there are no ballot changes during the
reconsideration ballot, the proposed draft C standard will be
forwarded up to ANSI for consideration during August.
If Mr. Hansberry does not accept the X3 response to his appeal,
then a formal appeal board must be formed. The process for
forming and convening this board will probably take a least two
months. The findings of this board will govern what further
steps must be taken.
If the board finds in favor of X3J11 (as we currently believe
that they should), the standard will be forwarded on to ANSI at
the conclusion of their work.
The ANSI committee, BSR, that reviews draft proposed standards
meets in the middle of October and the middle of December. If by
some outside chance we get the draft proposed C standard to them
in time to be considered during the October meeting, we would, if
there are no further problems, have a standard by November, 1989.
If we miss October and make the December meeting, it will
probably be January, 1990 before we formally have an approved
standard.
If still not satisfied, Mr Hansberry has the option of appealing
yet again at the ANSI level. However, in most cases, this appeal
is processed after the draft proposed standard receives the
American National Standard status.
The bottom line on all of this is that we don't have a C standard
yet. We, therefore, are not in a position to begin the process
of doing interpretations. This makes a September meeting of very
limited value. Since it seems our time and travel budgets are
always strained, the officers believed that it was better to
simply cancel this meeting and aim for the March, 1990 meeting in
New York.
If you have any questions, please feel free to give me a call. I
have recently accepted a position with Honeywell Inc in Phoenix.
My new phone number is (602) 863-5462.
[A POSTSCRIPT DATED AUGUST 02 OR 03 WILL GO HERE, WITH RESULTS OF
X3 RECONSIDERATION BALLOT. - T Plum. ]
-------
7-Aug-89 12:32:39-PDT,557;000000000000
Return-Path: <@SRI-NIC.ARPA:[email protected]>
Received: from SRI-NIC.ARPA by SRI-NIC.ARPA with TCP; Mon, 7 Aug 89 12:06:04 PDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Mon, 7 Aug 89 10:58:47 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA19661; Sat, 5 Aug 89 08:26:44 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: New address
Date: Fri Aug 4 17:29:57 1989
Tom Penello, Metaware uunet!sun!acad!metaware!tom
7-Aug-89 22:53:17-PDT,4987;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by NIC.DDN.MIL with TCP; Mon, 7 Aug 89 22:53:09 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AD17142; Mon, 7 Aug 89 20:54:27 PDT
Date: Mon, 7 Aug 89 20:54:27 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from SRI-NIC.ARPA by Sun.COM (4.1/SMI-4.1)
id AA12684; Fri, 4 Aug 89 16:27:43 PDT
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Tue, 1 Aug 89 10:07:36 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA28723; Tue, 1 Aug 89 13:05:50 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: 89-058.1
Date: Tue Aug 1 13:00:21 1989
.X3 89-058 "Current status, and cancellation of meeting" \
"01 Aug 89" "Jim Brodie"
This is a formal notice that the meeting scheduled for Salt Lake
City on September 21st and 22nd, 1989 has been CANCELLED.
Let me give you a little background on our current status to help
explain why the meeting has been cancelled.
We submitted the draft standard and our responses to Mr.
Hansberry's comments to the X3 Secretariat following the April
X3J11 meeting. This was done on the timetable discussed at that
meeting.
Mr. Hansberry, however, did not accept our responses and has
written a formal appeal to X3, challenging the work of X3J11.
The appeal is fairly lengthy, raising about 40 different
technical and procedural issues. It also threatens legal action
if he is not satisfied with the results.
According to the X3 rules only procedural issues can be addressed
in an appeal. The technical issues will be considered closed if
no negative X3 votes arise during the reconsideration ballot
which is currently being conducted. (Mr Hansberry's letter and
our responses were, after a delay because of the appeal,
distributed to the X3 members and they have been given an
opportunity to change their vote based solely on the issues
raised in his paper). This reconsideration ballot will close
August 2, 1989.
The procedural issues are not so easily addressed. Each appeal
issue must be responded to by X3. Tom Plum and Bill Plauger met
with the X3 leadership, in Washington D.C., to help organize,
supply information for, and expedite the X3 response to the
appeal. The formal procedures for the appeal process,
unfortunately, take a considerable amount of time.
A response to Mr Hansberry's appeal has been prepared and sent
out by X3 (with a lot of help from Tom Plum). The X3 position is
that appeal is unwarranted and that no additional remedial action
is required.
If Mr. Hansberry accepts the X3 response (or does not respond by
August 15, 1989 ) and there are no ballot changes during the
reconsideration ballot, the proposed draft C standard will be
forwarded up to ANSI for consideration during August.
If Mr. Hansberry does not accept the X3 response to his appeal,
then a formal appeal board must be formed. The process for
forming and convening this board will probably take a least two
months. The findings of this board will govern what further
steps must be taken.
If the board finds in favor of X3J11 (as we currently believe
that they should), the standard will be forwarded on to ANSI at
the conclusion of their work.
The ANSI committee, BSR, that reviews draft proposed standards
meets in the middle of October and the middle of December. If by
some outside chance we get the draft proposed C standard to them
in time to be considered during the October meeting, we would, if
there are no further problems, have a standard by November, 1989.
If we miss October and make the December meeting, it will
probably be January, 1990 before we formally have an approved
standard.
If still not satisfied, Mr Hansberry has the option of appealing
yet again at the ANSI level. However, in most cases, this appeal
is processed after the draft proposed standard receives the
American National Standard status.
The bottom line on all of this is that we don't have a C standard
yet. We, therefore, are not in a position to begin the process
of doing interpretations. This makes a September meeting of very
limited value. Since it seems our time and travel budgets are
always strained, the officers believed that it was better to
simply cancel this meeting and aim for the March, 1990 meeting in
New York.
If you have any questions, please feel free to give me a call. I
have recently accepted a position with Honeywell Inc in Phoenix.
My new phone number is (602) 863-5462.
[A POSTSCRIPT DATED AUGUST 02 OR 03 WILL GO HERE, WITH RESULTS OF
X3 RECONSIDERATION BALLOT. - T Plum. ]
9-Aug-89 20:18:38-PDT,1786;000000000000
Date: Wed, 9 Aug 89 20:15:57 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 9-Aug-89 17:41:18
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uc.msc.umn.edu by NIC.DDN.MIL with TCP; Wed, 9 Aug 89 17:41:09 PDT
Received: from tmacd.cray.com by uc.msc.umn.edu (5.59/1.14)
id AA25868; Wed, 9 Aug 89 19:38:58 CDT
Received: by tmacd.cray.com
id AA05419; 3.2/CRI-3.10; Wed, 9 Aug 89 19:40:47 CDT
Date: Wed, 9 Aug 89 19:40:47 CDT
From: [email protected] (Tom MacDonald)
Message-Id: <[email protected]>
To: [email protected]
Subject: Supercomputing 89
CALL FOR SPEAKERS
from
Tom MacDonald
Cray Research, Inc.
1345 Northland Drive
Mendota Heights, MN 55120
(612) 681 - 5818
[email protected]
uunet!cray!tam
During the week of November 13 - 17, 1989 the "Supercomputer 89" conference
will be held in Reno, Nevada. I am organizing a workshop on Friday the
17th. The topic is "Scientific and Numerical Programming in C." The
focus of the workshop is to discuss issues involved with using C for
numerical and scientific applications. This includes programming
techniques used to achieve high performance on supercomputers and any
issues involved with using C on supercomputers. This also includes C
derivatives such as C++, C*, and Objective C.
Please let me know if you have any interest in making a presentation
or if you know of someone else that I could contact. The popularity
of C on supercomputers is increasing every year and this is an excellent
opportunity to learn about and discuss issues that affect all of us.
Thank you for your interest.
-------
12-Aug-89 20:25:08-PDT,2149;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by NIC.DDN.MIL with TCP; Sat, 12 Aug 89 20:25:01 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AB12979; Sat, 12 Aug 89 20:23:41 PDT
Date: Sat, 12 Aug 89 20:23:41 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from NIC.DDN.MIL by Sun.COM (4.1/SMI-4.1)
id AA06121; Wed, 9 Aug 89 20:11:41 PDT
Received: from uc.msc.umn.edu by NIC.DDN.MIL with TCP; Wed, 9 Aug 89 17:41:09 PDT
Received: from tmacd.cray.com by uc.msc.umn.edu (5.59/1.14)
id AA25868; Wed, 9 Aug 89 19:38:58 CDT
Received: by tmacd.cray.com
id AA05419; 3.2/CRI-3.10; Wed, 9 Aug 89 19:40:47 CDT
Date: Wed, 9 Aug 89 19:40:47 CDT
From: [email protected] (Tom MacDonald)
Message-Id: <[email protected]>
To: [email protected]
Subject: Supercomputing 89
CALL FOR SPEAKERS
from
Tom MacDonald
Cray Research, Inc.
1345 Northland Drive
Mendota Heights, MN 55120
(612) 681 - 5818
[email protected]
uunet!cray!tam
During the week of November 13 - 17, 1989 the "Supercomputer 89" conference
will be held in Reno, Nevada. I am organizing a workshop on Friday the
17th. The topic is "Scientific and Numerical Programming in C." The
focus of the workshop is to discuss issues involved with using C for
numerical and scientific applications. This includes programming
techniques used to achieve high performance on supercomputers and any
issues involved with using C on supercomputers. This also includes C
derivatives such as C++, C*, and Objective C.
Please let me know if you have any interest in making a presentation
or if you know of someone else that I could contact. The popularity
of C on supercomputers is increasing every year and this is an excellent
opportunity to learn about and discuss issues that affect all of us.
Thank you for your interest.
15-Aug-89 03:12:31-PDT,1937;000000000000
Date: Tue, 15 Aug 89 03:08:53 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 9-Aug-89 17:41:18
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uc.msc.umn.edu by NIC.DDN.MIL with TCP; Wed, 9 Aug 89 17:41:09 PDT
Received: from tmacd.cray.com by uc.msc.umn.edu (5.59/1.14)
id AA25868; Wed, 9 Aug 89 19:38:58 CDT
Received: by tmacd.cray.com
id AA05419; 3.2/CRI-3.10; Wed, 9 Aug 89 19:40:47 CDT
Date: Wed, 9 Aug 89 19:40:47 CDT
From: [email protected] (Tom MacDonald)
Message-Id: <[email protected]>
To: [email protected]
Subject: Supercomputing 89
CALL FOR SPEAKERS
from
Tom MacDonald
Cray Research, Inc.
1345 Northland Drive
Mendota Heights, MN 55120
(612) 681 - 5818
[email protected]
uunet!cray!tam
During the week of November 13 - 17, 1989 the "Supercomputer 89" conference
will be held in Reno, Nevada. I am organizing a workshop on Friday the
17th. The topic is "Scientific and Numerical Programming in C." The
focus of the workshop is to discuss issues involved with using C for
numerical and scientific applications. This includes programming
techniques used to achieve high performance on supercomputers and any
issues involved with using C on supercomputers. This also includes C
derivatives such as C++, C*, and Objective C.
Please let me know if you have any interest in making a presentation
or if you know of someone else that I could contact. The popularity
of C on supercomputers is increasing every year and this is an excellent
opportunity to learn about and discuss issues that affect all of us.
Thank you for your interest.
-------
15-Aug-89 14:48:09-PDT,2565;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Tue, 15 Aug 89 14:47:07 PDT
Received: from NIC.DDN.MIL by decwrl.dec.com (5.54.5/4.7.34)
id AA22926; Tue, 15 Aug 89 03:08:02 PDT
Date: Tue, 15 Aug 89 03:08:02 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <[email protected]>
Received: from NIC.DDN.MIL by decwrl.dec.com (5.54.5/4.7.34)
for [email protected]; id AA22926; Tue, 15 Aug 89 03:08:02 PDT
To: <[email protected]>
----- Transcript of session follows -----
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-decwet
554 <[email protected]>... Remote protocol error
----- Unsent message follows -----
Received: from NIC.DDN.MIL by decwrl.dec.com (5.54.5/4.7.34)
id AA22924; Tue, 15 Aug 89 03:08:02 PDT
Received: from NIC.DDN.MIL by decwrl.dec.com (5.54.5/4.7.34)
for dec-decwet::vandepas; id AA22924; Tue, 15 Aug 89 03:08:02 PDT
Received: from uc.msc.umn.edu by NIC.DDN.MIL with TCP; Wed, 9 Aug 89 17:41:09 PDT
Received: from tmacd.cray.com by uc.msc.umn.edu (5.59/1.14)
id AA25868; Wed, 9 Aug 89 19:38:58 CDT
Received: by tmacd.cray.com
id AA05419; 3.2/CRI-3.10; Wed, 9 Aug 89 19:40:47 CDT
Date: Wed, 9 Aug 89 19:40:47 CDT
From: [email protected] (Tom MacDonald)
Message-Id: <[email protected]>
To: [email protected]
Subject: Supercomputing 89
CALL FOR SPEAKERS
from
Tom MacDonald
Cray Research, Inc.
1345 Northland Drive
Mendota Heights, MN 55120
(612) 681 - 5818
[email protected]
uunet!cray!tam
During the week of November 13 - 17, 1989 the "Supercomputer 89" conference
will be held in Reno, Nevada. I am organizing a workshop on Friday the
17th. The topic is "Scientific and Numerical Programming in C." The
focus of the workshop is to discuss issues involved with using C for
numerical and scientific applications. This includes programming
techniques used to achieve high performance on supercomputers and any
issues involved with using C on supercomputers. This also includes C
derivatives such as C++, C*, and Objective C.
Please let me know if you have any interest in making a presentation
or if you know of someone else that I could contact. The popularity
of C on supercomputers is increasing every year and this is an excellent
opportunity to learn about and discuss issues that affect all of us.
Thank you for your interest.
18-Aug-89 10:08:59-PDT,913;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 18 Aug 89 10:07:32 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA25702; Fri, 18 Aug 89 13:03:59 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: logist.ncr
Date: Thu Aug 17 07:34:39 1989
>From uunet!ncrlnk!ncr-sd!se-sd.SanDiego.NCR.COM!rns Thu Aug 17 07:26:56 1989
Received: from ncrlnk.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA27793; Tue, 15 Aug 89 20:14:48 -0400
Message-Id: <[email protected]>
Date: 15 Aug 89 16:33:03 PDT
From: uunet!se-sd.SanDiego.NCR.COM!rns
To: plumhall.uu.NET!plum
Subject: X3J11 Logistics Committee
Tom,
I hereby volunteer for the Logistics Committee. Let me know what I can do.
-- Rick Schubert ([email protected])
28-Aug-89 17:00:57-PDT,1490;000000000000
Date: Mon, 28 Aug 89 16:57:20 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 28-Aug-89 16:30:05
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 28 Aug 89 16:29:56 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23692; Mon, 28 Aug 89 19:29:41 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: sad_news
Date: Mon Aug 28 19:22:22 1989
It is my very sad task to tell you that Joan Hall left her physical
form this past August 17. She had struggled against a cancer problem
for over two years, with apparent success until last month, when a
rapidly growing liver involvement overcame her.
I have not spent much time in the office since then. Jim Brodie and
P. J. Plauger have been handling any necessary X3J11 business in
the meantime.
Joan always cared passionately that we would be of service to people
and represent the highest possible integrity. We will attempt to see
that all our commitments to our customers and associates will be met
in a way that would make her proud. I thank you collectively for
the regard you had for her and for our work.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
-------
28-Aug-89 17:48:04-PDT,1977;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Mon, 28 Aug 89 17:47:51 PDT
Received: by decwrl.dec.com; id AB28671; Mon, 28 Aug 89 17:46:18 -0700
Date: Mon, 28 Aug 89 17:46:18 -0700
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-decwet
554 <[email protected]>... Remote protocol error
----- Unsent message follows -----
Received: by decwrl.dec.com; id AA25905; Mon, 28 Aug 89 16:44:33 -0700
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 28 Aug 89 16:29:56 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23692; Mon, 28 Aug 89 19:29:41 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: sad_news
Date: Mon Aug 28 19:22:22 1989
It is my very sad task to tell you that Joan Hall left her physical
form this past August 17. She had struggled against a cancer problem
for over two years, with apparent success until last month, when a
rapidly growing liver involvement overcame her.
I have not spent much time in the office since then. Jim Brodie and
P. J. Plauger have been handling any necessary X3J11 business in
the meantime.
Joan always cared passionately that we would be of service to people
and represent the highest possible integrity. We will attempt to see
that all our commitments to our customers and associates will be met
in a way that would make her proud. I thank you collectively for
the regard you had for her and for our work.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
28-Aug-89 18:25:09-PDT,1994;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Mon, 28 Aug 89 18:24:57 PDT
Received: by decwrl.dec.com; id AA01838; Mon, 28 Aug 89 18:23:27 -0700
Date: Mon, 28 Aug 89 18:23:27 -0700
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-tle
554 <[email protected]>,<[email protected]>... Remote protocol error
----- Unsent message follows -----
Received: by decwrl.dec.com; id AA25995; Mon, 28 Aug 89 16:45:10 -0700
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 28 Aug 89 16:29:56 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23692; Mon, 28 Aug 89 19:29:41 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: sad_news
Date: Mon Aug 28 19:22:22 1989
It is my very sad task to tell you that Joan Hall left her physical
form this past August 17. She had struggled against a cancer problem
for over two years, with apparent success until last month, when a
rapidly growing liver involvement overcame her.
I have not spent much time in the office since then. Jim Brodie and
P. J. Plauger have been handling any necessary X3J11 business in
the meantime.
Joan always cared passionately that we would be of service to people
and represent the highest possible integrity. We will attempt to see
that all our commitments to our customers and associates will be met
in a way that would make her proud. I thank you collectively for
the regard you had for her and for our work.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
29-Aug-89 12:53:48-PDT,2687;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 29 Aug 89 12:53:33 PDT
Received: from ukc.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22155; Tue, 29 Aug 89 15:53:29 -0400
Received: from axion.bt.co.uk by kestrel.Ukc.AC.UK via PSS (UKC CAMEL FTP)
id aa16110; 29 Aug 89 17:05 BST
Received: from kyns by zaphod.axion.bt.co.uk via UUCP channel id aa11858;
29 Aug 89 16:50 WET DST
To: [email protected]
Subject: mail problem
From: [email protected]
Date: Tue, 29 Aug 89 14:40:54 GMT
Message-Id: <[email protected]>
Trouble sending mail at `bsiqa', Tue Aug 29 14:40:53 1989
============ Transcript follows ============
neil
0 alias errors
No local user named "neil"
1 delivery errors
1 total errors
============== Message follows =============
>From kyns!axion!ukc.ac.uk!nic.ddn.mil!x3j11-relay Tue Aug 29 14:40:53 1989
Received: from ukc.ac.uk by zaphod.axion.bt.co.uk via PSS with NIFTP
id aa01424; 29 Aug 89 13:38 WET DST
Received: from mcvax by kestrel.Ukc.AC.UK via EUnet with authorised UUCP
id aa24161; 29 Aug 89 13:29 BST
Received: by mcvax.cwi.nl via EUnet; Tue, 29 Aug 89 14:10:41 +0200 (MET)
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA00719; Mon, 28 Aug 89 19:56:02 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 28 Aug 89 16:29:56 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23692; Mon, 28 Aug 89 19:29:41 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: sad_news
Date: Mon Aug 28 19:22:22 1989
Sender: [email protected]
It is my very sad task to tell you that Joan Hall left her physical
form this past August 17. She had struggled against a cancer problem
for over two years, with apparent success until last month, when a
rapidly growing liver involvement overcame her.
I have not spent much time in the office since then. Jim Brodie and
P. J. Plauger have been handling any necessary X3J11 business in
the meantime.
Joan always cared passionately that we would be of service to people
and represent the highest possible integrity. We will attempt to see
that all our commitments to our customers and associates will be met
in a way that would make her proud. I thank you collectively for
the regard you had for her and for our work.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
1-Sep-89 04:08:58-PDT,1849;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by NIC.DDN.MIL with TCP; Fri, 1 Sep 89 04:08:52 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AB13199; Fri, 1 Sep 89 03:24:36 PDT
Date: Fri, 1 Sep 89 03:24:36 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld: Host ringworld is down
----- Unsent message follows -----
Received: from NIC.DDN.MIL by Sun.COM (4.1/SMI-4.1)
id AA29652; Mon, 28 Aug 89 16:54:11 PDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 28 Aug 89 16:29:56 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23692; Mon, 28 Aug 89 19:29:41 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: sad_news
Date: Mon Aug 28 19:22:22 1989
It is my very sad task to tell you that Joan Hall left her physical
form this past August 17. She had struggled against a cancer problem
for over two years, with apparent success until last month, when a
rapidly growing liver involvement overcame her.
I have not spent much time in the office since then. Jim Brodie and
P. J. Plauger have been handling any necessary X3J11 business in
the meantime.
Joan always cared passionately that we would be of service to people
and represent the highest possible integrity. We will attempt to see
that all our commitments to our customers and associates will be met
in a way that would make her proud. I thank you collectively for
the regard you had for her and for our work.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
4-Sep-89 13:17:44-PDT,1687;000000000000
Date: Mon, 4 Sep 89 13:16:11 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 28-Aug-89 16:30:05
Message undeliverable and dequeued after 7 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 28 Aug 89 16:29:56 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23692; Mon, 28 Aug 89 19:29:41 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: sad_news
Date: Mon Aug 28 19:22:22 1989
It is my very sad task to tell you that Joan Hall left her physical
form this past August 17. She had struggled against a cancer problem
for over two years, with apparent success until last month, when a
rapidly growing liver involvement overcame her.
I have not spent much time in the office since then. Jim Brodie and
P. J. Plauger have been handling any necessary X3J11 business in
the meantime.
Joan always cared passionately that we would be of service to people
and represent the highest possible integrity. We will attempt to see
that all our commitments to our customers and associates will be met
in a way that would make her proud. I thank you collectively for
the regard you had for her and for our work.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
-------
9-Sep-89 14:40:43-PDT,541;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 9 Sep 89 14:38:25 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA13466; Sat, 9 Sep 89 17:27:06 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: Derek Jones
Date: Sat Sep 9 15:33:59 1989
Another X3J11 address, please:
uunet!ukc!knosof!derek Derek Jones Knowledge Software Ltd
Thanks very much, Ken.
- Tom
14-Oct-89 01:31:47-PDT,2362;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Sat, 14 Oct 89 01:31:38 PDT
Received: by decwrl.dec.com; id AA25615; Sat, 14 Oct 89 01:32:54 -0700
Date: Sat, 14 Oct 89 01:32:54 -0700
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-decwet
554 <[email protected]>... Remote protocol error
----- Unsent message follows -----
Received: by decwrl.dec.com; id AA25612; Sat, 14 Oct 89 01:32:54 -0700
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 13 Oct 89 07:57:00 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA24041; Fri, 13 Oct 89 10:57:11 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: request.89a
Date: Fri Oct 13 10:44:13 1989
I am beginning to outline some articles that discuss
the new official (as of the future article-release date)
ANSI Standard for C.
What kind of questions are people asking you about ANSI C?
What concerns do your users have?
Here are a few of my current notes for the UNIX-related article:
What preparations does a project need to make to transition from
old UNIX (V.3 or 4.3 or other POSIX) C to full ANSI C?
What tools are available to help with any transition difficulties?
How much more restrictive is strict-ANSI (for any environment at all)
portability vs portability to a System V or POSIX or X/OPEN
environment?
If you have any information on these questions, or other questions
to propose, please beam them to me. Thanks for your comments.
By the way, the X3J11 situation is that a meeting has been scheduled
for the panel to hear the procedural appeal; it is set for 20 October.
We certainly expect that X3J11 and X3 will be upheld by the panel,
but there is not much more I can tell you. If all goes well, we will
reach the 15 December meeting of ANSI Board of Standards Review.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
14-Oct-89 01:31:58-PDT,2379;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Sat, 14 Oct 89 01:31:53 PDT
Received: by decwrl.dec.com; id AA25634; Sat, 14 Oct 89 01:33:09 -0700
Date: Sat, 14 Oct 89 01:33:09 -0700
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-tle
554 <[email protected]>,<[email protected]>... Remote protocol error
----- Unsent message follows -----
Received: by decwrl.dec.com; id AA25628; Sat, 14 Oct 89 01:33:09 -0700
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 13 Oct 89 07:57:00 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA24041; Fri, 13 Oct 89 10:57:11 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: request.89a
Date: Fri Oct 13 10:44:13 1989
I am beginning to outline some articles that discuss
the new official (as of the future article-release date)
ANSI Standard for C.
What kind of questions are people asking you about ANSI C?
What concerns do your users have?
Here are a few of my current notes for the UNIX-related article:
What preparations does a project need to make to transition from
old UNIX (V.3 or 4.3 or other POSIX) C to full ANSI C?
What tools are available to help with any transition difficulties?
How much more restrictive is strict-ANSI (for any environment at all)
portability vs portability to a System V or POSIX or X/OPEN
environment?
If you have any information on these questions, or other questions
to propose, please beam them to me. Thanks for your comments.
By the way, the X3J11 situation is that a meeting has been scheduled
for the panel to hear the procedural appeal; it is set for 20 October.
We certainly expect that X3J11 and X3 will be upheld by the panel,
but there is not much more I can tell you. If all goes well, we will
reach the 15 December meeting of ANSI Board of Standards Review.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
14-Oct-89 01:56:47-PDT,1875;000000000000
Date: Sat, 14 Oct 89 01:54:20 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Oct-89 08:00:41
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 13 Oct 89 07:57:00 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA24041; Fri, 13 Oct 89 10:57:11 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: request.89a
Date: Fri Oct 13 10:44:13 1989
I am beginning to outline some articles that discuss
the new official (as of the future article-release date)
ANSI Standard for C.
What kind of questions are people asking you about ANSI C?
What concerns do your users have?
Here are a few of my current notes for the UNIX-related article:
What preparations does a project need to make to transition from
old UNIX (V.3 or 4.3 or other POSIX) C to full ANSI C?
What tools are available to help with any transition difficulties?
How much more restrictive is strict-ANSI (for any environment at all)
portability vs portability to a System V or POSIX or X/OPEN
environment?
If you have any information on these questions, or other questions
to propose, please beam them to me. Thanks for your comments.
By the way, the X3J11 situation is that a meeting has been scheduled
for the panel to hear the procedural appeal; it is set for 20 October.
We certainly expect that X3J11 and X3 will be upheld by the panel,
but there is not much more I can tell you. If all goes well, we will
reach the 15 December meeting of ANSI Board of Standards Review.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
-------
14-Oct-89 03:24:27-PDT,2598;000000000000
Return-Path: <[email protected]>
Received: from css.itd.nrl.navy.mil by NIC.DDN.MIL with TCP; Sat, 14 Oct 89 03:24:20 PDT
Received: by css.itd.nrl.navy.mil (5.61/1.34)
id AA22711; Sat, 14 Oct 89 06:25:27 -0400
Received: by sae.com (3.2/SMI-3.2)
id AB16586; Sat, 14 Oct 89 05:29:23 EDT
Date: Sat, 14 Oct 89 05:29:23 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Bad usage
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
cannot open database /home/sae/Overhead/jim/.vacation
vacation: No message to send
500 "| /usr/ucb/vacation jim"... Bad usage
----- Unsent message follows -----
Return-Path: <nrl-css!NIC.DDN.MIL!X3J11-RELAY>
Received: by sae.com (3.2/SMI-3.2)
id AA16582; Sat, 14 Oct 89 05:29:23 EDT
Received: from nic.ddn.mil by css.itd.nrl.navy.mil (5.61/1.34)
id AA22465; Sat, 14 Oct 89 04:32:19 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 13 Oct 89 07:57:00 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA24041; Fri, 13 Oct 89 10:57:11 -0400
From: nrl-css!uunet.uu.net!plumhall!root
Message-Id: <[email protected]>
To: [email protected]
Subject: request.89a
Date: Fri Oct 13 10:44:13 1989
I am beginning to outline some articles that discuss
the new official (as of the future article-release date)
ANSI Standard for C.
What kind of questions are people asking you about ANSI C?
What concerns do your users have?
Here are a few of my current notes for the UNIX-related article:
What preparations does a project need to make to transition from
old UNIX (V.3 or 4.3 or other POSIX) C to full ANSI C?
What tools are available to help with any transition difficulties?
How much more restrictive is strict-ANSI (for any environment at all)
portability vs portability to a System V or POSIX or X/OPEN
environment?
If you have any information on these questions, or other questions
to propose, please beam them to me. Thanks for your comments.
By the way, the X3J11 situation is that a meeting has been scheduled
for the panel to hear the procedural appeal; it is set for 20 October.
We certainly expect that X3J11 and X3 will be upheld by the panel,
but there is not much more I can tell you. If all goes well, we will
reach the 15 December meeting of ANSI Board of Standards Review.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
14-Oct-89 03:24:31-PDT,2849;000000000000
Return-Path: <[email protected]>
Received: from css.itd.nrl.navy.mil by NIC.DDN.MIL with TCP; Sat, 14 Oct 89 03:24:22 PDT
Received: by css.itd.nrl.navy.mil (5.61/1.34)
id AA22716; Sat, 14 Oct 89 06:25:31 -0400
Received: from callisto.sae.com by sae.com (3.2/SMI-3.2)
id AA16594; Sat, 14 Oct 89 05:29:38 EDT
Received: from sae.com by callisto.sae.com (3.2/SMI-3.2)
id AB08647; Sat, 14 Oct 89 05:29:02 EDT
Date: Sat, 14 Oct 89 05:29:02 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Bad usage
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
cannot open database /home/sae/Overhead/jim/.vacation
vacation: No message to send
500 "| /usr/ucb/vacation jim"... Bad usage
----- Unsent message follows -----
Return-Path: <nrl-css!NIC.DDN.MIL!X3J11-RELAY>
Received: from sae.com by callisto.sae.com (3.2/SMI-3.2)
id AA08645; Sat, 14 Oct 89 05:29:02 EDT
Received: by sae.com (3.2/SMI-3.2)
id AA16582; Sat, 14 Oct 89 05:29:23 EDT
Received: from nic.ddn.mil by css.itd.nrl.navy.mil (5.61/1.34)
id AA22465; Sat, 14 Oct 89 04:32:19 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 13 Oct 89 07:57:00 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA24041; Fri, 13 Oct 89 10:57:11 -0400
From: nrl-css!uunet.uu.net!plumhall!root
Message-Id: <[email protected]>
To: [email protected]
Subject: request.89a
Date: Fri Oct 13 10:44:13 1989
I am beginning to outline some articles that discuss
the new official (as of the future article-release date)
ANSI Standard for C.
What kind of questions are people asking you about ANSI C?
What concerns do your users have?
Here are a few of my current notes for the UNIX-related article:
What preparations does a project need to make to transition from
old UNIX (V.3 or 4.3 or other POSIX) C to full ANSI C?
What tools are available to help with any transition difficulties?
How much more restrictive is strict-ANSI (for any environment at all)
portability vs portability to a System V or POSIX or X/OPEN
environment?
If you have any information on these questions, or other questions
to propose, please beam them to me. Thanks for your comments.
By the way, the X3J11 situation is that a meeting has been scheduled
for the panel to hear the procedural appeal; it is set for 20 October.
We certainly expect that X3J11 and X3 will be upheld by the panel,
but there is not much more I can tell you. If all goes well, we will
reach the 15 December meeting of ANSI Board of Standards Review.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
17-Oct-89 16:50:07-PDT,2263;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by NIC.DDN.MIL with TCP; Tue, 17 Oct 89 14:56:35 PDT
Received: by Sun.COM (4.1/SMI-4.1)
id AB13379; Tue, 17 Oct 89 01:54:17 PDT
Date: Tue, 17 Oct 89 01:54:17 PDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld.eng.sun.com.: Host ringworld.eng.sun.com. is down
----- Unsent message follows -----
Received: from NIC.DDN.MIL by Sun.COM (4.1/SMI-4.1)
id AA13401; Sat, 14 Oct 89 01:53:06 PDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 13 Oct 89 07:57:00 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA24041; Fri, 13 Oct 89 10:57:11 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: request.89a
Date: Fri Oct 13 10:44:13 1989
I am beginning to outline some articles that discuss
the new official (as of the future article-release date)
ANSI Standard for C.
What kind of questions are people asking you about ANSI C?
What concerns do your users have?
Here are a few of my current notes for the UNIX-related article:
What preparations does a project need to make to transition from
old UNIX (V.3 or 4.3 or other POSIX) C to full ANSI C?
What tools are available to help with any transition difficulties?
How much more restrictive is strict-ANSI (for any environment at all)
portability vs portability to a System V or POSIX or X/OPEN
environment?
If you have any information on these questions, or other questions
to propose, please beam them to me. Thanks for your comments.
By the way, the X3J11 situation is that a meeting has been scheduled
for the panel to hear the procedural appeal; it is set for 20 October.
We certainly expect that X3J11 and X3 will be upheld by the panel,
but there is not much more I can tell you. If all goes well, we will
reach the 15 December meeting of ANSI Board of Standards Review.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
19-Oct-89 16:53:20-PDT,2025;000000000000
Date: Thu, 19 Oct 89 11:16:55 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Oct-89 08:00:41
Message undeliverable and dequeued after 6 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 13 Oct 89 07:57:00 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA24041; Fri, 13 Oct 89 10:57:11 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: request.89a
Date: Fri Oct 13 10:44:13 1989
I am beginning to outline some articles that discuss
the new official (as of the future article-release date)
ANSI Standard for C.
What kind of questions are people asking you about ANSI C?
What concerns do your users have?
Here are a few of my current notes for the UNIX-related article:
What preparations does a project need to make to transition from
old UNIX (V.3 or 4.3 or other POSIX) C to full ANSI C?
What tools are available to help with any transition difficulties?
How much more restrictive is strict-ANSI (for any environment at all)
portability vs portability to a System V or POSIX or X/OPEN
environment?
If you have any information on these questions, or other questions
to propose, please beam them to me. Thanks for your comments.
By the way, the X3J11 situation is that a meeting has been scheduled
for the panel to hear the procedural appeal; it is set for 20 October.
We certainly expect that X3J11 and X3 will be upheld by the panel,
but there is not much more I can tell you. If all goes well, we will
reach the 15 December meeting of ANSI Board of Standards Review.
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
-------
25-Oct-89 22:09:19-PDT,808;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 25 Oct 89 22:08:05 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA00667; Thu, 26 Oct 89 01:05:03 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: J11 addresses
Date: Thu Oct 26 00:55:49 1989
These I think I have sent already:
Ed Keizer uunet!cs.vu.nl!keie
Jim Blondeau [email protected]
Carl Sutton [email protected]
Tom Pennello sun!acad!metaware!tom
Rick Schubert [email protected]
This one is new:
Walter Nielsen [email protected]
Would you be so kind as to send me another complete list?
Thanks, Ken.
- Tom Plum
27-Oct-89 07:37:04-PDT,527;000000000000
Return-Path: <[email protected]>
Received: from osf.osf.org by NIC.DDN.MIL with TCP; Fri, 27 Oct 89 07:36:39 PDT
Received: from osf.osf.org by osf.osf.org (5.61/OSF 0.9)
id AA22774; Fri, 27 Oct 89 10:36:34 -0400
Message-Id: <[email protected]>
To: [email protected]
Subject: Change to Mailing List
Date: Fri, 27 Oct 89 10:36:31 -0400
From: [email protected]
Please change my mailing list from:
[email protected]
to:
[email protected]
This is effective immediately. Thank you.
-Andy Johnson
30-Oct-89 23:17:43-PST,2169;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Mon, 30 Oct 89 23:17:38 PST
Received: by decwrl.dec.com; id AA03856; Mon, 30 Oct 89 23:18:36 -0800
Date: Mon, 30 Oct 89 23:18:36 -0800
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-tle
554 <[email protected]>,<[email protected]>... Remote protocol error
----- Unsent message follows -----
Received: by decwrl.dec.com; id AA03854; Mon, 30 Oct 89 23:18:36 -0800
Received: from uunet.uu.net ([192.48.96.2]) by NIC.DDN.MIL with TCP; Mon, 30 Oct 89 11:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA27600; Mon, 30 Oct 89 14:16:29 -0500
Date: Mon, 30 Oct 89 12:43:38 EST
From: [email protected] (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#[email protected]>
To: [email protected]
Until recently I had two postal addresses, my home (Swans Neck Way)
and a business PO box (Michael Faraday Drive.) Effective immediately,
the Michael Faraday Drive address is discontinued, however, mail will
be forwarded for a while. Please use Swans Neck Way in future. The
complete address is shown below.
Rex
----------------------------------------------------------------------------
******** NEW POSTAL ADDRESS EFFECTIVE OCT 16th
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL | 2051 Swans Neck Way
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22091, USA
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
30-Oct-89 23:19:39-PST,2152;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Mon, 30 Oct 89 23:19:32 PST
Received: by decwrl.dec.com; id AA03849; Mon, 30 Oct 89 23:18:29 -0800
Date: Mon, 30 Oct 89 23:18:29 -0800
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-decwet
554 <[email protected]>... Remote protocol error
----- Unsent message follows -----
Received: by decwrl.dec.com; id AA03847; Mon, 30 Oct 89 23:18:29 -0800
Received: from uunet.uu.net ([192.48.96.2]) by NIC.DDN.MIL with TCP; Mon, 30 Oct 89 11:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA27600; Mon, 30 Oct 89 14:16:29 -0500
Date: Mon, 30 Oct 89 12:43:38 EST
From: [email protected] (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#[email protected]>
To: [email protected]
Until recently I had two postal addresses, my home (Swans Neck Way)
and a business PO box (Michael Faraday Drive.) Effective immediately,
the Michael Faraday Drive address is discontinued, however, mail will
be forwarded for a while. Please use Swans Neck Way in future. The
complete address is shown below.
Rex
----------------------------------------------------------------------------
******** NEW POSTAL ADDRESS EFFECTIVE OCT 16th
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL | 2051 Swans Neck Way
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22091, USA
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
30-Oct-89 23:34:27-PST,1665;000000000000
Date: Mon, 30 Oct 89 23:30:45 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 30-Oct-89 14:38:37
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net ([192.48.96.2]) by NIC.DDN.MIL with TCP; Mon, 30 Oct 89 11:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA27600; Mon, 30 Oct 89 14:16:29 -0500
Date: Mon, 30 Oct 89 12:43:38 EST
From: [email protected] (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#[email protected]>
To: [email protected]
Until recently I had two postal addresses, my home (Swans Neck Way)
and a business PO box (Michael Faraday Drive.) Effective immediately,
the Michael Faraday Drive address is discontinued, however, mail will
be forwarded for a while. Please use Swans Neck Way in future. The
complete address is shown below.
Rex
----------------------------------------------------------------------------
******** NEW POSTAL ADDRESS EFFECTIVE OCT 16th
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL | 2051 Swans Neck Way
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22091, USA
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
2-Nov-89 23:58:23-PST,2050;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by NIC.DDN.MIL with TCP; Thu, 2 Nov 89 23:58:15 PST
Received: by Sun.COM (4.1/SMI-4.1)
id AA17771; Thu, 2 Nov 89 23:58:09 PST
Date: Thu, 2 Nov 89 23:58:09 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 ringworld.eng.sun.com.: Host ringworld.eng.sun.com. is down
----- Unsent message follows -----
Received: from NIC.DDN.MIL by Sun.COM (4.1/SMI-4.1)
id AA22912; Mon, 30 Oct 89 23:27:57 PST
Received: from uunet.uu.net ([192.48.96.2]) by NIC.DDN.MIL with TCP; Mon, 30 Oct 89 11:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA27600; Mon, 30 Oct 89 14:16:29 -0500
Date: Mon, 30 Oct 89 12:43:38 EST
From: [email protected] (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#[email protected]>
To: [email protected]
Until recently I had two postal addresses, my home (Swans Neck Way)
and a business PO box (Michael Faraday Drive.) Effective immediately,
the Michael Faraday Drive address is discontinued, however, mail will
be forwarded for a while. Please use Swans Neck Way in future. The
complete address is shown below.
Rex
----------------------------------------------------------------------------
******** NEW POSTAL ADDRESS EFFECTIVE OCT 16th
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL | 2051 Swans Neck Way
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22091, USA
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
8-Nov-89 21:22:33-PST,1814;000000000000
Date: Wed, 8 Nov 89 21:17:39 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 30-Oct-89 14:38:37
Message undeliverable and dequeued after 9 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net ([192.48.96.2]) by NIC.DDN.MIL with TCP; Mon, 30 Oct 89 11:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA27600; Mon, 30 Oct 89 14:16:29 -0500
Date: Mon, 30 Oct 89 12:43:38 EST
From: [email protected] (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#[email protected]>
To: [email protected]
Until recently I had two postal addresses, my home (Swans Neck Way)
and a business PO box (Michael Faraday Drive.) Effective immediately,
the Michael Faraday Drive address is discontinued, however, mail will
be forwarded for a while. Please use Swans Neck Way in future. The
complete address is shown below.
Rex
----------------------------------------------------------------------------
******** NEW POSTAL ADDRESS EFFECTIVE OCT 16th
----------------------------------------------------------------------------
Rex Jaeschke | C Users Journal | Journal of C Language Translation
(703) 860-0091 | DEC PROFESSIONAL | 2051 Swans Neck Way
uunet!aussie!rex | Programmers Journal | Reston, Virginia 22091, USA
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
21-Dec-89 12:09:43-PST,643;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 21 Dec 89 12:08:18 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA03529; Thu, 21 Dec 89 15:08:03 -0500
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: new names for J11
Date: Thu Dec 21 00:15:36 1989
! Wendy Merrill ! [email protected]
! Sheryl Horowitz ! [email protected]
Thomas Plum 609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum OR [email protected]
22-Dec-89 22:17:50-PST,2161;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Fri, 22 Dec 89 22:17:45 PST
Received: by decwrl.dec.com; id AA10073; Fri, 22 Dec 89 22:17:27 -0800
Date: Fri, 22 Dec 89 22:17:27 -0800
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-tle
554 <[email protected]>... Remote protocol error
While talking to /usr/bin/mail11v3:
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-tle
554 <[email protected]>... Remote protocol error
----- Unsent message follows -----
Received: by decwrl.dec.com; id AA10070; Fri, 22 Dec 89 22:17:27 -0800
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 22 Dec 89 22:03:49 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22648; Sat, 23 Dec 89 01:03:28 -0500
From: [email protected]
Message-Id: <[email protected]>
To: [email protected], [email protected],
[email protected], [email protected],
[email protected],
[email protected], [email protected],
[email protected], [email protected]
Subject: Approved!
Date: Sat Dec 23 01:00:34 1989
I have been informed verbally by Jean-Paul Emard, Director of the
X3 Standards Secretariat, that the X3J11 draft was unanimously(!)
approved by the ANSI Board of Standards Review on 14 December 1989.
There appears to be high probability that an appeal will be filed with
them. If so, I understand that the appeal will be resolved at their
February meeting. We still expect that approval will be completed by
the time of our March meeting.
Vice-Chair, X3J11:
Thomas Plum Plum Hall Inc, 1 Spruce Av, Cardiff NJ 08232 USA
609-927-3770 uunet!plumhall!plum OR [email protected]
22-Dec-89 22:17:53-PST,2003;000000000000
Return-Path: <[email protected]>
Received: from decwrl.dec.com by NIC.DDN.MIL with TCP; Fri, 22 Dec 89 22:17:44 PST
Received: by decwrl.dec.com; id AA10055; Fri, 22 Dec 89 22:17:15 -0800
Date: Fri, 22 Dec 89 22:17:15 -0800
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<[email protected]>
<<< 559 No such node as dec-decwet
554 <[email protected]>... Remote protocol error
----- Unsent message follows -----
Received: by decwrl.dec.com; id AA10053; Fri, 22 Dec 89 22:17:15 -0800
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 22 Dec 89 22:03:49 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22648; Sat, 23 Dec 89 01:03:28 -0500
From: [email protected]
Message-Id: <[email protected]>
To: [email protected], [email protected],
[email protected], [email protected],
[email protected],
[email protected], [email protected],
[email protected], [email protected]
Subject: Approved!
Date: Sat Dec 23 01:00:34 1989
I have been informed verbally by Jean-Paul Emard, Director of the
X3 Standards Secretariat, that the X3J11 draft was unanimously(!)
approved by the ANSI Board of Standards Review on 14 December 1989.
There appears to be high probability that an appeal will be filed with
them. If so, I understand that the appeal will be resolved at their
February meeting. We still expect that approval will be completed by
the time of our March meeting.
Vice-Chair, X3J11:
Thomas Plum Plum Hall Inc, 1 Spruce Av, Cardiff NJ 08232 USA
609-927-3770 uunet!plumhall!plum OR [email protected]
22-Dec-89 22:33:30-PST,1516;000000000000
Date: Fri, 22 Dec 89 22:29:53 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 22-Dec-89 22:04:00
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 22 Dec 89 22:03:49 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22648; Sat, 23 Dec 89 01:03:28 -0500
From: [email protected]
Message-Id: <[email protected]>
To: [email protected], [email protected],
[email protected], [email protected],
[email protected],
[email protected], [email protected],
[email protected], [email protected]
Subject: Approved!
Date: Sat Dec 23 01:00:34 1989
I have been informed verbally by Jean-Paul Emard, Director of the
X3 Standards Secretariat, that the X3J11 draft was unanimously(!)
approved by the ANSI Board of Standards Review on 14 December 1989.
There appears to be high probability that an appeal will be filed with
them. If so, I understand that the appeal will be resolved at their
February meeting. We still expect that approval will be completed by
the time of our March meeting.
Vice-Chair, X3J11:
Thomas Plum Plum Hall Inc, 1 Spruce Av, Cardiff NJ 08232 USA
609-927-3770 uunet!plumhall!plum OR [email protected]
-------
26-Dec-89 15:48:51-PST,1961;000000000000
Return-Path: <[email protected]>
Received: from Sun.COM by NIC.DDN.MIL with TCP; Tue, 26 Dec 89 15:48:41 PST
Received: by Sun.COM (4.1/SMI-4.1)
id AJ00112; Tue, 26 Dec 89 10:36:40 PST
Date: Tue, 26 Dec 89 10:36:40 PST
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <[email protected]>
To: <[email protected]>
----- Transcript of session follows -----
421 smile.eng.sun.com.: Host smile.eng.sun.com. is down
421 ringworld.eng.sun.com.: Host ringworld.eng.sun.com. is down
----- Unsent message follows -----
Received: from NIC.DDN.MIL by Sun.COM (4.1/SMI-4.1)
id AA04746; Fri, 22 Dec 89 22:26:39 PST
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 22 Dec 89 22:03:49 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22648; Sat, 23 Dec 89 01:03:28 -0500
From: [email protected]
Message-Id: <[email protected]>
To: [email protected], [email protected],
[email protected], [email protected],
[email protected],
[email protected], [email protected],
[email protected], [email protected]
Subject: Approved!
Date: Sat Dec 23 01:00:34 1989
I have been informed verbally by Jean-Paul Emard, Director of the
X3 Standards Secretariat, that the X3J11 draft was unanimously(!)
approved by the ANSI Board of Standards Review on 14 December 1989.
There appears to be high probability that an appeal will be filed with
them. If so, I understand that the appeal will be resolved at their
February meeting. We still expect that approval will be completed by
the time of our March meeting.
Vice-Chair, X3J11:
Thomas Plum Plum Hall Inc, 1 Spruce Av, Cardiff NJ 08232 USA
609-927-3770 uunet!plumhall!plum OR [email protected]
28-Dec-89 08:38:50-PST,1627;000000000000
Date: Thu, 28 Dec 89 08:36:09 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 22-Dec-89 22:04:00
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 22 Dec 89 22:03:49 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22648; Sat, 23 Dec 89 01:03:28 -0500
From: [email protected]
Message-Id: <[email protected]>
To: [email protected], [email protected],
[email protected], [email protected],
[email protected],
[email protected], [email protected],
[email protected], [email protected]
Subject: Approved!
Date: Sat Dec 23 01:00:34 1989
I have been informed verbally by Jean-Paul Emard, Director of the
X3 Standards Secretariat, that the X3J11 draft was unanimously(!)
approved by the ANSI Board of Standards Review on 14 December 1989.
There appears to be high probability that an appeal will be filed with
them. If so, I understand that the appeal will be resolved at their
February meeting. We still expect that approval will be completed by
the time of our March meeting.
Vice-Chair, X3J11:
Thomas Plum Plum Hall Inc, 1 Spruce Av, Cardiff NJ 08232 USA
609-927-3770 uunet!plumhall!plum OR [email protected]
-------
28-Dec-89 11:14:08-PST,727;000000000000
Return-Path: <[email protected]>
Received: from osf.osf.org by NIC.DDN.MIL with TCP; Thu, 28 Dec 89 11:13:58 PST
Received: from osf.osf.org by osf.osf.org (5.61/OSF 0.9)
id AA23285; Thu, 28 Dec 89 13:02:19 -0500
Message-Id: <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: Change of address
Date: Thu, 28 Dec 89 13:02:17 -0500
From: [email protected]
I had sent a request earlier, but it didn't seem to be acted upon.
Please change:
[email protected]
to:
[email protected]
in the X3J11 mailing list. I am getting mail forwarded for now, but that will
be discontinued in the near future, and I will lose any subsequent mail.
Thank you.
-AndyJ
19-Jan-90 10:43:31-PST,1929;000000000000
Return-Path: <[email protected]>
Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Fri, 19 Jan 90 10:42:53 PST
Received: by decpa.pa.dec.com; id AA14068; Fri, 19 Jan 90 10:40:36 -0800
Date: Fri, 19 Jan 90 10:40:36 -0800
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 dec-decwet.dec.com (tcp)... 550 Host unknown
554 <[email protected]>... 550 Host unknown (Valid name but no A or MX)
----- Unsent message follows -----
Received: by decpa.pa.dec.com; id AA14049; Fri, 19 Jan 90 10:40:36 -0800
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 18 Jan 90 17:03:17 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA04919; Thu, 18 Jan 90 20:03:13 -0500
Date: Wed, 17 Jan 90 17:32:08 EST
From: plum%[email protected] (Thomas Plum)
Subject: No appeals; FINAL!
Message-Id: <9001171732.0.UUL1.3#[email protected]>
To: [email protected]
By telephone conversation with Louise Germani,
at ANSI Board of Standards Review, I have confirmed the news given to me
yesterday by Jean Paul Emard at X3:
The time allowed for receipt of appeals to ANSI has expired.
No appeals have been received.
The approval by ANSI BSR is official.
The C Standard will be known as ANS X3.159-1989, because the approval
meeting was 14 December 1989.
I convey this news to you with great, and mixed, emotions.
Let me just express, on behalf of everyone, to everyone,
thanks for everything that was done to bring about this long-delayed result.
PS: My apologies if you had trouble reaching plumhall.uu.net last week;
we had a series of hardware problems. Access should now be reliable.
Thomas Plum, Vice-Chair X3J11
[email protected] (USA) 609-927-3770
19-Jan-90 10:44:21-PST,1946;000000000000
Return-Path: <[email protected]>
Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Fri, 19 Jan 90 10:43:51 PST
Received: by decpa.pa.dec.com; id AA14113; Fri, 19 Jan 90 10:41:12 -0800
Date: Fri, 19 Jan 90 10:41:12 -0800
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 dec-tle.dec.com (tcp)... 550 Host unknown
554 <[email protected]>,<[email protected]>... 550 Host unknown (Valid name but no A or MX)
----- Unsent message follows -----
Received: by decpa.pa.dec.com; id AA14085; Fri, 19 Jan 90 10:41:12 -0800
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 18 Jan 90 17:03:17 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA04919; Thu, 18 Jan 90 20:03:13 -0500
Date: Wed, 17 Jan 90 17:32:08 EST
From: plum%[email protected] (Thomas Plum)
Subject: No appeals; FINAL!
Message-Id: <9001171732.0.UUL1.3#[email protected]>
To: [email protected]
By telephone conversation with Louise Germani,
at ANSI Board of Standards Review, I have confirmed the news given to me
yesterday by Jean Paul Emard at X3:
The time allowed for receipt of appeals to ANSI has expired.
No appeals have been received.
The approval by ANSI BSR is official.
The C Standard will be known as ANS X3.159-1989, because the approval
meeting was 14 December 1989.
I convey this news to you with great, and mixed, emotions.
Let me just express, on behalf of everyone, to everyone,
thanks for everything that was done to bring about this long-delayed result.
PS: My apologies if you had trouble reaching plumhall.uu.net last week;
we had a series of hardware problems. Access should now be reliable.
Thomas Plum, Vice-Chair X3J11
[email protected] (USA) 609-927-3770
19-Jan-90 11:24:13-PST,1532;000000000000
Date: Fri, 19 Jan 90 11:22:56 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Jan-90 17:04:11
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 18 Jan 90 17:03:17 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA04919; Thu, 18 Jan 90 20:03:13 -0500
Date: Wed, 17 Jan 90 17:32:08 EST
From: plum%[email protected] (Thomas Plum)
Subject: No appeals; FINAL!
Message-Id: <9001171732.0.UUL1.3#[email protected]>
To: [email protected]
By telephone conversation with Louise Germani,
at ANSI Board of Standards Review, I have confirmed the news given to me
yesterday by Jean Paul Emard at X3:
The time allowed for receipt of appeals to ANSI has expired.
No appeals have been received.
The approval by ANSI BSR is official.
The C Standard will be known as ANS X3.159-1989, because the approval
meeting was 14 December 1989.
I convey this news to you with great, and mixed, emotions.
Let me just express, on behalf of everyone, to everyone,
thanks for everything that was done to bring about this long-delayed result.
PS: My apologies if you had trouble reaching plumhall.uu.net last week;
we had a series of hardware problems. Access should now be reliable.
Thomas Plum, Vice-Chair X3J11
[email protected] (USA) 609-927-3770
-------
25-Jan-90 17:33:20-PST,1591;000000000000
Date: Thu, 25 Jan 90 17:30:02 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Jan-90 17:04:11
Message undeliverable and dequeued after 7 days:
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 18 Jan 90 17:03:17 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA04919; Thu, 18 Jan 90 20:03:13 -0500
Date: Wed, 17 Jan 90 17:32:08 EST
From: plum%[email protected] (Thomas Plum)
Subject: No appeals; FINAL!
Message-Id: <9001171732.0.UUL1.3#[email protected]>
To: [email protected]
By telephone conversation with Louise Germani,
at ANSI Board of Standards Review, I have confirmed the news given to me
yesterday by Jean Paul Emard at X3:
The time allowed for receipt of appeals to ANSI has expired.
No appeals have been received.
The approval by ANSI BSR is official.
The C Standard will be known as ANS X3.159-1989, because the approval
meeting was 14 December 1989.
I convey this news to you with great, and mixed, emotions.
Let me just express, on behalf of everyone, to everyone,
thanks for everything that was done to bring about this long-delayed result.
PS: My apologies if you had trouble reaching plumhall.uu.net last week;
we had a series of hardware problems. Access should now be reliable.
Thomas Plum, Vice-Chair X3J11
[email protected] (USA) 609-927-3770
-------
3-Feb-90 00:07:21-PST,4683;000000000000
Return-Path: <[email protected]>
Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Sat, 3 Feb 90 00:07:01 PST
Received: by decpa.pa.dec.com; id AA17927; Sat, 3 Feb 90 00:04:20 -0800
Date: Sat, 3 Feb 90 00:04:20 -0800
From: MAILER-DAEMON@decpa (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 dec-decwet.dec.com (tcp)... 550 Host unknown
554 <[email protected]>... 550 Host unknown (Valid name but no A or MX)
----- Unsent message follows -----
Received: by decpa.pa.dec.com; id AA17920; Sat, 3 Feb 90 00:04:20 -0800
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 2 Feb 90 19:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA08595; Fri, 2 Feb 90 22:09:09 -0500
Date: Fri, 2 Feb 90 15:49:10 EST
From: [email protected] (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#[email protected]>
To: [email protected]
%---------------------------------------------------------------
The following text will apear in Volume 1, number 4, March 1990, of
The Journal of C Language Translation. Although it was written by Rex
Jaeschke, it will apear as part of Jim Brodie's Standards Column.
It is reproduced here for your convenience as a service by the
Journal and for those of you who are are not Journal subscribers.
Please note this extract is Copyright 1990, Rex Jaeschke and all
rights are reserved.
This information is believed to be accurate as at February 2nd, 1990.
%---------------------------------------------------------------
The American National Standard for C has finally been approved.
The period for appeals before enactment of the standard has now
passed and actual publication of the standard should occur shortly.
(ANSI anticipates copies being available by late March.) The
Standard's official designation is ANSI X3.159-1989. To obtain a
copy, contact:
American National Standards Institute
Sales Department
1430 Broadway
New York, NY 10018
(212) 642-4900
fax (212) 302-1286
At press time, the price of the standard had not yet been determined.
{Interpretations Phase}
If you would like to formally submit a request for interpretation, do
so to:
X3 Secretariat
CBEMA
311 First Street N.W.
Suite 500
Washington, DC 20001-2178
Attn: Manager of Standards Processing
{The U.S. Government FIPS}
There is not yet a Federal Information Processing Standard (FIPS)
for C. Referencing a FIPS significantly simplifies the process of
using a language in a U.S. defense project. Now that the ANSI standard
for C has been approved the C FIPS should follow soon. Sometime in
February 1990 the FIPS proposal will be issued for a 90 day public
comment period. Assuming there are no objections, the FIPS is
presented to the U.S. Secretary of Commerce for signing. It is
expected this whole process will be completed during the Fall of
1990. This is then followed by a six month acceptance period after
which the FIPS becomes final. Note, however, that since the ANSI
Standard exists right now, a U.S. Government agency can require
conformance to that standard in RFPs right now! They do not need to
wait until a FIPS is produced.
{The Formal Validation Process}
On the U.S. front, activity in that direction has also begun in
earnest. According to the National Institute of Standards and
Technology (NIST) they issued a Request For Proposal (RFP) in late
January asking for submissions of C language validation test suites.
To get a copy of the solicitation for C language validation suite RFP
(Solicitation Number 52SBNB0C6O42) contact:
National Institute of Standards and Technology
Contracts Department
Gaithersburg, MD 20899
Note that the process of selecting or developing a validation suite is
not related to the FIPS. That is, the suite may be finalized
before or after a FIPS is produced.
%---------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
3-Feb-90 00:07:29-PST,4858;000000000000
Received: from Relay.Prime.COM ([129.122.1.1]) by NIC.DDN.MIL with TCP; Sat, 3 Feb 90 00:07:13 PST
Date: 03 Feb 90 03:09:34 EST
From: [email protected] (PDNmail version 2.3.x123)
Subject: returned mail
Message-Type: Return
Encoding: 6 text, message
To: <[email protected]>
Mail addressed to "[email protected]" could not be forwarded.
Service at S55.Prime.COM said:
550 Cannot write to mailbox; user not known
------- Unsent message follows -------
Received: from sh.prime.com by Relay.Prime.COM; 03 Feb 90 03:09:19 EST
Received: from Relay.Prime.COM by sh.prime.com (3.2/SMI-3.2)
id AA14027; Sat, 3 Feb 90 03:04:44 EST
Received: from NET.Prime.COM by Relay.Prime.COM; 03 Feb 90 03:09:07 EST
Received: from EN-C06.Prime.COM by NET.Prime.COM; 03 Feb 90 03:06:56 EST
Received: from NIC.DDN.MIL by EN-C06.Prime.COM; 03 Feb 90 03:11:45 EST
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 2 Feb 90 19:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA08595; Fri, 2 Feb 90 22:09:09 -0500
Date: Fri, 2 Feb 90 15:49:10 EST
From: [email protected] (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#[email protected]>
To: [email protected]
%---------------------------------------------------------------
The following text will apear in Volume 1, number 4, March 1990, of
The Journal of C Language Translation. Although it was written by Rex
Jaeschke, it will apear as part of Jim Brodie's Standards Column.
It is reproduced here for your convenience as a service by the
Journal and for those of you who are are not Journal subscribers.
Please note this extract is Copyright 1990, Rex Jaeschke and all
rights are reserved.
This information is believed to be accurate as at February 2nd, 1990.
%---------------------------------------------------------------
The American National Standard for C has finally been approved.
The period for appeals before enactment of the standard has now
passed and actual publication of the standard should occur shortly.
(ANSI anticipates copies being available by late March.) The
Standard's official designation is ANSI X3.159-1989. To obtain a
copy, contact:
American National Standards Institute
Sales Department
1430 Broadway
New York, NY 10018
(212) 642-4900
fax (212) 302-1286
At press time, the price of the standard had not yet been determined.
{Interpretations Phase}
If you would like to formally submit a request for interpretation, do
so to:
X3 Secretariat
CBEMA
311 First Street N.W.
Suite 500
Washington, DC 20001-2178
Attn: Manager of Standards Processing
{The U.S. Government FIPS}
There is not yet a Federal Information Processing Standard (FIPS)
for C. Referencing a FIPS significantly simplifies the process of
using a language in a U.S. defense project. Now that the ANSI standard
for C has been approved the C FIPS should follow soon. Sometime in
February 1990 the FIPS proposal will be issued for a 90 day public
comment period. Assuming there are no objections, the FIPS is
presented to the U.S. Secretary of Commerce for signing. It is
expected this whole process will be completed during the Fall of
1990. This is then followed by a six month acceptance period after
which the FIPS becomes final. Note, however, that since the ANSI
Standard exists right now, a U.S. Government agency can require
conformance to that standard in RFPs right now! They do not need to
wait until a FIPS is produced.
{The Formal Validation Process}
On the U.S. front, activity in that direction has also begun in
earnest. According to the National Institute of Standards and
Technology (NIST) they issued a Request For Proposal (RFP) in late
January asking for submissions of C language validation test suites.
To get a copy of the solicitation for C language validation suite RFP
(Solicitation Number 52SBNB0C6O42) contact:
National Institute of Standards and Technology
Contracts Department
Gaithersburg, MD 20899
Note that the process of selecting or developing a validation suite is
not related to the FIPS. That is, the suite may be finalized
before or after a FIPS is produced.
%---------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
3-Feb-90 00:25:08-PST,4299;000000000000
Date: Sat, 3 Feb 90 00:21:18 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 2-Feb-90 19:18:17
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 2 Feb 90 19:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA08595; Fri, 2 Feb 90 22:09:09 -0500
Date: Fri, 2 Feb 90 15:49:10 EST
From: [email protected] (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#[email protected]>
To: [email protected]
%---------------------------------------------------------------
The following text will apear in Volume 1, number 4, March 1990, of
The Journal of C Language Translation. Although it was written by Rex
Jaeschke, it will apear as part of Jim Brodie's Standards Column.
It is reproduced here for your convenience as a service by the
Journal and for those of you who are are not Journal subscribers.
Please note this extract is Copyright 1990, Rex Jaeschke and all
rights are reserved.
This information is believed to be accurate as at February 2nd, 1990.
%---------------------------------------------------------------
The American National Standard for C has finally been approved.
The period for appeals before enactment of the standard has now
passed and actual publication of the standard should occur shortly.
(ANSI anticipates copies being available by late March.) The
Standard's official designation is ANSI X3.159-1989. To obtain a
copy, contact:
American National Standards Institute
Sales Department
1430 Broadway
New York, NY 10018
(212) 642-4900
fax (212) 302-1286
At press time, the price of the standard had not yet been determined.
{Interpretations Phase}
If you would like to formally submit a request for interpretation, do
so to:
X3 Secretariat
CBEMA
311 First Street N.W.
Suite 500
Washington, DC 20001-2178
Attn: Manager of Standards Processing
{The U.S. Government FIPS}
There is not yet a Federal Information Processing Standard (FIPS)
for C. Referencing a FIPS significantly simplifies the process of
using a language in a U.S. defense project. Now that the ANSI standard
for C has been approved the C FIPS should follow soon. Sometime in
February 1990 the FIPS proposal will be issued for a 90 day public
comment period. Assuming there are no objections, the FIPS is
presented to the U.S. Secretary of Commerce for signing. It is
expected this whole process will be completed during the Fall of
1990. This is then followed by a six month acceptance period after
which the FIPS becomes final. Note, however, that since the ANSI
Standard exists right now, a U.S. Government agency can require
conformance to that standard in RFPs right now! They do not need to
wait until a FIPS is produced.
{The Formal Validation Process}
On the U.S. front, activity in that direction has also begun in
earnest. According to the National Institute of Standards and
Technology (NIST) they issued a Request For Proposal (RFP) in late
January asking for submissions of C language validation test suites.
To get a copy of the solicitation for C language validation suite RFP
(Solicitation Number 52SBNB0C6O42) contact:
National Institute of Standards and Technology
Contracts Department
Gaithersburg, MD 20899
Note that the process of selecting or developing a validation suite is
not related to the FIPS. That is, the suite may be finalized
before or after a FIPS is produced.
%---------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
3-Feb-90 23:34:04-PST,4711;000000000000
Return-Path: <[email protected]>
Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Sat, 3 Feb 90 23:33:33 PST
Received: by decpa.pa.dec.com; id AA17946; Sat, 3 Feb 90 00:04:46 -0800
Date: Sat, 3 Feb 90 00:04:46 -0800
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 dec-tle.dec.com (tcp)... 550 Host unknown
554 <[email protected]>,<[email protected]>... 550 Host unknown (Valid name but no A or MX)
----- Unsent message follows -----
Received: by decpa.pa.dec.com; id AA17933; Sat, 3 Feb 90 00:04:46 -0800
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 2 Feb 90 19:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA08595; Fri, 2 Feb 90 22:09:09 -0500
Date: Fri, 2 Feb 90 15:49:10 EST
From: [email protected] (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#[email protected]>
To: [email protected]
%---------------------------------------------------------------
The following text will apear in Volume 1, number 4, March 1990, of
The Journal of C Language Translation. Although it was written by Rex
Jaeschke, it will apear as part of Jim Brodie's Standards Column.
It is reproduced here for your convenience as a service by the
Journal and for those of you who are are not Journal subscribers.
Please note this extract is Copyright 1990, Rex Jaeschke and all
rights are reserved.
This information is believed to be accurate as at February 2nd, 1990.
%---------------------------------------------------------------
The American National Standard for C has finally been approved.
The period for appeals before enactment of the standard has now
passed and actual publication of the standard should occur shortly.
(ANSI anticipates copies being available by late March.) The
Standard's official designation is ANSI X3.159-1989. To obtain a
copy, contact:
American National Standards Institute
Sales Department
1430 Broadway
New York, NY 10018
(212) 642-4900
fax (212) 302-1286
At press time, the price of the standard had not yet been determined.
{Interpretations Phase}
If you would like to formally submit a request for interpretation, do
so to:
X3 Secretariat
CBEMA
311 First Street N.W.
Suite 500
Washington, DC 20001-2178
Attn: Manager of Standards Processing
{The U.S. Government FIPS}
There is not yet a Federal Information Processing Standard (FIPS)
for C. Referencing a FIPS significantly simplifies the process of
using a language in a U.S. defense project. Now that the ANSI standard
for C has been approved the C FIPS should follow soon. Sometime in
February 1990 the FIPS proposal will be issued for a 90 day public
comment period. Assuming there are no objections, the FIPS is
presented to the U.S. Secretary of Commerce for signing. It is
expected this whole process will be completed during the Fall of
1990. This is then followed by a six month acceptance period after
which the FIPS becomes final. Note, however, that since the ANSI
Standard exists right now, a U.S. Government agency can require
conformance to that standard in RFPs right now! They do not need to
wait until a FIPS is produced.
{The Formal Validation Process}
On the U.S. front, activity in that direction has also begun in
earnest. According to the National Institute of Standards and
Technology (NIST) they issued a Request For Proposal (RFP) in late
January asking for submissions of C language validation test suites.
To get a copy of the solicitation for C language validation suite RFP
(Solicitation Number 52SBNB0C6O42) contact:
National Institute of Standards and Technology
Contracts Department
Gaithersburg, MD 20899
Note that the process of selecting or developing a validation suite is
not related to the FIPS. That is, the suite may be finalized
before or after a FIPS is produced.
%---------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
4-Feb-90 14:57:32-PST,3324;000000000000
Return-Path: <[email protected]>
Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Sun, 4 Feb 90 14:57:18 PST
Received: by decpa.pa.dec.com; id AA08929; Sun, 4 Feb 90 14:56:40 -0800
Date: Sun, 4 Feb 90 14:56:40 -0800
From: MAILER-DAEMON@decpa (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 dec-decwet.dec.com (tcp)... 550 Host unknown
554 <[email protected]>... 550 Host unknown (Valid name but no A or MX)
----- Unsent message follows -----
Received: by decpa.pa.dec.com; id AA08927; Sun, 4 Feb 90 14:56:40 -0800
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 4 Feb 90 14:18:33 PST
Received: by uunet.uu.net (5.61/1.14)
id AA29698; Sun, 4 Feb 90 10:42:09 -0500
Date: Sat, 3 Feb 90 19:48:53 EST
From: [email protected] (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#[email protected]>
To: [email protected]
---------------------------------------------------------------------
Since late in 1989 we've heard much of the upheaval in the Eastern
European Bloc. Until you can relate to it personally, it's just
another news item. What's this to do with you? Well recently I
recieved a letter from a Senior Software Engineer in Romania. The
relevant extract follows:
Prior to, and during, the recent revolution in Romania we at the
Research Institute for Computers suffered much. Much hardware was
damaged or destroyed and we also lost considerable software and many
books.
I would be very grateful if you could help me, by appealing to your
readers, rebuild our collection of books and documentation on C,
C++, and expert systems. Also software and even hardware if
possible.
I have put together a shipment of books and manuals that I intend to
send. I encourage you to do the same. If you have any doubts about
export restrictions on certain items (hardware, for example) consult
your national Trade Commission or relevant government agency. Since
I know they are using Borland's Turbo C it appears they at least have
IBM-PC compatibles.
The address to send computer care packages is:
Doru Turturea
Research Institute for Computers
Strada Clucererului No 1, Sector 1
Bloc 40, Scarad
Bucuresti 71308
ROMANIA
Apart from doing a good deed for our colleagues abroad I'm sure some
in your marketing department would love the press coverage a generous
donation could bring. Think about it. Wouldn't your company like to
get a foot into the door of the newly opened Eastern Europe
marketplace?
---------------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
4-Feb-90 14:57:38-PST,3341;000000000000
Return-Path: <[email protected]>
Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Sun, 4 Feb 90 14:57:29 PST
Received: by decpa.pa.dec.com; id AA08935; Sun, 4 Feb 90 14:56:47 -0800
Date: Sun, 4 Feb 90 14:56:47 -0800
From: MAILER-DAEMON@decpa (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 dec-tle.dec.com (tcp)... 550 Host unknown
554 <[email protected]>,<[email protected]>... 550 Host unknown (Valid name but no A or MX)
----- Unsent message follows -----
Received: by decpa.pa.dec.com; id AA08933; Sun, 4 Feb 90 14:56:47 -0800
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 4 Feb 90 14:18:33 PST
Received: by uunet.uu.net (5.61/1.14)
id AA29698; Sun, 4 Feb 90 10:42:09 -0500
Date: Sat, 3 Feb 90 19:48:53 EST
From: [email protected] (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#[email protected]>
To: [email protected]
---------------------------------------------------------------------
Since late in 1989 we've heard much of the upheaval in the Eastern
European Bloc. Until you can relate to it personally, it's just
another news item. What's this to do with you? Well recently I
recieved a letter from a Senior Software Engineer in Romania. The
relevant extract follows:
Prior to, and during, the recent revolution in Romania we at the
Research Institute for Computers suffered much. Much hardware was
damaged or destroyed and we also lost considerable software and many
books.
I would be very grateful if you could help me, by appealing to your
readers, rebuild our collection of books and documentation on C,
C++, and expert systems. Also software and even hardware if
possible.
I have put together a shipment of books and manuals that I intend to
send. I encourage you to do the same. If you have any doubts about
export restrictions on certain items (hardware, for example) consult
your national Trade Commission or relevant government agency. Since
I know they are using Borland's Turbo C it appears they at least have
IBM-PC compatibles.
The address to send computer care packages is:
Doru Turturea
Research Institute for Computers
Strada Clucererului No 1, Sector 1
Bloc 40, Scarad
Bucuresti 71308
ROMANIA
Apart from doing a good deed for our colleagues abroad I'm sure some
in your marketing department would love the press coverage a generous
donation could bring. Think about it. Wouldn't your company like to
get a foot into the door of the newly opened Eastern Europe
marketplace?
---------------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
4-Feb-90 15:00:02-PST,3499;000000000000
Received: from Relay.Prime.COM ([129.122.1.1]) by NIC.DDN.MIL with TCP; Sun, 4 Feb 90 14:59:41 PST
Date: 04 Feb 90 18:01:55 EST
From: [email protected] (PDNmail version 2.3.x123)
Subject: returned mail
Message-Type: Return
Encoding: 6 text, message
To: <[email protected]>
Mail addressed to "[email protected]" could not be forwarded.
Service at S55.Prime.COM said:
550 Cannot write to mailbox; user not known
------- Unsent message follows -------
Received: from sh.prime.com by Relay.Prime.COM; 04 Feb 90 18:01:11 EST
Received: from Relay.Prime.COM by sh.prime.com (3.2/SMI-3.2)
id AA15133; Sun, 4 Feb 90 17:56:47 EST
Received: from NET.Prime.COM by Relay.Prime.COM; 04 Feb 90 18:00:59 EST
Received: from EN-C06.Prime.COM by NET.Prime.COM; 04 Feb 90 17:59:00 EST
Received: from NIC.DDN.MIL by EN-C06.Prime.COM; 04 Feb 90 18:03:48 EST
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 4 Feb 90 14:18:33 PST
Received: by uunet.uu.net (5.61/1.14)
id AA29698; Sun, 4 Feb 90 10:42:09 -0500
Date: Sat, 3 Feb 90 19:48:53 EST
From: [email protected] (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#[email protected]>
To: [email protected]
---------------------------------------------------------------------
Since late in 1989 we've heard much of the upheaval in the Eastern
European Bloc. Until you can relate to it personally, it's just
another news item. What's this to do with you? Well recently I
recieved a letter from a Senior Software Engineer in Romania. The
relevant extract follows:
Prior to, and during, the recent revolution in Romania we at the
Research Institute for Computers suffered much. Much hardware was
damaged or destroyed and we also lost considerable software and many
books.
I would be very grateful if you could help me, by appealing to your
readers, rebuild our collection of books and documentation on C,
C++, and expert systems. Also software and even hardware if
possible.
I have put together a shipment of books and manuals that I intend to
send. I encourage you to do the same. If you have any doubts about
export restrictions on certain items (hardware, for example) consult
your national Trade Commission or relevant government agency. Since
I know they are using Borland's Turbo C it appears they at least have
IBM-PC compatibles.
The address to send computer care packages is:
Doru Turturea
Research Institute for Computers
Strada Clucererului No 1, Sector 1
Bloc 40, Scarad
Bucuresti 71308
ROMANIA
Apart from doing a good deed for our colleagues abroad I'm sure some
in your marketing department would love the press coverage a generous
donation could bring. Think about it. Wouldn't your company like to
get a foot into the door of the newly opened Eastern Europe
marketplace?
---------------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
4-Feb-90 15:21:10-PST,2940;000000000000
Date: Sun, 4 Feb 90 15:16:41 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 4-Feb-90 14:18:51
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 4 Feb 90 14:18:33 PST
Received: by uunet.uu.net (5.61/1.14)
id AA29698; Sun, 4 Feb 90 10:42:09 -0500
Date: Sat, 3 Feb 90 19:48:53 EST
From: [email protected] (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#[email protected]>
To: [email protected]
---------------------------------------------------------------------
Since late in 1989 we've heard much of the upheaval in the Eastern
European Bloc. Until you can relate to it personally, it's just
another news item. What's this to do with you? Well recently I
recieved a letter from a Senior Software Engineer in Romania. The
relevant extract follows:
Prior to, and during, the recent revolution in Romania we at the
Research Institute for Computers suffered much. Much hardware was
damaged or destroyed and we also lost considerable software and many
books.
I would be very grateful if you could help me, by appealing to your
readers, rebuild our collection of books and documentation on C,
C++, and expert systems. Also software and even hardware if
possible.
I have put together a shipment of books and manuals that I intend to
send. I encourage you to do the same. If you have any doubts about
export restrictions on certain items (hardware, for example) consult
your national Trade Commission or relevant government agency. Since
I know they are using Borland's Turbo C it appears they at least have
IBM-PC compatibles.
The address to send computer care packages is:
Doru Turturea
Research Institute for Computers
Strada Clucererului No 1, Sector 1
Bloc 40, Scarad
Bucuresti 71308
ROMANIA
Apart from doing a good deed for our colleagues abroad I'm sure some
in your marketing department would love the press coverage a generous
donation could bring. Think about it. Wouldn't your company like to
get a foot into the door of the newly opened Eastern Europe
marketplace?
---------------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
5-Feb-90 09:24:39-PST,1731;000000000000
Return-Path: <[email protected]>
Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Mon, 5 Feb 90 09:24:17 PST
Received: by decpa.pa.dec.com; id AA27171; Mon, 5 Feb 90 09:23:32 -0800
Date: Mon, 5 Feb 90 09:23:32 -0800
From: MAILER-DAEMON@decpa (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 dec-decwet.dec.com (tcp)... 550 Host unknown
554 <[email protected]>... 550 Host unknown (Valid name but no A or MX)
----- Unsent message follows -----
Received: by decpa.pa.dec.com; id AA27168; Mon, 5 Feb 90 09:23:32 -0800
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 5 Feb 90 07:17:31 PST
Received: by uunet.uu.net (5.61/1.14)
id AA27930; Mon, 5 Feb 90 10:16:05 -0500
Received: from thor by sdrc; Mon, 5 Feb 90 10:10:13 est
Received: by thor; Mon, 5 Feb 90 09:57:19 EST
Date: Mon, 5 Feb 90 09:57:19 EST
From: Larry Jones <sdrc!scjones%[email protected]>
Message-Id: <9002051457.AA00211@thor>
To: [email protected]
Subject: GKS-3D C Language Binding
I have just received an interim copy of the GKS-3D C Language
Binding for review prior to a late March meeting of the commitee
that does graphic language bindings. If anyone would like a copy
to review, please let me know.
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC [email protected]
2000 Eastman Dr. BIX: ltl
Milford, OH 45150-2789 AT&T: (513) 576-2070
"You know how Einstein got bad grades as a kid? Well MINE are even WORSE!"
-Calvin
5-Feb-90 09:25:06-PST,1748;000000000000
Return-Path: <[email protected]>
Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Mon, 5 Feb 90 09:24:46 PST
Received: by decpa.pa.dec.com; id AA27188; Mon, 5 Feb 90 09:23:46 -0800
Date: Mon, 5 Feb 90 09:23:46 -0800
From: MAILER-DAEMON@decpa (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
550 dec-tle.dec.com (tcp)... 550 Host unknown
554 <[email protected]>,<[email protected]>... 550 Host unknown (Valid name but no A or MX)
----- Unsent message follows -----
Received: by decpa.pa.dec.com; id AA27179; Mon, 5 Feb 90 09:23:46 -0800
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 5 Feb 90 07:17:31 PST
Received: by uunet.uu.net (5.61/1.14)
id AA27930; Mon, 5 Feb 90 10:16:05 -0500
Received: from thor by sdrc; Mon, 5 Feb 90 10:10:13 est
Received: by thor; Mon, 5 Feb 90 09:57:19 EST
Date: Mon, 5 Feb 90 09:57:19 EST
From: Larry Jones <sdrc!scjones%[email protected]>
Message-Id: <9002051457.AA00211@thor>
To: [email protected]
Subject: GKS-3D C Language Binding
I have just received an interim copy of the GKS-3D C Language
Binding for review prior to a late March meeting of the commitee
that does graphic language bindings. If anyone would like a copy
to review, please let me know.
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC [email protected]
2000 Eastman Dr. BIX: ltl
Milford, OH 45150-2789 AT&T: (513) 576-2070
"You know how Einstein got bad grades as a kid? Well MINE are even WORSE!"
-Calvin
5-Feb-90 09:42:30-PST,1347;000000000000
Date: Mon, 5 Feb 90 09:41:02 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 5-Feb-90 07:17:40
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 5 Feb 90 07:17:31 PST
Received: by uunet.uu.net (5.61/1.14)
id AA27930; Mon, 5 Feb 90 10:16:05 -0500
Received: from thor by sdrc; Mon, 5 Feb 90 10:10:13 est
Received: by thor; Mon, 5 Feb 90 09:57:19 EST
Date: Mon, 5 Feb 90 09:57:19 EST
From: Larry Jones <sdrc!scjones%[email protected]>
Message-Id: <9002051457.AA00211@thor>
To: [email protected]
Subject: GKS-3D C Language Binding
I have just received an interim copy of the GKS-3D C Language
Binding for review prior to a late March meeting of the commitee
that does graphic language bindings. If anyone would like a copy
to review, please let me know.
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC [email protected]
2000 Eastman Dr. BIX: ltl
Milford, OH 45150-2789 AT&T: (513) 576-2070
"You know how Einstein got bad grades as a kid? Well MINE are even WORSE!"
-Calvin
-------
5-Feb-90 13:49:00-PST,1906;000000000000
Received: from Relay.Prime.COM ([129.122.1.1]) by NIC.DDN.MIL with TCP; Mon, 5 Feb 90 13:48:49 PST
Date: 05 Feb 90 16:51:47 EST
From: [email protected] (PDNmail version 2.3.x144)
Subject: returned mail
Message-Type: Return
Encoding: 6 text, message
To: <[email protected]>
Mail addressed to "[email protected]" could not be forwarded.
Service at S55.Prime.COM said:
550 Cannot write to mailbox; user not known
------- Unsent message follows -------
Received: from sh.prime.com by Relay.Prime.COM; 05 Feb 90 16:51:15 EST
Received: from Relay.Prime.COM by sh.prime.com (3.2/SMI-3.2)
id AA15911; Mon, 5 Feb 90 16:46:07 EST
Received: from NET.Prime.COM by Relay.Prime.COM; 05 Feb 90 16:51:04 EST
Received: from EN-C06.Prime.COM by NET.Prime.COM; 05 Feb 90 16:48:21 EST
Received: from NIC.DDN.MIL by EN-C06.Prime.COM; 05 Feb 90 16:49:36 EST
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 5 Feb 90 07:17:31 PST
Received: by uunet.uu.net (5.61/1.14)
id AA27930; Mon, 5 Feb 90 10:16:05 -0500
Received: from thor by sdrc; Mon, 5 Feb 90 10:10:13 est
Received: by thor; Mon, 5 Feb 90 09:57:19 EST
Date: Mon, 5 Feb 90 09:57:19 EST
From: Larry Jones <sdrc!scjones%[email protected]>
Message-Id: <9002051457.AA00211@thor>
To: [email protected]
Subject: GKS-3D C Language Binding
I have just received an interim copy of the GKS-3D C Language
Binding for review prior to a late March meeting of the commitee
that does graphic language bindings. If anyone would like a copy
to review, please let me know.
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC [email protected]
2000 Eastman Dr. BIX: ltl
Milford, OH 45150-2789 AT&T: (513) 576-2070
"You know how Einstein got bad grades as a kid? Well MINE are even WORSE!"
-Calvin
7-Feb-90 21:18:50-PST,4358;000000000000
Date: Wed, 7 Feb 90 21:17:24 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 2-Feb-90 19:18:17
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 2 Feb 90 19:16:47 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA08595; Fri, 2 Feb 90 22:09:09 -0500
Date: Fri, 2 Feb 90 15:49:10 EST
From: [email protected] (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#[email protected]>
To: [email protected]
%---------------------------------------------------------------
The following text will apear in Volume 1, number 4, March 1990, of
The Journal of C Language Translation. Although it was written by Rex
Jaeschke, it will apear as part of Jim Brodie's Standards Column.
It is reproduced here for your convenience as a service by the
Journal and for those of you who are are not Journal subscribers.
Please note this extract is Copyright 1990, Rex Jaeschke and all
rights are reserved.
This information is believed to be accurate as at February 2nd, 1990.
%---------------------------------------------------------------
The American National Standard for C has finally been approved.
The period for appeals before enactment of the standard has now
passed and actual publication of the standard should occur shortly.
(ANSI anticipates copies being available by late March.) The
Standard's official designation is ANSI X3.159-1989. To obtain a
copy, contact:
American National Standards Institute
Sales Department
1430 Broadway
New York, NY 10018
(212) 642-4900
fax (212) 302-1286
At press time, the price of the standard had not yet been determined.
{Interpretations Phase}
If you would like to formally submit a request for interpretation, do
so to:
X3 Secretariat
CBEMA
311 First Street N.W.
Suite 500
Washington, DC 20001-2178
Attn: Manager of Standards Processing
{The U.S. Government FIPS}
There is not yet a Federal Information Processing Standard (FIPS)
for C. Referencing a FIPS significantly simplifies the process of
using a language in a U.S. defense project. Now that the ANSI standard
for C has been approved the C FIPS should follow soon. Sometime in
February 1990 the FIPS proposal will be issued for a 90 day public
comment period. Assuming there are no objections, the FIPS is
presented to the U.S. Secretary of Commerce for signing. It is
expected this whole process will be completed during the Fall of
1990. This is then followed by a six month acceptance period after
which the FIPS becomes final. Note, however, that since the ANSI
Standard exists right now, a U.S. Government agency can require
conformance to that standard in RFPs right now! They do not need to
wait until a FIPS is produced.
{The Formal Validation Process}
On the U.S. front, activity in that direction has also begun in
earnest. According to the National Institute of Standards and
Technology (NIST) they issued a Request For Proposal (RFP) in late
January asking for submissions of C language validation test suites.
To get a copy of the solicitation for C language validation suite RFP
(Solicitation Number 52SBNB0C6O42) contact:
National Institute of Standards and Technology
Contracts Department
Gaithersburg, MD 20899
Note that the process of selecting or developing a validation suite is
not related to the FIPS. That is, the suite may be finalized
before or after a FIPS is produced.
%---------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
11-Feb-90 12:57:01-PST,3000;000000000000
Date: Sun, 11 Feb 90 12:56:05 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 4-Feb-90 14:18:51
Message undeliverable and dequeued after 7 days:
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 4 Feb 90 14:18:33 PST
Received: by uunet.uu.net (5.61/1.14)
id AA29698; Sun, 4 Feb 90 10:42:09 -0500
Date: Sat, 3 Feb 90 19:48:53 EST
From: [email protected] (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#[email protected]>
To: [email protected]
---------------------------------------------------------------------
Since late in 1989 we've heard much of the upheaval in the Eastern
European Bloc. Until you can relate to it personally, it's just
another news item. What's this to do with you? Well recently I
recieved a letter from a Senior Software Engineer in Romania. The
relevant extract follows:
Prior to, and during, the recent revolution in Romania we at the
Research Institute for Computers suffered much. Much hardware was
damaged or destroyed and we also lost considerable software and many
books.
I would be very grateful if you could help me, by appealing to your
readers, rebuild our collection of books and documentation on C,
C++, and expert systems. Also software and even hardware if
possible.
I have put together a shipment of books and manuals that I intend to
send. I encourage you to do the same. If you have any doubts about
export restrictions on certain items (hardware, for example) consult
your national Trade Commission or relevant government agency. Since
I know they are using Borland's Turbo C it appears they at least have
IBM-PC compatibles.
The address to send computer care packages is:
Doru Turturea
Research Institute for Computers
Strada Clucererului No 1, Sector 1
Bloc 40, Scarad
Bucuresti 71308
ROMANIA
Apart from doing a good deed for our colleagues abroad I'm sure some
in your marketing department would love the press coverage a generous
donation could bring. Think about it. Wouldn't your company like to
get a foot into the door of the newly opened Eastern Europe
marketplace?
---------------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
11-Feb-90 13:12:02-PST,1407;000000000000
Date: Sun, 11 Feb 90 13:08:56 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 5-Feb-90 07:17:40
Message undeliverable and dequeued after 6 days:
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 5 Feb 90 07:17:31 PST
Received: by uunet.uu.net (5.61/1.14)
id AA27930; Mon, 5 Feb 90 10:16:05 -0500
Received: from thor by sdrc; Mon, 5 Feb 90 10:10:13 est
Received: by thor; Mon, 5 Feb 90 09:57:19 EST
Date: Mon, 5 Feb 90 09:57:19 EST
From: Larry Jones <sdrc!scjones%[email protected]>
Message-Id: <9002051457.AA00211@thor>
To: [email protected]
Subject: GKS-3D C Language Binding
I have just received an interim copy of the GKS-3D C Language
Binding for review prior to a late March meeting of the commitee
that does graphic language bindings. If anyone would like a copy
to review, please let me know.
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC [email protected]
2000 Eastman Dr. BIX: ltl
Milford, OH 45150-2789 AT&T: (513) 576-2070
"You know how Einstein got bad grades as a kid? Well MINE are even WORSE!"
-Calvin
-------
15-Feb-90 00:44:53-PST,3001;000000000000
Date: Thu, 15 Feb 90 00:42:57 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 4-Feb-90 14:18:51
Message undeliverable and dequeued after 10 days:
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 4 Feb 90 14:18:33 PST
Received: by uunet.uu.net (5.61/1.14)
id AA29698; Sun, 4 Feb 90 10:42:09 -0500
Date: Sat, 3 Feb 90 19:48:53 EST
From: [email protected] (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#[email protected]>
To: [email protected]
---------------------------------------------------------------------
Since late in 1989 we've heard much of the upheaval in the Eastern
European Bloc. Until you can relate to it personally, it's just
another news item. What's this to do with you? Well recently I
recieved a letter from a Senior Software Engineer in Romania. The
relevant extract follows:
Prior to, and during, the recent revolution in Romania we at the
Research Institute for Computers suffered much. Much hardware was
damaged or destroyed and we also lost considerable software and many
books.
I would be very grateful if you could help me, by appealing to your
readers, rebuild our collection of books and documentation on C,
C++, and expert systems. Also software and even hardware if
possible.
I have put together a shipment of books and manuals that I intend to
send. I encourage you to do the same. If you have any doubts about
export restrictions on certain items (hardware, for example) consult
your national Trade Commission or relevant government agency. Since
I know they are using Borland's Turbo C it appears they at least have
IBM-PC compatibles.
The address to send computer care packages is:
Doru Turturea
Research Institute for Computers
Strada Clucererului No 1, Sector 1
Bloc 40, Scarad
Bucuresti 71308
ROMANIA
Apart from doing a good deed for our colleagues abroad I'm sure some
in your marketing department would love the press coverage a generous
donation could bring. Think about it. Wouldn't your company like to
get a foot into the door of the newly opened Eastern Europe
marketplace?
---------------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
15-Feb-90 02:12:58-PST,1408;000000000000
Date: Thu, 15 Feb 90 00:59:02 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 5-Feb-90 07:17:40
Message undeliverable and dequeued after 10 days:
[email protected]: Cannot connect to host
[email protected].#Internet: Cannot connect to host
[email protected].#Internet: Cannot connect to host
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 5 Feb 90 07:17:31 PST
Received: by uunet.uu.net (5.61/1.14)
id AA27930; Mon, 5 Feb 90 10:16:05 -0500
Received: from thor by sdrc; Mon, 5 Feb 90 10:10:13 est
Received: by thor; Mon, 5 Feb 90 09:57:19 EST
Date: Mon, 5 Feb 90 09:57:19 EST
From: Larry Jones <sdrc!scjones%[email protected]>
Message-Id: <9002051457.AA00211@thor>
To: [email protected]
Subject: GKS-3D C Language Binding
I have just received an interim copy of the GKS-3D C Language
Binding for review prior to a late March meeting of the commitee
that does graphic language bindings. If anyone would like a copy
to review, please let me know.
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC [email protected]
2000 Eastman Dr. BIX: ltl
Milford, OH 45150-2789 AT&T: (513) 576-2070
"You know how Einstein got bad grades as a kid? Well MINE are even WORSE!"
-Calvin
-------
15-Feb-90 16:32:54-PST,472;000000000000
Mail-From: KLH created at 15-Feb-90 16:32:36
Date: Thu, 15 Feb 90 16:32:36 PST
From: Ken Harrenstien <[email protected]>
Subject: Which address?
To: [email protected], [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I have two addresses shown for you on the X3J11 e-mail list that I maintain:
[email protected]
[email protected]
Which one should be used?
Thanks,
--Ken
-------
15-Feb-90 16:36:05-PST,554;000000000000
Mail-From: KLH created at 15-Feb-90 16:35:57
Date: Thu, 15 Feb 90 16:35:57 PST
From: Ken Harrenstien <[email protected]>
Subject: Does this address work?
To: [email protected]
cc: [email protected]
Message-ID: <[email protected]>
I'm trying to see if this address, currently entered in the X3J11 email
list, actually works. Supposedly it will reach Steve Adamski. If I
hear no reply I'll eventually flush it. Please send a reply if
possible (if not, I can be reached at 415/859-6552). Thanks...
--Ken
-------
16-Feb-90 07:19:27-PST,587;000000000000
Return-Path: <[email protected]>
Received: from ocfmail.ocf.llnl.gov by NIC.DDN.MIL with TCP; Fri, 16 Feb 90 07:19:12 PST
Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0)
id AA11996; Fri, 16 Feb 90 07:21:37 PST
Date: Fri, 16 Feb 90 07:21:37 PST
From: [email protected] (Linda Stanberry)
Message-Id: <[email protected]>
To: [email protected], [email protected], [email protected]
Subject: Re: Which address?
Cc: [email protected]
The [email protected] is the correct address. Thanks for asking!
Linda
24-Feb-90 07:10:53-PST,1812;000000000000
Date: Sat, 24 Feb 90 07:07:51 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 17-Feb-90 08:09:52
Message undeliverable and dequeued after 7 days:
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
[email protected]: Cannot connect to host
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 17 Feb 90 08:09:43 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA11226; Sat, 17 Feb 90 11:08:44 -0500
Date: Wed, 14 Feb 90 15:46:27 EST
From: [email protected] (Rex Jaeschke)
Subject: NIST Address Correction
Message-Id: <9002141546.0.UUL1.3#[email protected]>
To: [email protected]
%---------------------------------------------------------------
Recently I posted information about NIST and their validation suite
RFP. They have since advised me the correct postal address is:
National Institute of Standards and Technology
Acquisition and Assistance Division
Building 301 Room B117
Gaithersburg, MD 20899
not:
National Institute of Standards and Technology
Contracts Department
Gaithersburg, MD 20899
as I stated previously.
%---------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
24-May-90 13:28:06-PDT,928;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 24 May 90 13:27:34 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA19222; Thu, 24 May 90 16:28:13 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA21778; Thu, 24 May 90 14:08:00 EDT
Date: Thu, 24 May 90 14:08:00 EDT
From: [email protected] (0000-Admin(0000))
Message-Id: <[email protected]>
To: [email protected]
Subject: new x3j11 addr
Hi Ken!
We are now at plumhall.com , no longer plumhall.uu.net .
By the way, I see these domain addresses in uppercase and
also in lowercase. Does some part of the network require
upper case?
Hope things are well with you.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
25-May-90 19:47:30-PDT,3241;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Fri, 25 May 90 19:47:25 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa08022; 25 May 90 22:48 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA25506; Fri, 25 May 90 19:51:12 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AA18715; Fri, 25 May 90 19:45:39 PDT
Date: Fri, 25 May 90 19:45:39 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB18713; Fri, 25 May 90 19:45:39 PDT
Message-Id: <[email protected]>
Received: from relay.cs.net by RELAY.CS.NET id aa29052; 25 May 90 22:34 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa07978; 25 May 90 22:40 EDT
Received: from att-in.att.com by NIC.DDN.MIL with TCP; Fri, 25 May 90 11:40:15 PDT
From: [email protected]
Date: Fri, 25 May 90 14:00 EDT
To: [email protected]
Subject: Interesting observation/informal interpretation request
I was recently made aware of a "hole" in the Standard: the Standard
specifies the result type for every expression operator except
function call. (Check it out.) There is a guarantee that the value
of the return expression for the called function (after conversion
to the function's return type if appropriate) is the value of the
function call expression, but this is insufficient to determine the
type completely.
For example, all floating return types could be mapped to "long
double", all signed integer types to "long" and unsigned to
"unsigned long". Therefore, one might take expressions such as
sizeof(f())
to have undefined behavior since this is one of the "nothing's in the
Standard" instances. (A better interpretation, in my view, is that
the value for such an expression is unspecified, but has a definite
lower and upper bound for any particular arithmetic return type. It
seems reasonable to assume that structure and union return types must
match exactly.)
As it turns out, the interpretations committee cannot simply say that
the resulting type is the return type of the function called. Most,
if not all, historic C implementations applied the argument promotion
rules to function return types as well as to function argument
expressions. Thus no narrower than "int" types were returned, and
often the only floating type returned was "double".
It seems appropriate to me to interpret the Standard as giving license
to implementations to choose to widen or not as they so desire. The
only possible way of seeing this widening would be through the sizeof
operator, and that visibility would likewise be an implementation
choice.
Any other opinions?
Dave
26-May-90 17:51:31-PDT,2882;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 26 May 90 17:51:25 PDT
Received: from gould.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA16943; Sat, 26 May 90 20:52:31 -0400
Date: Sat, 26 May 90 19:49:04 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <9005262349.AA16669@gould>
Received: by gould (5.52/(IC 19May87-13:37)) id AA16669; Sat, 26 May 90 19:49:04 EDT
To: [email protected]
----- Transcript of session follows -----
550 mbennett... User unknown
----- Unsent message follows -----
Received: by gould (5.52/(IC 19May87-13:37)) id AA16667; Sat, 26 May 90 19:49:04 EDT
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA21334; Sat, 26 May 90 16:20:06 -0400
Message-Id: <[email protected]>
Received: from att-in.att.com by NIC.DDN.MIL with TCP; Fri, 25 May 90 11:40:15 PDT
From: uunet!attunix.att.com!dfp
Date: Fri, 25 May 90 14:00 EDT
To: sri-nic.arpa!x3j11
Subject: Interesting observation/informal interpretation request
I was recently made aware of a "hole" in the Standard: the Standard
specifies the result type for every expression operator except
function call. (Check it out.) There is a guarantee that the value
of the return expression for the called function (after conversion
to the function's return type if appropriate) is the value of the
function call expression, but this is insufficient to determine the
type completely.
For example, all floating return types could be mapped to "long
double", all signed integer types to "long" and unsigned to
"unsigned long". Therefore, one might take expressions such as
sizeof(f())
to have undefined behavior since this is one of the "nothing's in the
Standard" instances. (A better interpretation, in my view, is that
the value for such an expression is unspecified, but has a definite
lower and upper bound for any particular arithmetic return type. It
seems reasonable to assume that structure and union return types must
match exactly.)
As it turns out, the interpretations committee cannot simply say that
the resulting type is the return type of the function called. Most,
if not all, historic C implementations applied the argument promotion
rules to function return types as well as to function argument
expressions. Thus no narrower than "int" types were returned, and
often the only floating type returned was "double".
It seems appropriate to me to interpret the Standard as giving license
to implementations to choose to widen or not as they so desire. The
only possible way of seeing this widening would be through the sizeof
operator, and that visibility would likewise be an implementation
choice.
Any other opinions?
Dave
31-May-90 20:18:56-PDT,2763;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Thu, 31 May 90 20:18:51 PDT
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA13361; Thu, 31 May 90 23:18:46 EDT
Date: Thu, 31 May 90 23:18:46 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 saber.ether-mailer... 550 Host unknown
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 31 May 90 14:57:08 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12928; Thu, 31 May 90 17:55:57 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02885; Thu, 31 May 90 17:31:44 EDT
Date: Thu, 31 May 90 17:31:44 EDT
From: [email protected] (0000-Admin(0000))
Message-Id: <[email protected]>
To: [email protected], [email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected]
Subject: ordering X3.159-1989
General notice:
The final Standard, X3.159-1989, is *almost* identical to X3J11/88-159,
and the only differences are editorial clarifications. One can use
88-159 with confidence.
Eventually, one needs the official document.
The ANSI C Standard, X3.159-1989, is available now from
ANSI, Sales Dept, 1430 Broadway, New York NY 10018
212-642-4900, FAX 212-302-1286
The price is $50, plus $6 shipping and handling.
If your company is a member of ANSI, they will bill you;
otherwise send a check or money order. No credit cards.
Allow 10 days to fill the order.
X3J11 members have been informed directly from X3 that they
are to make no copies of X3J11/90-013, the internal copy of
the final draft.
With regard to getting online copies of X3.159-1989: Jean-Paul Emard
is the Director of the Standards Secretariat at X3 (CBEMA). He told
me on the phone that he is working on a project to obtain rights for
making machine-readable copies of X3 standards. There is no telling
how long this will take.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ----------------------> NEW DOMAIN ADDR ++++++++++++
31-May-90 21:07:55-PDT,3455;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Thu, 31 May 90 21:07:46 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa16251; 1 Jun 90 0:07 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA29035; Thu, 31 May 90 21:10:45 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC23354; Thu, 31 May 90 21:05:00 PDT
Date: Thu, 31 May 90 21:05:00 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB23354; Thu, 31 May 90 21:05:00 PDT
Received: from relay.cs.net by RELAY.CS.NET id aa12437; 31 May 90 23:18 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa15574; 31 May 90 23:20 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 31 May 90 14:57:08 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12928; Thu, 31 May 90 17:55:57 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02885; Thu, 31 May 90 17:31:44 EDT
Date: Thu, 31 May 90 17:31:44 EDT
From: "0000-Admin(0000" <[email protected]>
Mmdf-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <[email protected]>
To: [email protected], [email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected],
[email protected]
Subject: ordering X3.159-1989
General notice:
The final Standard, X3.159-1989, is *almost* identical to X3J11/88-159,
and the only differences are editorial clarifications. One can use
88-159 with confidence.
Eventually, one needs the official document.
The ANSI C Standard, X3.159-1989, is available now from
ANSI, Sales Dept, 1430 Broadway, New York NY 10018
212-642-4900, FAX 212-302-1286
The price is $50, plus $6 shipping and handling.
If your company is a member of ANSI, they will bill you;
otherwise send a check or money order. No credit cards.
Allow 10 days to fill the order.
X3J11 members have been informed directly from X3 that they
are to make no copies of X3J11/90-013, the internal copy of
the final draft.
With regard to getting online copies of X3.159-1989: Jean-Paul Emard
is the Director of the Standards Secretariat at X3 (CBEMA). He told
me on the phone that he is working on a project to obtain rights for
making machine-readable copies of X3 standards. There is no telling
how long this will take.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ----------------------> NEW DOMAIN ADDR ++++++++++++
1-Jun-90 08:12:52-PDT,2269;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Fri, 1 Jun 90 08:12:44 PDT
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA22356; Fri, 1 Jun 90 11:12:48 EDT
Date: Fri, 1 Jun 90 11:12:48 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 saber.ether-mailer... 550 Host unknown
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from att-in.att.com by NIC.DDN.MIL with TCP; Fri, 1 Jun 90 06:17:51 PDT
From: [email protected]
Date: Fri, 1 Jun 90 08:44 EDT
To: [email protected]
Subject: Re: Interesting observation/informal interpretation request
Sam Kendall ([email protected]) makes the point that it's not just
sizeof that can be affected by the lack of strict type rules for
function calls. I would certainly argue that the intent of the
Standard was to allow code such as in his mail:
> There's one other way that this widening can be made visible: through
>calls to functions that lack prototypes. For example:
>
> extern char ret_char(void);
> extern float ret_float(void);
> void no_prototype();
>
> main() {
> no_prototype(ret_char(), ret_float());
> }
>
> void no_prototype(i, d)
> int i;
> double d;
> {
> ...
> }
>
>If `ret_char' returned a `long', or `ret_float' returned a `long
>double', then the call to `no_prototype' wouldn't work.
Fortunately, the old implementation behavior in which the same widening
rules for argument expressions were applied to return types causes no
problems here.
> We need a constrant that an integral return type cannot be promoted
>to `long' or `long unsigned', and a floating return type cannot be
>promoted to `long double'.
Of course, we can't add new constraints to the Standard now. However,
the point you make does implicitly contrain implementations to widen
(if at all) to no wider than the default argument promotions. Since
this matches the behavior of many older implementations, this makes
the interpretation of the Standard quite reasonable!
Dave
1-Jun-90 09:53:31-PDT,2927;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Fri, 1 Jun 90 09:51:16 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa27998; 1 Jun 90 12:49 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA15934; Fri, 1 Jun 90 09:52:40 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC10035; Fri, 1 Jun 90 09:46:49 PDT
Date: Fri, 1 Jun 90 09:46:49 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB10035; Fri, 1 Jun 90 09:46:49 PDT
Message-Id: <[email protected]>
Received: from relay.cs.net by RELAY.CS.NET id aa03052; 1 Jun 90 11:14 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa26065; 1 Jun 90 11:15 EDT
Received: from att-in.att.com by NIC.DDN.MIL with TCP; Fri, 1 Jun 90 06:17:51 PDT
From: [email protected]
Date: Fri, 1 Jun 90 08:44 EDT
To: [email protected]
Subject: Re: Interesting observation/informal interpretation request
Sam Kendall ([email protected]) makes the point that it's not just
sizeof that can be affected by the lack of strict type rules for
function calls. I would certainly argue that the intent of the
Standard was to allow code such as in his mail:
> There's one other way that this widening can be made visible: through
>calls to functions that lack prototypes. For example:
>
> extern char ret_char(void);
> extern float ret_float(void);
> void no_prototype();
>
> main() {
> no_prototype(ret_char(), ret_float());
> }
>
> void no_prototype(i, d)
> int i;
> double d;
> {
> ...
> }
>
>If `ret_char' returned a `long', or `ret_float' returned a `long
>double', then the call to `no_prototype' wouldn't work.
Fortunately, the old implementation behavior in which the same widening
rules for argument expressions were applied to return types causes no
problems here.
> We need a constrant that an integral return type cannot be promoted
>to `long' or `long unsigned', and a floating return type cannot be
>promoted to `long double'.
Of course, we can't add new constraints to the Standard now. However,
the point you make does implicitly contrain implementations to widen
(if at all) to no wider than the default argument promotions. Since
this matches the behavior of many older implementations, this makes
the interpretation of the Standard quite reasonable!
Dave
3-Jun-90 18:03:43-PDT,2794;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 3 Jun 90 18:03:38 PDT
Received: from gould.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA21523; Sun, 3 Jun 90 21:03:14 -0400
Date: Sun, 3 Jun 90 19:56:43 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <9006032356.AA16664@gould>
Received: by gould (5.52/(IC 19May87-13:37)) id AA16664; Sun, 3 Jun 90 19:56:43 EDT
To: [email protected]
----- Transcript of session follows -----
550 mbennett... User unknown
----- Unsent message follows -----
Received: by gould (5.52/(IC 19May87-13:37)) id AA16662; Sun, 3 Jun 90 19:56:43 EDT
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA18594; Sun, 3 Jun 90 05:59:15 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 31 May 90 14:57:08 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12928; Thu, 31 May 90 17:55:57 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02885; Thu, 31 May 90 17:31:44 EDT
Date: Thu, 31 May 90 17:31:44 EDT
From: uunet!plumhall!root (0000-Admin(0000))
Message-Id: <[email protected]>
To: SRI-NIC.ARPA!X3J11, cs.vu.nl!keie, pyrps5.pyramid.com!sutton,
se-sd.sandiego.NCR.COM!rns, sun!acad!metaware!ken,
sun!acad!metaware!tom, sun.com!wnielsen, tekirl.labs.tek.com!jbb,
ukc!knosof!derek
Subject: ordering X3.159-1989
General notice:
The final Standard, X3.159-1989, is *almost* identical to X3J11/88-159,
and the only differences are editorial clarifications. One can use
88-159 with confidence.
Eventually, one needs the official document.
The ANSI C Standard, X3.159-1989, is available now from
ANSI, Sales Dept, 1430 Broadway, New York NY 10018
212-642-4900, FAX 212-302-1286
The price is $50, plus $6 shipping and handling.
If your company is a member of ANSI, they will bill you;
otherwise send a check or money order. No credit cards.
Allow 10 days to fill the order.
X3J11 members have been informed directly from X3 that they
are to make no copies of X3J11/90-013, the internal copy of
the final draft.
With regard to getting online copies of X3.159-1989: Jean-Paul Emard
is the Director of the Standards Secretariat at X3 (CBEMA). He told
me on the phone that he is working on a project to obtain rights for
making machine-readable copies of X3 standards. There is no telling
how long this will take.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ----------------------> NEW DOMAIN ADDR ++++++++++++
3-Jun-90 18:03:45-PDT,2570;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 3 Jun 90 18:03:42 PDT
Received: from gould.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA21527; Sun, 3 Jun 90 21:03:16 -0400
Date: Sun, 3 Jun 90 19:57:42 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <9006032357.AA16687@gould>
Received: by gould (5.52/(IC 19May87-13:37)) id AA16687; Sun, 3 Jun 90 19:57:42 EDT
To: [email protected]
----- Transcript of session follows -----
550 mbennett... User unknown
----- Unsent message follows -----
Received: by gould (5.52/(IC 19May87-13:37)) id AA16685; Sun, 3 Jun 90 19:57:42 EDT
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA25102; Sun, 3 Jun 90 07:19:41 -0400
Message-Id: <[email protected]>
Received: from att-in.att.com by NIC.DDN.MIL with TCP; Fri, 1 Jun 90 06:17:51 PDT
From: uunet!attunix.att.com!dfp
Date: Fri, 1 Jun 90 08:44 EDT
To: sri-nic.arpa!x3j11
Subject: Re: Interesting observation/informal interpretation request
Sam Kendall ([email protected]) makes the point that it's not just
sizeof that can be affected by the lack of strict type rules for
function calls. I would certainly argue that the intent of the
Standard was to allow code such as in his mail:
> There's one other way that this widening can be made visible: through
>calls to functions that lack prototypes. For example:
>
> extern char ret_char(void);
> extern float ret_float(void);
> void no_prototype();
>
> main() {
> no_prototype(ret_char(), ret_float());
> }
>
> void no_prototype(i, d)
> int i;
> double d;
> {
> ...
> }
>
>If `ret_char' returned a `long', or `ret_float' returned a `long
>double', then the call to `no_prototype' wouldn't work.
Fortunately, the old implementation behavior in which the same widening
rules for argument expressions were applied to return types causes no
problems here.
> We need a constrant that an integral return type cannot be promoted
>to `long' or `long unsigned', and a floating return type cannot be
>promoted to `long double'.
Of course, we can't add new constraints to the Standard now. However,
the point you make does implicitly contrain implementations to widen
(if at all) to no wider than the default argument promotions. Since
this matches the behavior of many older implementations, this makes
the interpretation of the Standard quite reasonable!
Dave
3-Jun-90 18:15:02-PDT,907;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 3 Jun 90 18:15:00 PDT
Received: from oresoft.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22351; Sun, 3 Jun 90 21:14:36 -0400
Received: by oresoft.oresoft.com (/\=-/\ Smail3.1.18.1 #18.37)
id <[email protected]>; Sun, 3 Jun 90 06:21 PDT
Received: by m2xenix.psg.com (/\=-/\ Smail3.1.18.1 #18.11)
id <[email protected]>; Sun, 3 Jun 90 05:55 PDT
Message-Id: <[email protected]>
From: [email protected] (Randy Bush)
To: [email protected]
Subject: I'm on vacation
Date: Sun Jun 3 05:55:40 1990
Your message was delivered. However, I am on vacation, so I have not yet
read your message. I will be back on June 10, 1990.
This is the only such message you will receive.
randy (via Chip's wonderful Deliver program)
3-Jun-90 18:15:05-PDT,907;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 3 Jun 90 18:15:03 PDT
Received: from oresoft.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22357; Sun, 3 Jun 90 21:14:38 -0400
Received: by oresoft.oresoft.com (/\=-/\ Smail3.1.18.1 #18.37)
id <[email protected]>; Sun, 3 Jun 90 06:21 PDT
Received: by m2xenix.psg.com (/\=-/\ Smail3.1.18.1 #18.11)
id <[email protected]>; Sun, 3 Jun 90 05:55 PDT
Message-Id: <[email protected]>
From: [email protected] (Randy Bush)
To: [email protected]
Subject: I'm on vacation
Date: Sun Jun 3 05:55:40 1990
Your message was delivered. However, I am on vacation, so I have not yet
read your message. I will be back on June 10, 1990.
This is the only such message you will receive.
randy (via Chip's wonderful Deliver program)
4-Jun-90 15:56:05-PDT,837;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 4 Jun 90 15:55:56 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA09275; Mon, 4 Jun 90 10:25:56 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA01035; Mon, 4 Jun 90 10:12:32 EDT
Date: Mon, 4 Jun 90 10:12:32 EDT
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: request
Ken, would you be so kind as to email me a copy of the latest
X3J11 list? Thanks a lot.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
6-Jun-90 22:45:00-PDT,1900;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 6 Jun 90 22:44:55 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa12692; 7 Jun 90 1:45 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA13794; Wed, 6 Jun 90 22:48:01 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC08094; Wed, 6 Jun 90 22:42:17 PDT
Date: Wed, 6 Jun 90 22:42:17 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB08094; Wed, 6 Jun 90 22:42:17 PDT
Received: from relay.cs.net by RELAY.CS.NET id aa25090; 7 Jun 90 1:36 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa12600; 7 Jun 90 1:38 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 6 Jun 90 12:17:03 PDT
Received: from ibmsupt.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA29772; Wed, 6 Jun 90 15:15:56 -0400
Received: by ibmsupt.XXX (5.51/5.17)
id AA26981; Wed, 6 Jun 90 11:15:50 19
Received: by ibmpa.paloalto.ibm.com (5.61/1.14)
id AA05805; Wed, 6 Jun 90 10:54:22 -0700
Date: Wed, 6 Jun 90 10:54:22 -0700
From: Fred Tydeman <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: "o" and precision in printf
What should be printed by:
printf( "%#.4o", 345 );
Should it be 0531 or 00531 ?
6-Jul-90 23:04:12-PDT,1418;000000000000
Return-Path: <[email protected]>
Received: from timbuk.CRAY.COM by NIC.DDN.MIL with TCP; Fri, 6 Jul 90 23:04:06 PDT
Received: from hilbert.cray.com by timbuk.CRAY.COM (4.1/SMI4.0 CRAY1.1)
id AA28944; Sat, 7 Jul 90 01:02:01 CDT
Received: by hilbert.cray.com
id AA27506; 3.2/CRI-3.14; Sat, 7 Jul 90 01:03:38 CDT
Date: Sat, 7 Jul 90 01:03:38 CDT
From: [email protected] (Tom MacDonald)
Message-Id: <[email protected]>
Subject: TMacD's gone to Montana
To: [email protected]
Hello,
This is Tom's SUN 3/50 workstation here, letting you know that he
has gone to Montana to punch a few cows and wrestle a few steers.
I'm just a workstation so I don't know how to do anything. TMacD will be
back to work on Mon. 7/9/90 so I will have to be content with responding
to his Email until then. Just between you and me I'm glad he's gone
cause he was getting to be one miserable person to be around lately.
I certainly hope this improves his mood.
If you have a Cray C question please contact Steve Collins (slc) x5806.
If you want to do TMacD a favor then call the Minneapolis-St. Paul
Metropolitan Airports Commision and tell them to move MSP airport.
It's too small, noisy and controversial. Their number is 612-726-1892.
Let's make the Minneapolis-St. Paul Metro area a first class place with
a first class airport.
Remember - workstations are people to.
6-Jul-90 23:20:52-PDT,11531;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Fri, 6 Jul 90 23:20:44 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa18944; 7 Jul 90 2:20 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA09529; Fri, 6 Jul 90 23:23:30 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC29268; Fri, 6 Jul 90 23:16:55 PDT
Date: Fri, 6 Jul 90 23:16:55 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB29268; Fri, 6 Jul 90 23:16:55 PDT
Received: from relay.cs.net by RELAY.CS.NET id aa10312; 7 Jul 90 2:06 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa18801; 7 Jul 90 2:10 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 6 Jul 90 17:59:13 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA27151; Fri, 6 Jul 90 20:58:45 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA01605; Fri, 6 Jul 90 20:28:18 EDT
Date: Fri, 6 Jul 90 20:28:18 EDT
From: "0000-Admin(0000" <[email protected]>
Mmdf-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <[email protected]>
To: [email protected], [email protected],
[email protected]
Subject: X3J11/90-048
Regarding Simonsen and Stroustrup's paper, 06 July 1990
"A European Representation for ISO C" X3J11/90-048
SC22/WG14/N117 X3J16/90-____
WG14/N____
Thomas Plum, Plum Hall Inc
At the June 19-20 WG14 meeting, Keld Simonsen asked me if I would
communicate my comments on the latest Simonsen/Stroustrup proposal
on character sets. This latest version is WG14/N117; I will refer
to the proposal in its various forms as the "S&S" proposal.
My first comment is that I never received any feedback regarding
my paper X3J11/88-108, a personal (non-official) comment on their
earlier paper that was distributed as X3J11/88-134. Rather than
re-hash those comments, I will attempt to outline the issues
one-by-one.
1. Agreed by all parties:
"ANSI/ISO C needs to have a representation system within ISO 646."
X3J11 and WG14 have agreed on this point for many years. X3J11
resisted all attempts by various members and public commenters to
eliminate or weaken the support for our adopted solution, the
so-called trigraphs.
I am not sure that SC22 has been clearly informed that ANSI C does
in fact already provide full support for programs in ISO 646. Keld
distributed an excerpt from an ISO document, SC22/N615 -- now also
WG14/N123 -- containing the following guideline:
| 5.1.3.1 Guideline: Character sets used for program text
|
| As far as possible, the language should be defined in terms only of
| the characters included within ISO 646, avoiding the use of any that
| are in national use positions.
X3J11 standardized an existing language which already did use a number
of these characters. We avoided adding any other national use positions.
| If any symbols are used which are not included within ISO 646 or are
| in national use positions, an alternative representation for all such
| symbols should be specified.
X3J11 has done so. The trigraphs are an alternative representation.
| A conforming processor should be required to be capable of accepting
| a program represented using only this minimal character set.
X3J11 has done so.
| Great care should be taken in specifying how "non-printing"
| characters are to be handled, i.e. those characters that correspond
| to integer values 0 to 32 inclusive and 127, i.e. null (0/0) to
| space (2/0) and delete (7/13).
X3J11 has done so. The handling of whitespace is consistent across
language and library. This is also irrelevant to the S&S proposals.
Those of us who worked in X3J11 over several years to develop that
Standard would appreciate it if in future discussions it were first
recognized that our current system of trigraphs does in fact conform
to these guidelines. Then we can get on with the real issues.
2. A generally-agreed point:
"The trigraph representation is not very suitable for human eyes."
This is a quote from WG14/N117. Most people agree; this disagreements
are only in the area of what should be done about this.
3. Generally-agreed:
"There is no alternative to using trigraphs in strings."
The S&S proposals have never suggested using anything but trigraphs
in strings (and character constants too). It is, of course, possible
to make a given program more readable by defining macros:
#define LEFT_BRACE '??<'
and then using the symbolic names, but this goes beyond what S&S
proposed.
4. Not agreed:
"Introducing more readable names requires new keywords."
This has been a major point of disagreement between X3J11 and the
S&S proposals. It has been suggested several times that simple
macro names provide all that is required for greater readability.
It would be a pure extension to define a new header -- call
it <iso646.h> say -- in which a specified set of new names are
provided. The S&S proposal even goes so far as to suggest that
"the new keywords could be conditionally in effect for new programs".
If they are conditional, then why not confine them to a header-file
definition?
The only point in the S&S paper that favors new keywords over a
header-file is that (by re-programming every parser) the new keywords
can be combined with = to make assignment operators. But on the
other hand, the header-file can provide or_equals , and_equals , and
xor_equals .
5. Generally agreed:
"Left to local choice, readability conventions will diverge."
If different groups of programmers begin using macros to make the
open-brace and close-brace trigraphs more readable, then in a few
years we will have several incompatible sets of conventions.
What is not generally agreed is that incompatible sets of conventions
are in themselves a major problem worth changing the language for.
However, if a new standard header <iso646.h> were adopted, such a
header could provide a consistent set of conventions, which would
also prevent the divergence of conventions.
6. Not agreed (from my alternative 88-108):
"The names begin and end have been proposed, and are adequate."
My paper 88-108 suggested begin and end as the most popular
synonyms for open-brace and close-brace.
The latest WG14/N117 says
We decided to make the compound statement brackets digraphs,
finding 'begin' and 'end' too long to write and too likely to
be found ''not in the spirit of C'' by large numbers
of programmers.
This is one of the points of direct disagreement. Each reader of
these documents will have to judge whether this claim of "too long
to write" and "not in the spirit of C" is sufficient ground for
causing ISO and ANSI C to diverge, and for causing the rewriting of
all existing parsers.
All I can say is, this is a purely aesthetic argument here,
not having ANYTHING to do with decisions of SC22 about accomodating
ISO 646. It seems unlikely to me that SC22 would have any objection
to the names begin and end .
In my experience of the industry, among those projects which make the
(misguided) attempt to make C look more like prior languages, these
names ( begin and end ) are the most common synonyms.
7. Generally agreed:
"The trigraph representation of ??/ is unatractive but adequate."
The S&S papers make no proposals to use anything but the trigraph.
8. Not agreed (from my alternative in 88-108):
"A macro -- named sub for example -- is adequate for subscript [n]."
In my paper 88-108, I proposed that SUB(n) was an adequate alternative
for subscript. Since then, the C++ style has favored lower-case
symbols, and the S&S papers have always used them. So suppose, then,
that the proposal were revised to say sub(n) .
There is no discussion in N117 addressing the question of why an
entirely new operator needs to be introduced to solve the readability
problem of square brackets. As with point 6 above, the justification
for this new operator needs to be sufficiently compelling to force the
ANSI and ISO standards to diverge, and to cause the rewriting of all
existing parsers.
9. Not agreed (from my objections in 88-108):
"The proposed subscription symbol ! is technically flawed."
It was pointed out in 88-108, and independently elsewhere, that the
proposed new symbol, exclamation-mark, used for subscription in
expressions and for the "array-of" declarator, has a technical flaw
in its usage for the empty-brackets declarator context. It requires
acceptance of an empty-expression () operand (as in argv!() )
as well as an entirely-missing operand (as in argv! ). This latter
situation essentially adds the exclamation-mark as a postfix symbol,
as well as infix (as well, of course, as the original prefix usage).
N117 contains no discussion that addresses these long-standing
technical problems.
10. Not agreed (from my alternative in 88-108):
"The empty-brackets declarator can be handled by a macro name."
In 88-108 I suggested that SUBSUB could suffice for the
empty-brackets context. I had no attachment to the particular name;
any will do. It could be lower-case just as well as upper-case.
There is no discussion in N117 giving any reasons why a macro name
is not adequate for the empty-brackets declarator context.
SUMMARY:
We agree on several points.
I am expressing here the entirely personal opinion that a pure
extension to existing C could be adopted by WG14, in the form of
a header, named for example <iso646.h> .
o This would not invalidate any existing translators.
o It could be specified in the Normative Addendum authorized by
SC22 to address character set issues.
o It avoids the technical flaw that has not yet been addressed in
the S&S papers.
o It would achieve the stated goals of the S&S papers, a more
readable representation of C programs in ISO 646.
o If a "readability" header were to be adopted by WG14 in its Normative
Addendum, it is immensely more likely that ANSI X3J11 would also
adopt it, to preserve the situation of identical ANSI and ISO
Standards for C, relative to the major changes in the S&S papers.
o In my limited and biased opinion, it is more likely to be adopted
by ANSI X3J16 (standardizing C++) than a proposal which alters
the lexical syntax, the declarator syntax, and the expression
syntax of all existing Base Documents for the C++ Standard.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
7-Jul-90 05:08:58-PDT,10494;000000000000
Date: Sat, 7 Jul 90 05:04:05 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 6-Jul-90 17:59:20
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 6 Jul 90 17:59:13 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA27151; Fri, 6 Jul 90 20:58:45 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA01605; Fri, 6 Jul 90 20:28:18 EDT
Date: Fri, 6 Jul 90 20:28:18 EDT
From: [email protected] (0000-Admin(0000))
Message-Id: <[email protected]>
To: [email protected], [email protected],
[email protected]
Subject: X3J11/90-048
Regarding Simonsen and Stroustrup's paper, 06 July 1990
"A European Representation for ISO C" X3J11/90-048
SC22/WG14/N117 X3J16/90-____
WG14/N____
Thomas Plum, Plum Hall Inc
At the June 19-20 WG14 meeting, Keld Simonsen asked me if I would
communicate my comments on the latest Simonsen/Stroustrup proposal
on character sets. This latest version is WG14/N117; I will refer
to the proposal in its various forms as the "S&S" proposal.
My first comment is that I never received any feedback regarding
my paper X3J11/88-108, a personal (non-official) comment on their
earlier paper that was distributed as X3J11/88-134. Rather than
re-hash those comments, I will attempt to outline the issues
one-by-one.
1. Agreed by all parties:
"ANSI/ISO C needs to have a representation system within ISO 646."
X3J11 and WG14 have agreed on this point for many years. X3J11
resisted all attempts by various members and public commenters to
eliminate or weaken the support for our adopted solution, the
so-called trigraphs.
I am not sure that SC22 has been clearly informed that ANSI C does
in fact already provide full support for programs in ISO 646. Keld
distributed an excerpt from an ISO document, SC22/N615 -- now also
WG14/N123 -- containing the following guideline:
| 5.1.3.1 Guideline: Character sets used for program text
|
| As far as possible, the language should be defined in terms only of
| the characters included within ISO 646, avoiding the use of any that
| are in national use positions.
X3J11 standardized an existing language which already did use a number
of these characters. We avoided adding any other national use positions.
| If any symbols are used which are not included within ISO 646 or are
| in national use positions, an alternative representation for all such
| symbols should be specified.
X3J11 has done so. The trigraphs are an alternative representation.
| A conforming processor should be required to be capable of accepting
| a program represented using only this minimal character set.
X3J11 has done so.
| Great care should be taken in specifying how "non-printing"
| characters are to be handled, i.e. those characters that correspond
| to integer values 0 to 32 inclusive and 127, i.e. null (0/0) to
| space (2/0) and delete (7/13).
X3J11 has done so. The handling of whitespace is consistent across
language and library. This is also irrelevant to the S&S proposals.
Those of us who worked in X3J11 over several years to develop that
Standard would appreciate it if in future discussions it were first
recognized that our current system of trigraphs does in fact conform
to these guidelines. Then we can get on with the real issues.
2. A generally-agreed point:
"The trigraph representation is not very suitable for human eyes."
This is a quote from WG14/N117. Most people agree; this disagreements
are only in the area of what should be done about this.
3. Generally-agreed:
"There is no alternative to using trigraphs in strings."
The S&S proposals have never suggested using anything but trigraphs
in strings (and character constants too). It is, of course, possible
to make a given program more readable by defining macros:
#define LEFT_BRACE '??<'
and then using the symbolic names, but this goes beyond what S&S
proposed.
4. Not agreed:
"Introducing more readable names requires new keywords."
This has been a major point of disagreement between X3J11 and the
S&S proposals. It has been suggested several times that simple
macro names provide all that is required for greater readability.
It would be a pure extension to define a new header -- call
it <iso646.h> say -- in which a specified set of new names are
provided. The S&S proposal even goes so far as to suggest that
"the new keywords could be conditionally in effect for new programs".
If they are conditional, then why not confine them to a header-file
definition?
The only point in the S&S paper that favors new keywords over a
header-file is that (by re-programming every parser) the new keywords
can be combined with = to make assignment operators. But on the
other hand, the header-file can provide or_equals , and_equals , and
xor_equals .
5. Generally agreed:
"Left to local choice, readability conventions will diverge."
If different groups of programmers begin using macros to make the
open-brace and close-brace trigraphs more readable, then in a few
years we will have several incompatible sets of conventions.
What is not generally agreed is that incompatible sets of conventions
are in themselves a major problem worth changing the language for.
However, if a new standard header <iso646.h> were adopted, such a
header could provide a consistent set of conventions, which would
also prevent the divergence of conventions.
6. Not agreed (from my alternative 88-108):
"The names begin and end have been proposed, and are adequate."
My paper 88-108 suggested begin and end as the most popular
synonyms for open-brace and close-brace.
The latest WG14/N117 says
We decided to make the compound statement brackets digraphs,
finding 'begin' and 'end' too long to write and too likely to
be found ''not in the spirit of C'' by large numbers
of programmers.
This is one of the points of direct disagreement. Each reader of
these documents will have to judge whether this claim of "too long
to write" and "not in the spirit of C" is sufficient ground for
causing ISO and ANSI C to diverge, and for causing the rewriting of
all existing parsers.
All I can say is, this is a purely aesthetic argument here,
not having ANYTHING to do with decisions of SC22 about accomodating
ISO 646. It seems unlikely to me that SC22 would have any objection
to the names begin and end .
In my experience of the industry, among those projects which make the
(misguided) attempt to make C look more like prior languages, these
names ( begin and end ) are the most common synonyms.
7. Generally agreed:
"The trigraph representation of ??/ is unatractive but adequate."
The S&S papers make no proposals to use anything but the trigraph.
8. Not agreed (from my alternative in 88-108):
"A macro -- named sub for example -- is adequate for subscript [n]."
In my paper 88-108, I proposed that SUB(n) was an adequate alternative
for subscript. Since then, the C++ style has favored lower-case
symbols, and the S&S papers have always used them. So suppose, then,
that the proposal were revised to say sub(n) .
There is no discussion in N117 addressing the question of why an
entirely new operator needs to be introduced to solve the readability
problem of square brackets. As with point 6 above, the justification
for this new operator needs to be sufficiently compelling to force the
ANSI and ISO standards to diverge, and to cause the rewriting of all
existing parsers.
9. Not agreed (from my objections in 88-108):
"The proposed subscription symbol ! is technically flawed."
It was pointed out in 88-108, and independently elsewhere, that the
proposed new symbol, exclamation-mark, used for subscription in
expressions and for the "array-of" declarator, has a technical flaw
in its usage for the empty-brackets declarator context. It requires
acceptance of an empty-expression () operand (as in argv!() )
as well as an entirely-missing operand (as in argv! ). This latter
situation essentially adds the exclamation-mark as a postfix symbol,
as well as infix (as well, of course, as the original prefix usage).
N117 contains no discussion that addresses these long-standing
technical problems.
10. Not agreed (from my alternative in 88-108):
"The empty-brackets declarator can be handled by a macro name."
In 88-108 I suggested that SUBSUB could suffice for the
empty-brackets context. I had no attachment to the particular name;
any will do. It could be lower-case just as well as upper-case.
There is no discussion in N117 giving any reasons why a macro name
is not adequate for the empty-brackets declarator context.
SUMMARY:
We agree on several points.
I am expressing here the entirely personal opinion that a pure
extension to existing C could be adopted by WG14, in the form of
a header, named for example <iso646.h> .
o This would not invalidate any existing translators.
o It could be specified in the Normative Addendum authorized by
SC22 to address character set issues.
o It avoids the technical flaw that has not yet been addressed in
the S&S papers.
o It would achieve the stated goals of the S&S papers, a more
readable representation of C programs in ISO 646.
o If a "readability" header were to be adopted by WG14 in its Normative
Addendum, it is immensely more likely that ANSI X3J11 would also
adopt it, to preserve the situation of identical ANSI and ISO
Standards for C, relative to the major changes in the S&S papers.
o In my limited and biased opinion, it is more likely to be adopted
by ANSI X3J16 (standardizing C++) than a proposal which alters
the lexical syntax, the declarator syntax, and the expression
syntax of all existing Base Documents for the C++ Standard.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
-------
7-Jul-90 21:26:44-PDT,804;000000000000
Date: Sat, 7 Jul 90 21:22:34 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 7-Jul-90 20:41:05
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from vgr.brl.mil by NIC.DDN.MIL with TCP; Sat, 7 Jul 90 20:40:58 PDT
Date: Sat, 7 Jul 90 23:32:32 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: [email protected]
cc: [email protected], [email protected]
Subject: Re: X3J11/90-048
Message-ID: <[email protected]>
Good paper. While you didn't emphasize it, my position is that any
ISO "normative addendum" must be one that is permitted as an extension
by the ANSI C standard. Certainly <iso646.h> would be one such method.
-------
7-Jul-90 21:30:37-PDT,1741;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Sat, 7 Jul 90 21:30:34 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa04888; 8 Jul 90 0:29 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA29129; Sat, 7 Jul 90 21:33:30 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC26698; Sat, 7 Jul 90 21:27:06 PDT
Date: Sat, 7 Jul 90 21:27:06 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB26698; Sat, 7 Jul 90 21:27:06 PDT
Received: from relay.cs.net by RELAY.CS.NET id ab19665; 8 Jul 90 0:18 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa04803; 8 Jul 90 0:21 EDT
Received: from vgr.brl.mil by NIC.DDN.MIL with TCP; Sat, 7 Jul 90 20:40:58 PDT
Date: Sat, 7 Jul 90 23:32:32 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: [email protected]
Cc: [email protected], [email protected]
Subject: Re: X3J11/90-048
Message-Id: <[email protected]>
Good paper. While you didn't emphasize it, my position is that any
ISO "normative addendum" must be one that is permitted as an extension
by the ANSI C standard. Certainly <iso646.h> would be one such method.
16-Jul-90 11:37:22-PDT,754;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 16 Jul 90 11:37:17 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA19170; Mon, 16 Jul 90 10:57:49 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA05934; Mon, 16 Jul 90 10:39:22 EDT
Date: Mon, 16 Jul 90 10:39:22 EDT
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Stanberry addr chg
I noticed on a recent X3J11 mailing that I received two copies: if you
want to correct the mailing list, you can delete [email protected].
Linda Stanberry
Lawrence Livermore National Laboratory
16-Jul-90 13:27:00-PDT,1416;000000000000
Return-Path: <[email protected]>
Received: from churchy.nisc.sri.com by NIC.DDN.MIL with TCP; Mon, 16 Jul 90 13:26:59 PDT
Received: by churchy.nisc.sri.com (5.61/SRI-NISC1.0)
id AA05409; Mon, 16 Jul 90 13:25:27 -0700
Resent-Message-Id: <[email protected]>
Received: from CHURCHY.NISC.SRI.COM by NISC.SRI.COM (5.61/SRI-NISC1.0) id
AA16619; Mon, 16 Jul 90 12:53:04 -0700
Received: by churchy.nisc.sri.com (5.61/SRI-NISC1.0) id AA05389; Mon, 16 Jul
90 12:50:41 -0700
Date: Mon, 16 Jul 90 12:50:41 -0700
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <[email protected]>
To: [email protected]
Resent-To: [email protected]
Resent-Date: Mon, 16 Jul 1990 13:25:24 PDT
Resent-From: Ken Harrenstien <[email protected]>
----- Transcript of session follows -----
550 [email protected]... Host unknown
----- Unsent message follows -----
Received: by churchy.nisc.sri.com (5.61/SRI-NISC1.0)
id AA05387; Mon, 16 Jul 90 12:50:41 -0700
Date: Mon, 16 Jul 1990 12:50:38 PDT
From: Ken Harrenstien <[email protected]>
To: [email protected] (Thomas Plum)
Cc: [email protected]
Subject: Re: Stanberry addr chg
In-Reply-To: Your message of Mon, 16 Jul 90 10:39:22 EDT
Message-Id: <[email protected]>
OK, done.
19-Jul-90 16:48:19-PDT,824;000000000000
Return-Path: <[email protected]>
Received: from osf.osf.org by NIC.DDN.MIL with TCP; Thu, 19 Jul 90 16:48:14 PDT
Received: by osf.osf.org (5.61/OSF 0.9)
id AA26316; Thu, 19 Jul 90 19:47:58 -0400
Date: Thu, 19 Jul 90 19:47:58 -0400
Message-Id: <[email protected]>
From: [email protected] (Michael Meissner)
Subject: Out of the office until who knows when
Brought-To-You-By: the Vacation program
Apparently-To: [email protected]
I am away from the office until who knows when, and am
therefore unable to respond to your mail until that time. If you
receive this message, it means that your mail was in fact delivered to
me successfully.
This should be the only time during the next week you
will be bothered by this message, even if you send me more
mail.
Michael Meissner
19-Jul-90 17:27:36-PDT,2973;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Thu, 19 Jul 90 17:27:31 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa14064; 19 Jul 90 20:23 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA19198; Thu, 19 Jul 90 17:23:18 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC17572; Thu, 19 Jul 90 17:20:10 PDT
Date: Thu, 19 Jul 90 17:20:10 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB17572; Thu, 19 Jul 90 17:20:10 PDT
Received: from relay.cs.net by RELAY.CS.NET id aa13589; 19 Jul 90 19:48 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa13251; 19 Jul 90 19:50 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 19 Jul 90 08:12:11 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12319; Thu, 19 Jul 90 11:11:53 -0400
Date: Thu, 19 Jul 90 08:11:54 EST
From: Rex Jaeschke <[email protected]>
Subject: extending identifier spellings
Message-Id: <9007190811.0.UUL1.3#[email protected]>
To: [email protected]
I just received the following mail from the Danish ISO C rep. Any
comments?
---------------
Date: Tue, 17 Jul 90 18:02:49 +0200
From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
Message-Id: <[email protected]>
To: [email protected]
Subject: another item for the addendum
X-Charset: US-DK
X-Char-Esc: 29
Dear collegues,
I would like to bring another issue about character handling in C
to your attention. This is concerning the use of non-ASCII letters
in identifiers.
This is requested in the SC22 ad hoc WG on character sets.
I think it is a fair request.
One very simple solution to it was to allow all alphabetic
characters of the compiling locale to be used in identifiers.
Can it be done just as clean and simple as that?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
regards
Keld
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
19-Jul-90 20:09:22-PDT,3698;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Thu, 19 Jul 90 20:09:17 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa16701; 19 Jul 90 22:17 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA22540; Thu, 19 Jul 90 19:01:21 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC19287; Thu, 19 Jul 90 18:58:07 PDT
Date: Thu, 19 Jul 90 18:58:07 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB19287; Thu, 19 Jul 90 18:58:07 PDT
Received: from relay.cs.net by RELAY.CS.NET id ab13716; 19 Jul 90 19:56 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa13453; 19 Jul 90 19:58 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 19 Jul 90 08:12:17 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12392; Thu, 19 Jul 90 11:12:06 -0400
Date: Thu, 19 Jul 90 08:21:23 EST
From: Rex Jaeschke <[email protected]>
Subject: More on extended identifier names
Message-Id: <9007190821.0.UUL1.3#[email protected]>
To: [email protected]
Some input from Japan.
----------------------
Return-Path: <[email protected]>
Subject: Non-ASCII in identifiers (was Re: another item for the addendum)
Keld J|rn Simonsen <[email protected]> writes:
> I would like to bring another issue about character handling in C
> to your attention. This is concerning the use of non-ASCII letters
> in identifiers.
I have felt Japanese would feel happy if we could use Kanji Characters
for identifiers. But I know the barrier in the Principle,
"C is English"
is very high. I am interested in the way how you(Keld san)
get over the barrier.
> One very simple solution to it was to allow all alphabetic
> characters of the compiling locale to be used in identifiers.
> Can it be done just as clean and simple as that?
I wonder it means that we won't be able to compile Japanese source
codes with US compilers.
I think there is no problem from the view of localization. But from
the view of I18N, we will lose source code portability between
different locales, which we now have on the current ANSI/ISO-C.
I find an idea to prepare for several levels of conformance;
1) Domestic conformance: we can use 'all alphabetic characters of the
compiling locale to be used in identifiers'. Of course, no
portability between different locales is ensured.
2) I18n conformance: we can use only all alphabetic characters in the
Basic Character Set in identifiers.
How do English people feel about our approach?
Norihiro Kumagai, SHARP Corp., JAPAN
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
21-Jul-90 13:06:08-PDT,2010;000000000000
Date: Sat, 21 Jul 90 13:05:28 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 19-Jul-90 08:12:25
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 19 Jul 90 08:12:11 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12319; Thu, 19 Jul 90 11:11:53 -0400
Date: Thu, 19 Jul 90 08:11:54 EST
From: [email protected] (Rex Jaeschke)
Subject: extending identifier spellings
Message-Id: <9007190811.0.UUL1.3#[email protected]>
To: [email protected]
I just received the following mail from the Danish ISO C rep. Any
comments?
---------------
Date: Tue, 17 Jul 90 18:02:49 +0200
From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
Message-Id: <[email protected]>
To: [email protected]
Subject: another item for the addendum
X-Charset: US-DK
X-Char-Esc: 29
Dear collegues,
I would like to bring another issue about character handling in C
to your attention. This is concerning the use of non-ASCII letters
in identifiers.
This is requested in the SC22 ad hoc WG on character sets.
I think it is a fair request.
One very simple solution to it was to allow all alphabetic
characters of the compiling locale to be used in identifiers.
Can it be done just as clean and simple as that?
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
regards
Keld
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
21-Jul-90 13:11:07-PDT,2735;000000000000
Date: Sat, 21 Jul 90 13:07:53 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 19-Jul-90 08:12:30
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 19 Jul 90 08:12:17 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12392; Thu, 19 Jul 90 11:12:06 -0400
Date: Thu, 19 Jul 90 08:21:23 EST
From: [email protected] (Rex Jaeschke)
Subject: More on extended identifier names
Message-Id: <9007190821.0.UUL1.3#[email protected]>
To: [email protected]
Some input from Japan.
----------------------
Return-Path: <[email protected]>
Subject: Non-ASCII in identifiers (was Re: another item for the addendum)
Keld J|rn Simonsen <[email protected]> writes:
> I would like to bring another issue about character handling in C
> to your attention. This is concerning the use of non-ASCII letters
> in identifiers.
I have felt Japanese would feel happy if we could use Kanji Characters
for identifiers. But I know the barrier in the Principle,
"C is English"
is very high. I am interested in the way how you(Keld san)
get over the barrier.
> One very simple solution to it was to allow all alphabetic
> characters of the compiling locale to be used in identifiers.
> Can it be done just as clean and simple as that?
I wonder it means that we won't be able to compile Japanese source
codes with US compilers.
I think there is no problem from the view of localization. But from
the view of I18N, we will lose source code portability between
different locales, which we now have on the current ANSI/ISO-C.
I find an idea to prepare for several levels of conformance;
1) Domestic conformance: we can use 'all alphabetic characters of the
compiling locale to be used in identifiers'. Of course, no
portability between different locales is ensured.
2) I18n conformance: we can use only all alphabetic characters in the
Basic Character Set in identifiers.
How do English people feel about our approach?
Norihiro Kumagai, SHARP Corp., JAPAN
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
27-Jul-90 08:02:31-PDT,1127;000000000000
Return-Path: <sdrc!scjones%[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 27 Jul 90 08:02:25 PDT
Received: from sdrc.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23325; Fri, 27 Jul 90 11:02:30 -0400
Received: from thor by sdrc; Fri, 27 Jul 90 10:58:40 edt
Received: by thor; Fri, 27 Jul 90 10:48:40 EDT
Date: Fri, 27 Jul 90 10:48:40 EDT
From: Larry Jones <sdrc!scjones%[email protected]>
Message-Id: <9007271448.AA02362@thor>
To: [email protected]
Subject: GKS-3D and PHIGS PLUS C Language Bindings
I have just received the latest draft of the C Language Binding
for GKS-3D (ISO DIS 8806-4) and the initial draft of the C
Language Binding for PHIGS PLUS. If anyone would like a copy of
either of these documents, let me know.
----
Larry Jones UUCP: uunet!sdrc!thor!scjones
SDRC [email protected]
2000 Eastman Dr. BIX: ltl
Milford, OH 45150-2789 AT&T: (513) 576-2070
"This probably just goes to show something, but I sure don't know what."
-Calvin
3-Aug-90 10:06:48-PDT,938;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 3 Aug 90 10:04:49 PDT
Received: from edg1.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23859; Fri, 3 Aug 90 08:27:27 -0400
Received: by edg1.com (3.2/SMI-3.2)
id AA12072; Fri, 3 Aug 90 08:24:26 EDT
Date: Fri, 3 Aug 90 08:24:26 EDT
From: [email protected] (J. Stephen Adamczyk)
Message-Id: <[email protected]>
To: [email protected]
Subject: New email address
Uunet recently abandoned support for the xxx.UU.NET form of address
(they were doing that as a favor to people who didn't have domain names,
but it was so convenient that no one was applying for real domain names).
I therefore have a new email address with a real domain name:
[email protected]
Would you please update my entry on the x3j11 list? Thanks.
Steve Adamczyk (uunet!edg1!jsa or [email protected]; 201-744-2620)
29-Aug-90 17:23:38-PDT,1676;000000000000
Date: Wed, 29 Aug 90 17:20:51 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 29-Aug-90 11:57:11
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 29 Aug 90 11:57:05 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA21585; Wed, 29 Aug 90 14:56:37 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA05870; Wed, 29 Aug 90 14:35:19 EDT
Date: Wed, 29 Aug 90 14:35:19 EDT
From: [email protected] (0000-Admin(0000))
Message-Id: <[email protected]>
To: [email protected]
Subject: info re NIST
This is an information request to the e-mail list of X3J11.
After our recent negotiations at the US National Institute of
Standards and Technology (NIST), I have begun to wonder whether
they have consulted any C experts in their choice of test suites.
If any of you have been asked by them to help evaluate the technical
merit of test suites for C, would you be so kind as to let me
know that you have done so. (I would understand, of course, that
any actual results of evaluation would be private information.)
This is a matter of major importance to us, and it would take only
a few seconds of your time.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
-------
29-Aug-90 18:25:26-PDT,2663;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 29 Aug 90 18:25:19 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa08250; 29 Aug 90 21:24 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA02390; Wed, 29 Aug 90 18:24:41 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AA01198; Wed, 29 Aug 90 18:21:44 PDT
Date: Wed, 29 Aug 90 18:21:44 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from tektronix.tek.com by zephyr.ENS.TEK.COM (4.1/7.1)
id AG00677; Wed, 29 Aug 90 18:12:39 PDT
Received: from relay.cs.net by RELAY.CS.NET id ab07307; 29 Aug 90 20:18 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa03976; 29 Aug 90 20:19 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 29 Aug 90 11:57:05 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA21585; Wed, 29 Aug 90 14:56:37 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA05870; Wed, 29 Aug 90 14:35:19 EDT
Date: Wed, 29 Aug 90 14:35:19 EDT
From: "0000-Admin(0000" <[email protected]>
Mmdf-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <[email protected]>
To: [email protected]
Subject: info re NIST
This is an information request to the e-mail list of X3J11.
After our recent negotiations at the US National Institute of
Standards and Technology (NIST), I have begun to wonder whether
they have consulted any C experts in their choice of test suites.
If any of you have been asked by them to help evaluate the technical
merit of test suites for C, would you be so kind as to let me
know that you have done so. (I would understand, of course, that
any actual results of evaluation would be private information.)
This is a matter of major importance to us, and it would take only
a few seconds of your time.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
29-Aug-90 19:14:47-PDT,2244;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 29 Aug 90 19:14:44 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA07672; Wed, 29 Aug 90 22:14:19 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AB17837; Wed, 29 Aug 90 19:45:16 -0500
Date: Wed, 29 Aug 90 19:45:16 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA17733; Wed, 29 Aug 90 19:30:13 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA19551; Wed, 29 Aug 90 20:19:15 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 29 Aug 90 11:57:05 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA21585; Wed, 29 Aug 90 14:56:37 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA05870; Wed, 29 Aug 90 14:35:19 EDT
Date: Wed, 29 Aug 90 14:35:19 EDT
From: uunet!plumhall!root (0000-Admin(0000))
Message-Id: <[email protected]>
To: [email protected]
Subject: info re NIST
This is an information request to the e-mail list of X3J11.
After our recent negotiations at the US National Institute of
Standards and Technology (NIST), I have begun to wonder whether
they have consulted any C experts in their choice of test suites.
If any of you have been asked by them to help evaluate the technical
merit of test suites for C, would you be so kind as to let me
know that you have done so. (I would understand, of course, that
any actual results of evaluation would be private information.)
This is a matter of major importance to us, and it would take only
a few seconds of your time.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
1-Sep-90 14:08:49-PDT,7567;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Sat, 1 Sep 90 14:08:37 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa25189; 1 Sep 90 17:07 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA24911; Sat, 1 Sep 90 14:07:14 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AA16394; Sat, 1 Sep 90 14:07:41 PDT
Date: Sat, 1 Sep 90 14:07:41 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB16389; Sat, 1 Sep 90 14:07:41 PDT
Received: from relay.cs.net by RELAY.CS.NET id ab06376; 1 Sep 90 17:05 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa25017; 1 Sep 90 17:04 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 1 Sep 90 13:51:00 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA11358; Sat, 1 Sep 90 16:48:06 -0400
Date: Sat, 1 Sep 90 15:16:30 EST
From: Rex Jaeschke <[email protected]>
Subject: Request for Interpretation
Message-Id: <9009011516.0.UUL1.3#[email protected]>
To: [email protected]
I recently received the following from Japan. If anyone can shed any
light on the matter please email them directly, copying me. I shall
endeavor to get this on the agenda for the Sept meeting for an
official opinion.
------------------------------------------------
From mcsun!tsbome!ynk Sun Aug 26 06:04:21 1990 remote from uunet
Received: by aussie.UUCP (UUL1.3#5077)
from uunet with UUCP; Mon, 27 Aug 90 05:04:01 EST
Received: from mcsun.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA28196; Sun, 26 Aug 90 06:04:21 -0400
Received: by mcsun.EU.net via EUnet; Sun, 26 Aug 90 12:02:11 +0200 (MET)
Received: from mcsun.eu.net by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8)
id AA22891; Sun, 26 Aug 90 11:39:44 +0200
Received: by mcsun.EU.net via EUnet; Sun, 26 Aug 90 11:40:21 +0200 (MET)
From: uunet!tis1.tis.toshiba.co.jp!ynk%tsbome
Received: by kddlab.kddlabs.co.jp (4.0/6.2Junet)
id AA02244; Sun, 26 Aug 90 10:12:51 JST
Received: by tis1.tis.toshiba.co.jp (3.2/6.4J.6-R17)
id AA01695; Sun, 26 Aug 90 03:38:04 JST
Return-Path: <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Request for interpretation of (f)scanf in DIS9899
Date: Sat Aug 25 16:49:27 JST 1990
X-Charset: ASCII
X-Char-Esc: 29
Dear C language Experts,
This is a request for interpretation of the DIS9899 or ANSI/C Standard.
Could anyone clarify the rationale or forward this request to the
appropriate committee/people?
This request has been raised during the Japanese SC22/C Committee
meeting held in August, targeting the submission of our next draft of
Multibyte Support Extension to the ISO SC22/WG14 Copenhagen meeting.
It is unclear how the (f)scanf function shall behave when executing
directives that include "ordinary multibyte characters", especially
in the case of shift-encoded ordinary multibyte characters.
The following statements are described in "Section 4.9.6.2 The fscanf
Function" of the current Standard.
: A directive that is an ordinary multibyte character is executed
: by reading the next characters of the stream. If one of the
: characters differs from one comprising the directive, the
: directive fails, and the differing and subsequent characters
: remain unread.
Assume a typical shift encoded directive: A-UMLAUT in 7 bit representation.
And, consider two different encoding systems; Latin Alphabet No.1 - 8859/1,
and German Standard DIN 66 003. The codes are, for example,
A-UMLAUT in 8859/1 : SO 4/4 SI
A-UMLAUT in DIN 66 003 : ESC 2/8 4/11 5/11 ESC 2/8 4/2
where, SO is a Shift-Out code (0/15 = 0x0f) and SI corresponds to
a Shift-In code (0/14). "ESC 2/8 4/11" is an escape sequence for
the German Standard DIN 66 003, and "ESC 2/8 4/2" is for ISO 646
USA Version (ASCII).
Assuming that a subject sequence includes A-UMLAUT, O-UMLAUT and
U-UMLAUT with the following 7 bit representations,
In 8859/1 : SO 4/4 5/6 5/12 SI
In DIN 66 003 : ESC 2/8 4/11 5/11 5/12 5/13 ESC 2/8 4/2
does the "A-UMLAUT" directive in the (f)scanf format string match the
beginning part of the "A-UMLAUT O-UMLAUT U-UMLAUT" sequence?
At what position of the target sequence shall the "A-UMLAUT" directive
fail?
One interpretation is that because the current Standard defined the
behavior of the directive in the (f)scanf format based on the word
"character"(byte), not using the word "multibyte character",
the comparison shall be done on byte-by-byte basis. This may conclude
that the "A-UMLAUT" directive never match the "A-UMLAUT O-UMLAUT U-UMLAUT"
sequence in this case.
Another interpretation may lead to a reverse conclusion, saying that
the current Standard statements quoted above do not necessarily
mean that such comparison shall be done on byte-by-byte basis.
Instead, it is read that the matching shall be done on "multibyte
character by multibyte character basis" or rather "wide character by
wide character basis". Especially, a "ghost" sequence like "ESC ..."
and SI/SO characters should not be regarded as independent ordinary
multibyte characters in this case.
Which is a correct interpretation of the current Standard?
These different interpretations are caused by the ambiguity of the
current Standard descriptions. Also, it would be pointed out that
the major problem here is usage of the word "character".
The generic word "character" and the specific word "character(=byte)"
should be properly discriminated in the Standard.
In any case, would you all, especially U.S.A. representatives and U.K.
representatives, please respond to the question?
Any your comments and suggestions are welcome.
If there are good rationale on this subject in the ANSI X3J11 Committee
or in the ISO/SC22/WG14 Committee, please let us know as soon as possible.
It would be greatly appreciated, as the Japanese SC22/C Committee is now
finalizing our MSE proposal including enhancement of the (f)scanf
functionality for wide characters.
Thank you for your consideration of this matter.
Best Regards,
Yasushi Nakahara
TOSHIBA Corp.
Phone: +81 472-77-8670 Fax: +81 472-79-2628
Email: [email protected]
---------------------------------------------------------------
I am able to reach him using [email protected]
---------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
1-Sep-90 14:10:43-PDT,6686;000000000000
Date: Sat, 1 Sep 90 14:06:19 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 1-Sep-90 13:51:08
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 1 Sep 90 13:51:00 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA11358; Sat, 1 Sep 90 16:48:06 -0400
Date: Sat, 1 Sep 90 15:16:30 EST
From: [email protected] (Rex Jaeschke)
Subject: Request for Interpretation
Message-Id: <9009011516.0.UUL1.3#[email protected]>
To: [email protected]
I recently received the following from Japan. If anyone can shed any
light on the matter please email them directly, copying me. I shall
endeavor to get this on the agenda for the Sept meeting for an
official opinion.
------------------------------------------------
From mcsun!tsbome!ynk Sun Aug 26 06:04:21 1990 remote from uunet
Received: by aussie.UUCP (UUL1.3#5077)
from uunet with UUCP; Mon, 27 Aug 90 05:04:01 EST
Received: from mcsun.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA28196; Sun, 26 Aug 90 06:04:21 -0400
Received: by mcsun.EU.net via EUnet; Sun, 26 Aug 90 12:02:11 +0200 (MET)
Received: from mcsun.eu.net by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8)
id AA22891; Sun, 26 Aug 90 11:39:44 +0200
Received: by mcsun.EU.net via EUnet; Sun, 26 Aug 90 11:40:21 +0200 (MET)
From: uunet!tis1.tis.toshiba.co.jp!ynk%tsbome
Received: by kddlab.kddlabs.co.jp (4.0/6.2Junet)
id AA02244; Sun, 26 Aug 90 10:12:51 JST
Received: by tis1.tis.toshiba.co.jp (3.2/6.4J.6-R17)
id AA01695; Sun, 26 Aug 90 03:38:04 JST
Return-Path: <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Request for interpretation of (f)scanf in DIS9899
Date: Sat Aug 25 16:49:27 JST 1990
X-Charset: ASCII
X-Char-Esc: 29
Dear C language Experts,
This is a request for interpretation of the DIS9899 or ANSI/C Standard.
Could anyone clarify the rationale or forward this request to the
appropriate committee/people?
This request has been raised during the Japanese SC22/C Committee
meeting held in August, targeting the submission of our next draft of
Multibyte Support Extension to the ISO SC22/WG14 Copenhagen meeting.
It is unclear how the (f)scanf function shall behave when executing
directives that include "ordinary multibyte characters", especially
in the case of shift-encoded ordinary multibyte characters.
The following statements are described in "Section 4.9.6.2 The fscanf
Function" of the current Standard.
: A directive that is an ordinary multibyte character is executed
: by reading the next characters of the stream. If one of the
: characters differs from one comprising the directive, the
: directive fails, and the differing and subsequent characters
: remain unread.
Assume a typical shift encoded directive: A-UMLAUT in 7 bit representation.
And, consider two different encoding systems; Latin Alphabet No.1 - 8859/1,
and German Standard DIN 66 003. The codes are, for example,
A-UMLAUT in 8859/1 : SO 4/4 SI
A-UMLAUT in DIN 66 003 : ESC 2/8 4/11 5/11 ESC 2/8 4/2
where, SO is a Shift-Out code (0/15 = 0x0f) and SI corresponds to
a Shift-In code (0/14). "ESC 2/8 4/11" is an escape sequence for
the German Standard DIN 66 003, and "ESC 2/8 4/2" is for ISO 646
USA Version (ASCII).
Assuming that a subject sequence includes A-UMLAUT, O-UMLAUT and
U-UMLAUT with the following 7 bit representations,
In 8859/1 : SO 4/4 5/6 5/12 SI
In DIN 66 003 : ESC 2/8 4/11 5/11 5/12 5/13 ESC 2/8 4/2
does the "A-UMLAUT" directive in the (f)scanf format string match the
beginning part of the "A-UMLAUT O-UMLAUT U-UMLAUT" sequence?
At what position of the target sequence shall the "A-UMLAUT" directive
fail?
One interpretation is that because the current Standard defined the
behavior of the directive in the (f)scanf format based on the word
"character"(byte), not using the word "multibyte character",
the comparison shall be done on byte-by-byte basis. This may conclude
that the "A-UMLAUT" directive never match the "A-UMLAUT O-UMLAUT U-UMLAUT"
sequence in this case.
Another interpretation may lead to a reverse conclusion, saying that
the current Standard statements quoted above do not necessarily
mean that such comparison shall be done on byte-by-byte basis.
Instead, it is read that the matching shall be done on "multibyte
character by multibyte character basis" or rather "wide character by
wide character basis". Especially, a "ghost" sequence like "ESC ..."
and SI/SO characters should not be regarded as independent ordinary
multibyte characters in this case.
Which is a correct interpretation of the current Standard?
These different interpretations are caused by the ambiguity of the
current Standard descriptions. Also, it would be pointed out that
the major problem here is usage of the word "character".
The generic word "character" and the specific word "character(=byte)"
should be properly discriminated in the Standard.
In any case, would you all, especially U.S.A. representatives and U.K.
representatives, please respond to the question?
Any your comments and suggestions are welcome.
If there are good rationale on this subject in the ANSI X3J11 Committee
or in the ISO/SC22/WG14 Committee, please let us know as soon as possible.
It would be greatly appreciated, as the Japanese SC22/C Committee is now
finalizing our MSE proposal including enhancement of the (f)scanf
functionality for wide characters.
Thank you for your consideration of this matter.
Best Regards,
Yasushi Nakahara
TOSHIBA Corp.
Phone: +81 472-77-8670 Fax: +81 472-79-2628
Email: [email protected]
---------------------------------------------------------------
I am able to reach him using [email protected]
---------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
3-Sep-90 05:42:34-PDT,1602;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Mon, 3 Sep 90 05:42:31 PDT
Received: from relay2.cs.net by RELAY.CS.NET id bb21296; 3 Sep 90 8:40 EDT
Date: Mon, 3 Sep 90 8:10:27 EDT
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa07267)
To: [email protected]
After 5 days (106 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa07267; 29 Aug 90 20:16 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 29 Aug 90 11:57:05 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA21585; Wed, 29 Aug 90 14:56:37 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA05870; Wed, 29 Aug 90 14:35:19 EDT
Date: Wed, 29 Aug 90 14:35:19 EDT
From: [email protected] (0000-Admin(0000))
Message-Id: <[email protected]>
To: [email protected]
Subject: info re NIST
This is an information request to the e-mail list of X3J11.
After our recent negotiations at the US National Institute of
...
5-Sep-90 05:51:30-PDT,2179;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 5 Sep 90 05:51:27 PDT
Received: from relay2.cs.net by RELAY.CS.NET id bb14096; 5 Sep 90 8:50 EDT
Date: Wed, 5 Sep 90 8:24:01 EDT
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Failed mail (msg.aa07267)
To: [email protected]
After 7 days (154 hours), your message could not be
fully delivered.
It failed to be received by the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa07267; 29 Aug 90 20:16 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 29 Aug 90 11:57:05 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA21585; Wed, 29 Aug 90 14:56:37 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA05870; Wed, 29 Aug 90 14:35:19 EDT
Date: Wed, 29 Aug 90 14:35:19 EDT
From: [email protected] (0000-Admin(0000))
Message-Id: <[email protected]>
To: [email protected]
Subject: info re NIST
This is an information request to the e-mail list of X3J11.
After our recent negotiations at the US National Institute of
Standards and Technology (NIST), I have begun to wonder whether
they have consulted any C experts in their choice of test suites.
If any of you have been asked by them to help evaluate the technical
merit of test suites for C, would you be so kind as to let me
know that you have done so. (I would understand, of course, that
any actual results of evaluation would be private information.)
This is a matter of major importance to us, and it would take only
a few seconds of your time.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
6-Sep-90 04:12:52-PDT,1507;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Thu, 6 Sep 90 04:12:49 PDT
Received: from relay2.cs.net by RELAY.CS.NET id as27577; 6 Sep 90 7:12 EDT
Date: Thu, 6 Sep 90 7:07:35 EDT
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa06367)
To: [email protected]
After 5 days (109 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa06367; 1 Sep 90 17:04 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 1 Sep 90 13:51:00 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA11358; Sat, 1 Sep 90 16:48:06 -0400
Date: Sat, 1 Sep 90 15:16:30 EST
From: [email protected] (Rex Jaeschke)
Subject: Request for Interpretation
Message-Id: <9009011516.0.UUL1.3#[email protected]>
To: [email protected]
I recently received the following from Japan. If anyone can shed any
light on the matter please email them directly, copying me. I shall
...
7-Sep-90 19:50:49-PDT,1271;000000000000
Date: Fri, 7 Sep 90 19:49:08 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 7-Sep-90 17:45:53
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 17:45:46 PDT
Received: from ibmsupt.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23133; Fri, 7 Sep 90 20:45:47 -0400
Received: by ibmsupt.UUCP (5.51/5.17)
id AA12886; Fri, 7 Sep 90 10:21:30 19
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA19713; Fri, 7 Sep 90 09:57:39 -0700
Date: Fri, 7 Sep 90 09:57:39 -0700
From: [email protected] (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: Should atof and/or scanf set errno if strtod sets errno?
Consider the statements:
i = sscanf( "1e9999", "%lf", &double_var );
double_var = strtod( "1e9999", (char **)NULL);
double_var = atof( "1e9999" );
on a machine where 1e9999 is bigger than DBL_MAX, ie, overflows.
errno should be set to ERANGE by strtod. What should happen
to errno for atof and sscanf?
-------
7-Sep-90 20:02:09-PDT,2152;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 20:02:05 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa29531; 7 Sep 90 23:01 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA09494; Fri, 7 Sep 90 20:01:50 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC08341; Fri, 7 Sep 90 20:01:47 PDT
Date: Fri, 7 Sep 90 20:01:47 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB08341; Fri, 7 Sep 90 20:01:47 PDT
Received: from relay.cs.net by RELAY.CS.NET id ab01874; 7 Sep 90 22:48 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa28861; 7 Sep 90 22:48 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 17:45:46 PDT
Received: from ibmsupt.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23133; Fri, 7 Sep 90 20:45:47 -0400
Received: by ibmsupt.UUCP (5.51/5.17)
id AA12886; Fri, 7 Sep 90 10:21:30 19
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA19713; Fri, 7 Sep 90 09:57:39 -0700
Date: Fri, 7 Sep 90 09:57:39 -0700
From: Fred Tydeman <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Should atof and/or scanf set errno if strtod sets errno?
Consider the statements:
i = sscanf( "1e9999", "%lf", &double_var );
double_var = strtod( "1e9999", (char **)NULL);
double_var = atof( "1e9999" );
on a machine where 1e9999 is bigger than DBL_MAX, ie, overflows.
errno should be set to ERANGE by strtod. What should happen
to errno for atof and sscanf?
8-Sep-90 04:51:50-PDT,1835;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 8 Sep 90 04:51:46 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02138; Sat, 8 Sep 90 07:51:53 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA11684; Sat, 8 Sep 90 06:54:13 -0500
Date: Sat, 8 Sep 90 06:54:13 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA11445; Sat, 8 Sep 90 06:13:15 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA19871; Sat, 8 Sep 90 06:28:16 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 17:45:46 PDT
Received: from ibmsupt.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23133; Fri, 7 Sep 90 20:45:47 -0400
Received: by ibmsupt.UUCP (5.51/5.17)
id AA12886; Fri, 7 Sep 90 10:21:30 19
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA19713; Fri, 7 Sep 90 09:57:39 -0700
Date: Fri, 7 Sep 90 09:57:39 -0700
From: uunet!ibmsupt!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: Should atof and/or scanf set errno if strtod sets errno?
Consider the statements:
i = sscanf( "1e9999", "%lf", &double_var );
double_var = strtod( "1e9999", (char **)NULL);
double_var = atof( "1e9999" );
on a machine where 1e9999 is bigger than DBL_MAX, ie, overflows.
errno should be set to ERANGE by strtod. What should happen
to errno for atof and sscanf?
8-Sep-90 23:52:19-PDT,1971;000000000000
Return-Path: <[email protected]>
Received: from ames.arc.nasa.gov by NIC.DDN.MIL with TCP; Sat, 8 Sep 90 23:52:16 PDT
Received: by ames.arc.nasa.gov (5.64/1.2); Sat, 8 Sep 90 23:52:22 -0700
Received: by AMD.COM (4.1/SMI-4.1-AMD-90.4.28)
id AA17179; Sat, 8 Sep 90 23:46:58 PDT
Date: Sat, 8 Sep 90 23:46:58 PDT
From: [email protected]
Message-Id: <[email protected]>
Subject: Warning From uucp
Apparently-To: [email protected]
To: [email protected]
We have been unable to contact machine 'sun0' since you queued your job.
mail sun0!fay (Date 09/07)
Attempts will continue for a few more days.
Sincerely,
amdcad!uucp
#############################################
##### Data File: ############################
From NIC.DDN.MIL!x3j11-RELAY Fri Sep 7 19:50:29 1990 remote from amdcad
Received: from NIC.DDN.MIL by AMD.COM (4.1/SMI-4.1-AMD-90.4.28)
id AA21324; Fri, 7 Sep 90 19:50:29 PDT
Received: by decwrl.dec.com; id AA24958; Fri, 7 Sep 90 19:49:13 -0700
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 7 Sep 90 17:45:46 PDT
Received: from ibmsupt.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23133; Fri, 7 Sep 90 20:45:47 -0400
Received: by ibmsupt.UUCP (5.51/5.17)
id AA12886; Fri, 7 Sep 90 10:21:30 19
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA19713; Fri, 7 Sep 90 09:57:39 -0700
Date: Fri, 7 Sep 90 09:57:39 -0700
From: amdcad!decwrl!uunet.UU.NET!ibmsupt!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: uunet.UU.NET!uunet!sri-nic.arpa!x3j11
Subject: Should atof and/or scanf set errno if strtod sets errno?
Consider the statements:
i = sscanf( "1e9999", "%lf", &double_var );
double_var = strtod( "1e9999", (char **)NULL);
double_var = atof( "1e9999" );
on a machine where 1e9999 is bigger than DBL_MAX, ie, overflows.
errno should be set to ERANGE by strtod. What should happen
to errno for atof and sscanf?
10-Sep-90 20:37:22-PDT,1146;000000000000
Date: Mon, 10 Sep 90 20:36:54 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 10-Sep-90 17:13:35
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 17:13:31 PDT
Received: from TI.COM by uunet.uu.net (5.61/1.14) with SMTP
id AA07963; Mon, 10 Sep 90 14:39:19 -0400
Received: by ti.com id AA05118; Mon, 10 Sep 90 13:25:07 -0500
Received: from tilde by ti-csl id AA26976; Mon, 10 Sep 90 09:06:18 CDT
Received: from m2.csc.ti.com by tilde id AA05101; Mon, 10 Sep 90 09:08:27 -0500
Received: by m2.csc.ti.com (5.64+/4.7)
id AA19823; Mon, 10 Sep 90 09:08:26 -0500
Date: Mon, 10 Sep 90 09:08:26 -0500
From: [email protected] (Reid Tatge)
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: Re: Should atof and/or scanf set errno if strtod sets errno?
Fred,
My interpretation of the standard,
-------
10-Sep-90 20:47:20-PDT,1876;000000000000
Date: Mon, 10 Sep 90 20:43:54 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 10-Sep-90 17:23:55
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 17:23:50 PDT
Received: from osf.osf.org by uunet.uu.net (5.61/1.14) with SMTP
id AA02181; Mon, 10 Sep 90 10:42:32 -0400
Received: from curley.osf.org by osf.osf.org (5.61/OSF 0.9)
id AA03998; Mon, 10 Sep 90 10:42:29 -0400
Received: by curley.osf.org (5.61/4.7) id AA11695; Mon, 10 Sep 90 10:42:27 -0400
Date: Mon, 10 Sep 90 10:42:27 -0400
From: [email protected]
Message-Id: <[email protected]>
To: [email protected] (Fred Tydeman)
Cc: [email protected]
In-Reply-To: <[email protected]>
Subject: Should atof and/or scanf set errno if strtod sets errno?
Fred Tydeman writes:
| Consider the statements:
| i = sscanf( "1e9999", "%lf", &double_var );
| double_var = strtod( "1e9999", (char **)NULL);
| double_var = atof( "1e9999" );
| on a machine where 1e9999 is bigger than DBL_MAX, ie, overflows.
| errno should be set to ERANGE by strtod. What should happen
| to errno for atof and sscanf?
IMHO, it doesn't matter. Any of the library functions can set errno,
even for successful returns, unless they explicitly set errno. This
was because people wanted a fast, clunky atof which is not required to
set errno, and a more reasonable function that does set errno.
--
Michael Meissner email: [email protected] phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
Do apple growers tell their kids money doesn't grow on bushes?
-------
11-Sep-90 00:08:10-PDT,1720;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 11 Sep 90 00:08:04 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA10941; Tue, 11 Sep 90 03:08:02 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA18743; Tue, 11 Sep 90 01:30:32 -0500
Date: Tue, 11 Sep 90 01:30:32 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA15364; Tue, 11 Sep 90 00:32:14 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA29201; Mon, 10 Sep 90 23:35:46 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 17:13:31 PDT
Received: from TI.COM by uunet.uu.net (5.61/1.14) with SMTP
id AA07963; Mon, 10 Sep 90 14:39:19 -0400
Received: by ti.com id AA05118; Mon, 10 Sep 90 13:25:07 -0500
Received: from tilde by ti-csl id AA26976; Mon, 10 Sep 90 09:06:18 CDT
Received: from m2.csc.ti.com by tilde id AA05101; Mon, 10 Sep 90 09:08:27 -0500
Received: by m2.csc.ti.com (5.64+/4.7)
id AA19823; Mon, 10 Sep 90 09:08:26 -0500
Date: Mon, 10 Sep 90 09:08:26 -0500
From: uunet!m2.csc.ti.com!tatge (Reid Tatge)
Message-Id: <[email protected]>
To: ibmsupt!ibmpa!tydeman, [email protected]
Subject: Re: Should atof and/or scanf set errno if strtod sets errno?
Fred,
My interpretation of the standard,
11-Sep-90 00:08:14-PDT,2450;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 11 Sep 90 00:08:05 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA11004; Tue, 11 Sep 90 03:08:05 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AB18743; Tue, 11 Sep 90 01:30:35 -0500
Date: Tue, 11 Sep 90 01:30:35 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA15365; Tue, 11 Sep 90 00:32:16 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA01301; Mon, 10 Sep 90 23:41:17 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 17:23:50 PDT
Received: from osf.osf.org by uunet.uu.net (5.61/1.14) with SMTP
id AA02181; Mon, 10 Sep 90 10:42:32 -0400
Received: from curley.osf.org by osf.osf.org (5.61/OSF 0.9)
id AA03998; Mon, 10 Sep 90 10:42:29 -0400
Received: by curley.osf.org (5.61/4.7) id AA11695; Mon, 10 Sep 90 10:42:27 -0400
Date: Mon, 10 Sep 90 10:42:27 -0400
From: uunet!osf.org!meissner
Message-Id: <[email protected]>
To: ibmsupt!ibmpa!tydeman (Fred Tydeman)
Cc: [email protected]
In-Reply-To: <[email protected]>
Subject: Should atof and/or scanf set errno if strtod sets errno?
Fred Tydeman writes:
| Consider the statements:
| i = sscanf( "1e9999", "%lf", &double_var );
| double_var = strtod( "1e9999", (char **)NULL);
| double_var = atof( "1e9999" );
| on a machine where 1e9999 is bigger than DBL_MAX, ie, overflows.
| errno should be set to ERANGE by strtod. What should happen
| to errno for atof and sscanf?
IMHO, it doesn't matter. Any of the library functions can set errno,
even for successful returns, unless they explicitly set errno. This
was because people wanted a fast, clunky atof which is not required to
set errno, and a more reasonable function that does set errno.
--
Michael Meissner email: [email protected] phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
Do apple growers tell their kids money doesn't grow on bushes?
11-Sep-90 06:02:44-PDT,2049;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 11 Sep 90 06:02:38 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa02331; 11 Sep 90 9:02 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA08715; Tue, 11 Sep 90 06:03:05 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AB26809; Tue, 11 Sep 90 06:02:59 PDT
Date: Tue, 11 Sep 90 06:02:59 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from tektronix.tek.com by zephyr.ENS.TEK.COM (4.1/7.1)
id AB14747; Mon, 10 Sep 90 20:48:56 PDT
Received: from relay.cs.net by RELAY.CS.NET id ac05877; 10 Sep 90 23:35 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa22491; 10 Sep 90 23:36 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 17:13:31 PDT
Received: from TI.COM by uunet.uu.net (5.61/1.14) with SMTP
id AA07963; Mon, 10 Sep 90 14:39:19 -0400
Received: by ti.com id AA05118; Mon, 10 Sep 90 13:25:07 -0500
Received: from tilde by ti-csl id AA26976; Mon, 10 Sep 90 09:06:18 CDT
Received: from m2.csc.ti.com by tilde id AA05101; Mon, 10 Sep 90 09:08:27 -0500
Received: by m2.csc.ti.com (5.64+/4.7)
id AA19823; Mon, 10 Sep 90 09:08:26 -0500
Date: Mon, 10 Sep 90 09:08:26 -0500
From: Reid Tatge <[email protected]>
Message-Id: <[email protected]>
To: [email protected], [email protected]
Subject: Re: Should atof and/or scanf set errno if strtod sets errno?
Fred,
My interpretation of the standard,
11-Sep-90 06:03:44-PDT,2779;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 11 Sep 90 06:03:40 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa02370; 11 Sep 90 9:03 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA08746; Tue, 11 Sep 90 06:03:37 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AA26693; Tue, 11 Sep 90 06:03:28 PDT
Date: Tue, 11 Sep 90 06:03:28 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from tektronix.tek.com by zephyr.ENS.TEK.COM (4.1/7.1)
id AG14747; Mon, 10 Sep 90 20:49:36 PDT
Received: from relay.cs.net by RELAY.CS.NET id ac05925; 10 Sep 90 23:41 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa22894; 10 Sep 90 23:41 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 10 Sep 90 17:23:50 PDT
Received: from osf.osf.org by uunet.uu.net (5.61/1.14) with SMTP
id AA02181; Mon, 10 Sep 90 10:42:32 -0400
Received: from curley.osf.org by osf.osf.org (5.61/OSF 0.9)
id AA03998; Mon, 10 Sep 90 10:42:29 -0400
Received: by curley.osf.org (5.61/4.7) id AA11695; Mon, 10 Sep 90 10:42:27 -0400
Date: Mon, 10 Sep 90 10:42:27 -0400
From: [email protected]
Message-Id: <[email protected]>
To: Fred Tydeman <[email protected]>
Cc: [email protected]
In-Reply-To: <[email protected]>
Subject: Should atof and/or scanf set errno if strtod sets errno?
Fred Tydeman writes:
| Consider the statements:
| i = sscanf( "1e9999", "%lf", &double_var );
| double_var = strtod( "1e9999", (char **)NULL);
| double_var = atof( "1e9999" );
| on a machine where 1e9999 is bigger than DBL_MAX, ie, overflows.
| errno should be set to ERANGE by strtod. What should happen
| to errno for atof and sscanf?
IMHO, it doesn't matter. Any of the library functions can set errno,
even for successful returns, unless they explicitly set errno. This
was because people wanted a fast, clunky atof which is not required to
set errno, and a more reasonable function that does set errno.
--
Michael Meissner email: [email protected] phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142
Do apple growers tell their kids money doesn't grow on bushes?
18-Sep-90 18:44:59-PDT,1027;000000000000
Date: Tue, 18 Sep 90 18:44:17 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Sep-90 14:03:13
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from ocfmail.ocf.llnl.gov by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 14:03:07 PDT
Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0)
id AA17591; Tue, 18 Sep 90 14:04:37 PDT
Date: Tue, 18 Sep 90 14:04:37 PDT
From: [email protected] (Linda Stanberry)
Message-Id: <[email protected]>
To: [email protected]
Subject: ANSI C Meeting, September 24-25
X3J11 Member:
If you are planning on attending our meeting next week in Pleasanton, could
you please let me know? We are trying to be sure we are planning for the
right number of people. Could you also indicate if you will be staying at
the Pleasanton Hilton?
Thanks, and see you next week!
Linda
[email protected]
-------
18-Sep-90 18:48:41-PDT,1965;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 18:48:33 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa16236; 18 Sep 90 21:48 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA01187; Tue, 18 Sep 90 18:48:43 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC06140; Tue, 18 Sep 90 18:48:59 PDT
Date: Tue, 18 Sep 90 18:48:59 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB06140; Tue, 18 Sep 90 18:48:59 PDT
Received: from relay.cs.net by RELAY.CS.NET id aa16845; 18 Sep 90 21:42 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa16041; 18 Sep 90 21:43 EDT
Received: from ocfmail.ocf.llnl.gov by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 14:03:07 PDT
Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0)
id AA17591; Tue, 18 Sep 90 14:04:37 PDT
Date: Tue, 18 Sep 90 14:04:37 PDT
From: Linda Stanberry <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: ANSI C Meeting, September 24-25
X3J11 Member:
If you are planning on attending our meeting next week in Pleasanton, could
you please let me know? We are trying to be sure we are planning for the
right number of people. Could you also indicate if you will be staying at
the Pleasanton Hilton?
Thanks, and see you next week!
Linda
[email protected]
18-Sep-90 19:44:59-PDT,1003;000000000000
Date: Tue, 18 Sep 90 19:42:33 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Sep-90 14:03:13
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from ocfmail.ocf.llnl.gov by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 14:03:07 PDT
Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0)
id AA17591; Tue, 18 Sep 90 14:04:37 PDT
Date: Tue, 18 Sep 90 14:04:37 PDT
From: [email protected] (Linda Stanberry)
Message-Id: <[email protected]>
To: [email protected]
Subject: ANSI C Meeting, September 24-25
X3J11 Member:
If you are planning on attending our meeting next week in Pleasanton, could
you please let me know? We are trying to be sure we are planning for the
right number of people. Could you also indicate if you will be staying at
the Pleasanton Hilton?
Thanks, and see you next week!
Linda
[email protected]
-------
18-Sep-90 19:49:20-PDT,1679;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 19:49:15 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA15595; Tue, 18 Sep 90 22:49:15 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA07264; Tue, 18 Sep 90 22:19:18 -0500
Date: Tue, 18 Sep 90 22:19:18 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA06262; Tue, 18 Sep 90 21:43:23 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA18439; Tue, 18 Sep 90 21:43:38 -0400
Received: from ocfmail.ocf.llnl.gov by NIC.DDN.MIL with TCP; Tue, 18 Sep 90 14:03:07 PDT
Received: by ocfmail.ocf.llnl.gov (4.1/SMI-4.0)
id AA17591; Tue, 18 Sep 90 14:04:37 PDT
Date: Tue, 18 Sep 90 14:04:37 PDT
From: uunet!ocfmail.ocf.llnl.gov!linda (Linda Stanberry)
Message-Id: <[email protected]>
To: [email protected]
Subject: ANSI C Meeting, September 24-25
X3J11 Member:
If you are planning on attending our meeting next week in Pleasanton, could
you please let me know? We are trying to be sure we are planning for the
right number of people. Could you also indicate if you will be staying at
the Pleasanton Hilton?
Thanks, and see you next week!
Linda
[email protected]
19-Sep-90 02:59:59-PDT,1427;000000000000
Date: Wed, 19 Sep 90 02:58:17 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 19-Sep-90 02:45:14
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 02:45:09 PDT
Received: from apple.com by RELAY.CS.NET id aa04813; 19 Sep 90 5:45 EDT
Received: by apple.com (5.61/25-eef)
id AA26032; Wed, 19 Sep 90 02:43:29 -0700
for
Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.1)
id <[email protected]>; Wed, 19 Sep 90 00:39 PDT
Received: by tde.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.8)
id <[email protected]>; Wed, 19 Sep 90 00:39 PDT
Message-Id: <[email protected]>
Date: Wed, 19 Sep 90 00:39 PDT
From: Neal Weidenhofer <nw%[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: Linda Stanberry's message of Tue, 18 Sep 90 14:04:37 PDT <[email protected]>
Subject: ANSI C Meeting, September 24-25
I'll be there but I'll be commuting from San Jose.
Neal Weidenhofer
[email protected]
Amdahl Corporation
1250 E. Arques Ave. (M/S 316)
P. O. Box 3470
Sunnyvale, CA 94088-3470
(408)737-5007
-------
19-Sep-90 03:02:49-PDT,2311;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 03:02:45 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa05634; 19 Sep 90 6:02 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA10860; Wed, 19 Sep 90 03:02:37 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC16214; Wed, 19 Sep 90 03:02:47 PDT
Date: Wed, 19 Sep 90 03:02:47 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB16214; Wed, 19 Sep 90 03:02:47 PDT
Received: from relay.cs.net by RELAY.CS.NET id aa22080; 19 Sep 90 5:56 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa05429; 19 Sep 90 5:57 EDT
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 02:45:09 PDT
Received: from apple.com by RELAY.CS.NET id aa04813; 19 Sep 90 5:45 EDT
Received: by apple.com (5.61/25-eef)
id AA26032; Wed, 19 Sep 90 02:43:29 -0700
for
Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.1)
id <[email protected]>; Wed, 19 Sep 90 00:39 PDT
Received: by tde.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.8)
id <[email protected]>; Wed, 19 Sep 90 00:39 PDT
Message-Id: <[email protected]>
Date: Wed, 19 Sep 90 00:39 PDT
From: Neal Weidenhofer <nw%[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: Linda Stanberry's message of Tue, 18 Sep 90 14:04:37 PDT <[email protected]>
Subject: ANSI C Meeting, September 24-25
I'll be there but I'll be commuting from San Jose.
Neal Weidenhofer
[email protected]
Amdahl Corporation
1250 E. Arques Ave. (M/S 316)
P. O. Box 3470
Sunnyvale, CA 94088-3470
(408)737-5007
19-Sep-90 08:09:07-PDT,2027;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 08:09:03 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA05169; Wed, 19 Sep 90 09:55:32 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA16298; Wed, 19 Sep 90 09:25:24 -0500
Date: Wed, 19 Sep 90 09:25:24 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA16102; Wed, 19 Sep 90 09:11:43 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA10834; Wed, 19 Sep 90 08:15:28 -0400
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 02:45:09 PDT
Received: from apple.com by RELAY.CS.NET id aa04813; 19 Sep 90 5:45 EDT
Received: by apple.com (5.61/25-eef)
id AA26032; Wed, 19 Sep 90 02:43:29 -0700
for
Received: by amdahl.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.1)
id <[email protected]>; Wed, 19 Sep 90 00:39 PDT
Received: by tde.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.8)
id <[email protected]>; Wed, 19 Sep 90 00:39 PDT
Message-Id: <[email protected]>
Date: Wed, 19 Sep 90 00:39 PDT
From: Neal Weidenhofer <[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: Linda Stanberry's message of Tue, 18 Sep 90 14:04:37 PDT <[email protected]>
Subject: ANSI C Meeting, September 24-25
I'll be there but I'll be commuting from San Jose.
Neal Weidenhofer
[email protected]
Amdahl Corporation
1250 E. Arques Ave. (M/S 316)
P. O. Box 3470
Sunnyvale, CA 94088-3470
(408)737-5007
20-Sep-90 02:49:56-PDT,3736;000000000000
Date: Thu, 20 Sep 90 02:45:34 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 19-Sep-90 13:59:16
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 13:58:59 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA26777; Wed, 19 Sep 90 14:24:51 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02906; Wed, 19 Sep 90 14:22:04 EDT
Date: Wed, 19 Sep 90 14:22:04 EDT
From: [email protected] (0000-Admin(0000))
Message-Id: <[email protected]>
To: [email protected]
Subject: 90-067
INFORMATION PROCESSING SYSTEMS Doc No: X3J11/90-067
American National Standards Committee Date: 15 Sep 90
Operating under the procedures of the Project: 381-D
American National Standards Institute Ref Doc:
Reply to: Thomas Plum
Issues re NIST Test Suite
The Procurement at NIST for a C test suite is still in progress,
as far as I know. As of now, Plum Hall Inc has withdrawn its
proposal for several reasons, and requested that the Solicitation
be withdrawn and revised.
Many of the issues are business reasons relating to high start-up
costs with no compensation. These business issues are of vital
interest to Plum Hall Inc, and to any future marketplace for test
suites, but they are not directly relevant to X3J11. In a nut-
shell, the NIST award may go to whomever is willing to provide a
year's free service to the NIST. I have copies of our detailed
statement, and will supply them upon request.
However, some issues are directly relevant to X3J11, and to the
future of the control of the C language. The NIST procurement
did not specify that the technically-best test suite would be
selected, and to the best of my knowledge no C experts have been
consulted in assessing the technical quality of the suites.
(Actually, a last-minute amendment grouped all the mandatory
business requirements under the guise of "technical", so that it
appears that 80% of the evaluation is "technical".) In my obvi-
ously very-biased opinion, X3J11 has an interest in seeing that
the NIST test suite for C is of proper technical quality.
A second issue is the way the NIST is interpreting its mandate.
The FIPS (Federal Information Processing Standard) is the US
Government's procurement standard, and the Solicitation specifies
that this may diverge from ANSI or ISO standards at any point in
the future, under procedures subject to the sole control of NIST.
After such divergence, the NIST suite would validate FIPS C only.
I believe the mandate should be to validate nationally or inter-
nationally recognized standards, i.e. ANSI or ISO, with the
best-quality test method, subject to one international control
committee not controlled by one single organization.
These issues need to be examined by the industry and the users.
Many alternative scenarios are possible, but one very real possi-
bility is that the situation will drift into one in which one
agency of the US Government effectively controls the evolution of
the de-facto standards for C.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
-------
20-Sep-90 02:59:37-PDT,4256;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Thu, 20 Sep 90 02:59:29 PDT
Received: from relay2.cs.net by RELAY.CS.NET id aa10892; 20 Sep 90 5:59 EDT
Date: Thu, 20 Sep 90 5:54:19 EDT
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Failed mail (msg.ab09980)
To: @RELAY.CS.NET:[email protected]
Your message could not be delivered to
'[email protected] (host: tektronix.tek.com) (queue: tektronix)' for the following
reason: ' <[email protected]>... User unknown'
Your message follows:
Received: from relay.cs.net by RELAY.CS.NET id ab09980; 20 Sep 90 5:42 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa10080; 20 Sep 90 5:44 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 13:58:59 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA26777; Wed, 19 Sep 90 14:24:51 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02906; Wed, 19 Sep 90 14:22:04 EDT
Date: Wed, 19 Sep 90 14:22:04 EDT
From: "0000-Admin(0000" <[email protected]>
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <[email protected]>
To: [email protected]
Subject: 90-067
INFORMATION PROCESSING SYSTEMS Doc No: X3J11/90-067
American National Standards Committee Date: 15 Sep 90
Operating under the procedures of the Project: 381-D
American National Standards Institute Ref Doc:
Reply to: Thomas Plum
Issues re NIST Test Suite
The Procurement at NIST for a C test suite is still in progress,
as far as I know. As of now, Plum Hall Inc has withdrawn its
proposal for several reasons, and requested that the Solicitation
be withdrawn and revised.
Many of the issues are business reasons relating to high start-up
costs with no compensation. These business issues are of vital
interest to Plum Hall Inc, and to any future marketplace for test
suites, but they are not directly relevant to X3J11. In a nut-
shell, the NIST award may go to whomever is willing to provide a
year's free service to the NIST. I have copies of our detailed
statement, and will supply them upon request.
However, some issues are directly relevant to X3J11, and to the
future of the control of the C language. The NIST procurement
did not specify that the technically-best test suite would be
selected, and to the best of my knowledge no C experts have been
consulted in assessing the technical quality of the suites.
(Actually, a last-minute amendment grouped all the mandatory
business requirements under the guise of "technical", so that it
appears that 80% of the evaluation is "technical".) In my obvi-
ously very-biased opinion, X3J11 has an interest in seeing that
the NIST test suite for C is of proper technical quality.
A second issue is the way the NIST is interpreting its mandate.
The FIPS (Federal Information Processing Standard) is the US
Government's procurement standard, and the Solicitation specifies
that this may diverge from ANSI or ISO standards at any point in
the future, under procedures subject to the sole control of NIST.
After such divergence, the NIST suite would validate FIPS C only.
I believe the mandate should be to validate nationally or inter-
nationally recognized standards, i.e. ANSI or ISO, with the
best-quality test method, subject to one international control
committee not controlled by one single organization.
These issues need to be examined by the industry and the users.
Many alternative scenarios are possible, but one very real possi-
bility is that the situation will drift into one in which one
agency of the US Government effectively controls the evolution of
the de-facto standards for C.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
21-Sep-90 10:22:05-PDT,4304;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 21 Sep 90 10:21:51 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA16061; Fri, 21 Sep 90 13:21:43 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA04959; Fri, 21 Sep 90 11:51:02 -0500
Date: Fri, 21 Sep 90 11:51:02 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA02460; Fri, 21 Sep 90 10:37:49 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA08883; Fri, 21 Sep 90 09:35:27 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 19 Sep 90 13:58:59 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA26777; Wed, 19 Sep 90 14:24:51 -0400
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02906; Wed, 19 Sep 90 14:22:04 EDT
Date: Wed, 19 Sep 90 14:22:04 EDT
From: uunet!plumhall!root (0000-Admin(0000))
Message-Id: <[email protected]>
To: [email protected]
Subject: 90-067
INFORMATION PROCESSING SYSTEMS Doc No: X3J11/90-067
American National Standards Committee Date: 15 Sep 90
Operating under the procedures of the Project: 381-D
American National Standards Institute Ref Doc:
Reply to: Thomas Plum
Issues re NIST Test Suite
The Procurement at NIST for a C test suite is still in progress,
as far as I know. As of now, Plum Hall Inc has withdrawn its
proposal for several reasons, and requested that the Solicitation
be withdrawn and revised.
Many of the issues are business reasons relating to high start-up
costs with no compensation. These business issues are of vital
interest to Plum Hall Inc, and to any future marketplace for test
suites, but they are not directly relevant to X3J11. In a nut-
shell, the NIST award may go to whomever is willing to provide a
year's free service to the NIST. I have copies of our detailed
statement, and will supply them upon request.
However, some issues are directly relevant to X3J11, and to the
future of the control of the C language. The NIST procurement
did not specify that the technically-best test suite would be
selected, and to the best of my knowledge no C experts have been
consulted in assessing the technical quality of the suites.
(Actually, a last-minute amendment grouped all the mandatory
business requirements under the guise of "technical", so that it
appears that 80% of the evaluation is "technical".) In my obvi-
ously very-biased opinion, X3J11 has an interest in seeing that
the NIST test suite for C is of proper technical quality.
A second issue is the way the NIST is interpreting its mandate.
The FIPS (Federal Information Processing Standard) is the US
Government's procurement standard, and the Solicitation specifies
that this may diverge from ANSI or ISO standards at any point in
the future, under procedures subject to the sole control of NIST.
After such divergence, the NIST suite would validate FIPS C only.
I believe the mandate should be to validate nationally or inter-
nationally recognized standards, i.e. ANSI or ISO, with the
best-quality test method, subject to one international control
committee not controlled by one single organization.
These issues need to be examined by the industry and the users.
Many alternative scenarios are possible, but one very real possi-
bility is that the situation will drift into one in which one
agency of the US Government effectively controls the evolution of
the de-facto standards for C.
Thomas Plum Plum Hall Inc, 1 Spruce Avenue, Cardiff NJ 08232 USA
609-927-3770 FAX 609-653-1903 [email protected]
NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
30-Sep-90 16:30:42-PDT,2783;000000000000
Date: Sun, 30 Sep 90 16:29:56 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 30-Sep-90 16:14:31
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 30 Sep 90 16:14:27 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02104; Sun, 30 Sep 90 19:14:51 -0400
Date: Sun, 30 Sep 90 23:16:58 EST
From: [email protected] (Rex Jaeschke)
Subject: NIST selects validation suite
Message-Id: <9009302316.0.UUL1.3#[email protected]>
To: [email protected], [email protected],
[email protected], [email protected]
FYI, I just received the following e-mail from Perennial, one of the
contenders for the NIST validation suite selection.
As far as I can tell there were only 3 final contenders: Perennial,
Plum Hall, and HCR/ACE. According to reliable sources, Plum Hall
withdrew their bid in the last several weeks citing major problems
with the selection criteria and other issues. Around the same time,
HCR/ACE aparently withdrew their bid since they thought the
competition was biased toward Plum Hall. So, that left only Perennial.
I have a feeling that the dust has not yet settled and there will
likely be one or more appeals. I'll keep you informed as I find out
more information.
If you were not already aware, the European C Validation service (UK,
France, and Italy) selected Plum Hall for their suite, more than a
year ago.
------------------------------------------
Date: Sat, 29 Sep 90 15:02:45 PDT
From: uunet!peren!beh (Barry E. Hedquist)
To: aussie!rex
Subject: ANSI C Validation Suite
Rex,
Just a note to let you know that Perennial has been selected
by the National Inst of Standards and Technology (NIST) has
selected Perennial to be the exclusive supplier of the
validation test suite for ANSI C - soon to be adopted as
a Federal Information Processing (FIP) Standard.
More information to follow.
Barry Hedquist
Perennial
------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
30-Sep-90 16:31:41-PDT,3670;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Sun, 30 Sep 90 16:31:37 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa29594; 30 Sep 90 19:32 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA25514; Sun, 30 Sep 90 16:32:25 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AA19211; Sun, 30 Sep 90 16:32:26 PDT
Date: Sun, 30 Sep 90 16:32:26 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB19202; Sun, 30 Sep 90 16:32:26 PDT
Received: from relay.cs.net by RELAY.CS.NET id ab05621; 30 Sep 90 19:24 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa29559; 30 Sep 90 19:29 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 30 Sep 90 16:14:27 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02104; Sun, 30 Sep 90 19:14:51 -0400
Date: Sun, 30 Sep 90 23:16:58 EST
From: Rex Jaeschke <[email protected]>
Subject: NIST selects validation suite
Message-Id: <9009302316.0.UUL1.3#[email protected]>
To: [email protected], [email protected],
[email protected], [email protected]
FYI, I just received the following e-mail from Perennial, one of the
contenders for the NIST validation suite selection.
As far as I can tell there were only 3 final contenders: Perennial,
Plum Hall, and HCR/ACE. According to reliable sources, Plum Hall
withdrew their bid in the last several weeks citing major problems
with the selection criteria and other issues. Around the same time,
HCR/ACE aparently withdrew their bid since they thought the
competition was biased toward Plum Hall. So, that left only Perennial.
I have a feeling that the dust has not yet settled and there will
likely be one or more appeals. I'll keep you informed as I find out
more information.
If you were not already aware, the European C Validation service (UK,
France, and Italy) selected Plum Hall for their suite, more than a
year ago.
------------------------------------------
Date: Sat, 29 Sep 90 15:02:45 PDT
From: uunet!peren!beh (Barry E. Hedquist)
To: aussie!rex
Subject: ANSI C Validation Suite
Rex,
Just a note to let you know that Perennial has been selected
by the National Inst of Standards and Technology (NIST) has
selected Perennial to be the exclusive supplier of the
validation test suite for ANSI C - soon to be adopted as
a Federal Information Processing (FIP) Standard.
More information to follow.
Barry Hedquist
Perennial
------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
1-Oct-90 05:42:57-PDT,3339;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 1 Oct 90 05:42:54 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA25776; Mon, 1 Oct 90 08:43:20 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AB27999; Mon, 1 Oct 90 07:02:05 -0500
Date: Mon, 1 Oct 90 07:02:05 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA26115; Mon, 1 Oct 90 06:10:36 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA05912; Sun, 30 Sep 90 19:28:55 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 30 Sep 90 16:14:27 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02104; Sun, 30 Sep 90 19:14:51 -0400
Date: Sun, 30 Sep 90 23:16:58 EST
From: uunet!aussie!rex (Rex Jaeschke)
Subject: NIST selects validation suite
Message-Id: <9009302316.0.UUL1.3#[email protected]>
To: [email protected], aussie!plumhall!plum, aussie!attcan!utzoo!hcr!paul,
[email protected]
FYI, I just received the following e-mail from Perennial, one of the
contenders for the NIST validation suite selection.
As far as I can tell there were only 3 final contenders: Perennial,
Plum Hall, and HCR/ACE. According to reliable sources, Plum Hall
withdrew their bid in the last several weeks citing major problems
with the selection criteria and other issues. Around the same time,
HCR/ACE aparently withdrew their bid since they thought the
competition was biased toward Plum Hall. So, that left only Perennial.
I have a feeling that the dust has not yet settled and there will
likely be one or more appeals. I'll keep you informed as I find out
more information.
If you were not already aware, the European C Validation service (UK,
France, and Italy) selected Plum Hall for their suite, more than a
year ago.
------------------------------------------
Date: Sat, 29 Sep 90 15:02:45 PDT
From: uunet!peren!beh (Barry E. Hedquist)
To: aussie!rex
Subject: ANSI C Validation Suite
Rex,
Just a note to let you know that Perennial has been selected
by the National Inst of Standards and Technology (NIST) has
selected Perennial to be the exclusive supplier of the
validation test suite for ANSI C - soon to be adopted as
a Federal Information Processing (FIP) Standard.
More information to follow.
Barry Hedquist
Perennial
------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
2-Oct-90 00:02:27-PDT,3483;000000000000
Return-Path: <[email protected]>
Received: from ames.arc.nasa.gov by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 00:02:20 PDT
Received: by ames.arc.nasa.gov (5.64/1.2); Mon, 1 Oct 90 23:57:28 -0700
Received: by AMD.COM (4.1/SMI-4.1-AMD-90.4.28)
id AA25085; Mon, 1 Oct 90 23:46:03 PDT
Date: Mon, 1 Oct 90 23:46:03 PDT
From: [email protected]
Message-Id: <[email protected]>
Subject: Warning From uucp
Apparently-To: [email protected]
To: [email protected]
We have been unable to contact machine 'sun0' since you queued your job.
mail sun0!fay (Date 09/30)
Attempts will continue for a few more days.
Sincerely,
amdcad!uucp
#############################################
##### Data File: ############################
From NIC.DDN.MIL!X3J11-RELAY Sun Sep 30 16:37:49 1990 remote from amdcad
Received: from NIC.DDN.MIL by AMD.COM (4.1/SMI-4.1-AMD-90.4.28)
id AA15569; Sun, 30 Sep 90 16:37:49 PDT
Received: by decwrl.dec.com; id AA29938; Sun, 30 Sep 90 16:30:00 -0700
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 30 Sep 90 16:14:27 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02104; Sun, 30 Sep 90 19:14:51 -0400
Date: Sun, 30 Sep 90 23:16:58 EST
From: amdcad!decwrl!uunet.UU.NET!aussie!rex (Rex Jaeschke)
Subject: NIST selects validation suite
Message-Id: <9009302316.0.UUL1.3#[email protected]>
To: NIC.DDN.MIL!X3J11, uunet.UU.NET!aussie!plumhall!plum,
uunet.UU.NET!aussie!attcan!utzoo!hcr!paul, ace.nl!john
FYI, I just received the following e-mail from Perennial, one of the
contenders for the NIST validation suite selection.
As far as I can tell there were only 3 final contenders: Perennial,
Plum Hall, and HCR/ACE. According to reliable sources, Plum Hall
withdrew their bid in the last several weeks citing major problems
with the selection criteria and other issues. Around the same time,
HCR/ACE aparently withdrew their bid since they thought the
competition was biased toward Plum Hall. So, that left only Perennial.
I have a feeling that the dust has not yet settled and there will
likely be one or more appeals. I'll keep you informed as I find out
more information.
If you were not already aware, the European C Validation service (UK,
France, and Italy) selected Plum Hall for their suite, more than a
year ago.
------------------------------------------
Date: Sat, 29 Sep 90 15:02:45 PDT
From: uunet!peren!beh (Barry E. Hedquist)
To: aussie!rex
Subject: ANSI C Validation Suite
Rex,
Just a note to let you know that Perennial has been selected
by the National Inst of Standards and Technology (NIST) has
selected Perennial to be the exclusive supplier of the
validation test suite for ANSI C - soon to be adopted as
a Federal Information Processing (FIP) Standard.
More information to follow.
Barry Hedquist
Perennial
------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
2-Oct-90 02:23:10-PDT,1943;000000000000
Date: Tue, 2 Oct 90 02:22:08 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 2-Oct-90 02:03:44
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 02:03:39 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA07012; Tue, 2 Oct 90 05:03:49 -0400
Date: Mon, 1 Oct 90 17:57:04 EST
From: [email protected] (Rex Jaeschke)
Subject: RFI #18 from Japan
Message-Id: <9010011757.0.UUL1.3#[email protected]>
To: [email protected]
Cc: [email protected]
On request from Japanese C representatives I registered a a formal
Request for Interpretation (number 18). I also took copies to last
week's X3J11 meeting. Unfortunately, the committee did NOT get to
review and process all submitted requests and, unfortunately, #18
was one of those left unresolved. There will be no formal review of
it until the next meeting in March of 1991. The only way to get
informal input before then is to directly ask members of X3J11.
If you have an interest in multibyte character issues look for #18 in
your next mailing (if you didn't get a copy last week) and send me any
input you can. I'll forward it on to the Japanese.
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
2-Oct-90 02:27:13-PDT,2821;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 02:27:09 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa00850; 2 Oct 90 5:27 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA13839; Tue, 2 Oct 90 02:27:40 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AA02667; Tue, 2 Oct 90 02:27:39 PDT
Date: Tue, 2 Oct 90 02:27:39 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB02665; Tue, 2 Oct 90 02:27:39 PDT
Received: from relay.cs.net by RELAY.CS.NET id ab25930; 2 Oct 90 5:16 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa00803; 2 Oct 90 5:21 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 02:03:39 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA07012; Tue, 2 Oct 90 05:03:49 -0400
Date: Mon, 1 Oct 90 17:57:04 EST
From: Rex Jaeschke <[email protected]>
Subject: RFI #18 from Japan
Message-Id: <9010011757.0.UUL1.3#[email protected]>
To: [email protected]
Cc: [email protected]
On request from Japanese C representatives I registered a a formal
Request for Interpretation (number 18). I also took copies to last
week's X3J11 meeting. Unfortunately, the committee did NOT get to
review and process all submitted requests and, unfortunately, #18
was one of those left unresolved. There will be no formal review of
it until the next meeting in March of 1991. The only way to get
informal input before then is to directly ask members of X3J11.
If you have an interest in multibyte character issues look for #18 in
your next mailing (if you didn't get a copy last week) and send me any
input you can. I'll forward it on to the Japanese.
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
2-Oct-90 04:01:17-PDT,2526;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 04:01:13 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12691; Tue, 2 Oct 90 07:01:40 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA18813; Tue, 2 Oct 90 06:00:28 -0500
Date: Tue, 2 Oct 90 06:00:28 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA17324; Tue, 2 Oct 90 04:34:05 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA15965; Tue, 2 Oct 90 05:29:18 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Tue, 2 Oct 90 02:03:39 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA07012; Tue, 2 Oct 90 05:03:49 -0400
Date: Mon, 1 Oct 90 17:57:04 EST
From: uunet!aussie!rex (Rex Jaeschke)
Subject: RFI #18 from Japan
Message-Id: <9010011757.0.UUL1.3#[email protected]>
To: [email protected]
Cc: [email protected]
On request from Japanese C representatives I registered a a formal
Request for Interpretation (number 18). I also took copies to last
week's X3J11 meeting. Unfortunately, the committee did NOT get to
review and process all submitted requests and, unfortunately, #18
was one of those left unresolved. There will be no formal review of
it until the next meeting in March of 1991. The only way to get
informal input before then is to directly ask members of X3J11.
If you have an interest in multibyte character issues look for #18 in
your next mailing (if you didn't get a copy last week) and send me any
input you can. I'll forward it on to the Japanese.
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
10-Oct-90 22:21:15-PDT,4703;000000000000
Date: Wed, 10 Oct 90 22:19:58 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 10-Oct-90 09:40:24
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 09:40:17 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA14457; Wed, 10 Oct 90 12:40:15 -0400
Date: Wed, 10 Oct 90 12:00:22 EST
From: [email protected] (Rex Jaeschke)
Subject: Re: report delivered to SC22 CHAR WG
Message-Id: <9010101200.1.UUL1.3#[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: Your message of Wed, 10 Oct 90 15:50:53 +0100
> From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
> To: [email protected]
> Subject: report delivered to SC22 CHAR WG
>
> Title: WG14 report to CHAR WG
>
> Source: Danish WG14 member, Keld Simonsen
>
> Date: 1990-10-07
>
> This report covers the work of SC22/WG14 (Programming language C)
> with respect to character sets, especially the requirements of the
> papers SC22 N623R.
>
> WG14 has just finished the IS 9899, which has several provisions for
> handling of international character sets. WG14 has also been charged
> by the SC22 Berlin plenary 1989 to produce a normative addendum to
> the IS 9899-1990, which amongst other things shall solve "character
> set handling issues".
>
> With respect to the requirements in N623R, the following comments can
> be made of the status of the work of WG14:
>
> 1. Extented character use in identifiers.
> This is not supported in the IS, but there is a proposal to solve it
> in the forthcoming addendum, based on the "alpha" class of the
> current "locale".
>
> 2. Internationalization
> The IS 9899-1990 provides standard functions to handle:
> character classification alpha, digit, hex digit,
> control, graphic, space etc
> lower and upper case, and conversion
> collating sequences
> date and time formatting
> day and month names selectable
> numeric formatting
> currency formatting
> language sensitive collating
>
> 3. Use of large character sets.
> IS 9899 has limited support for "multibyte characters". There is a
> proposal to include full support for multibyte characters in the
> addendum.
>
> 4. Support for national versions of ISO 646.
> The IS 9899 has specified an alternate representation for characters
> not in the invariant part of ISO 646, the so-called "trigraph"
> representation. This consists of two question marks and another
> character to represent the not-well-defined ISO 646 IRV character.
> The "trigraph" notation is not well-liked, and another alternate
> representation is proposed for the addendum, based on digraphs and
> new keywords.
> 5. Encoding of files
> Programming Language C has currently no way of specifying which
> character set a file is encoded in, and no work is planned. WG14
> would like to seek guidance on how this could be done.
>
> 6. Control characters in source files.
> C has no special rules for this.
Re your trigraph comments:
I think it must be stated that ``Trigraphs are already part of the
ANSI C standard on which IS 9899 is based. They were added to
provide a mechanical way of converting conforming programs into and
out of ISO 646 environments, and in that respect, do their intended
job.''
To say that `The trigraph notation is not well-liked'' is misleading
in this context. Certainly, there are few people who think trigraphs
are elegant. And most people think they are quite unnecessary. It
is generally acknowledged, however, that they do the job they were
designed for. It should be made clear that ONLY ONE WG14 member
dislikes them enough to seriously propose an alternative (and extra)
representation. Your report should in no way imply that an alternate
representation is the desire of WG14 as a whole.
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
10-Oct-90 22:29:00-PDT,5587;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 22:28:55 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa14650; 11 Oct 90 1:28 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA02572; Wed, 10 Oct 90 22:29:12 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC21648; Wed, 10 Oct 90 22:28:42 PDT
Date: Wed, 10 Oct 90 22:28:42 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB21648; Wed, 10 Oct 90 22:28:42 PDT
Received: from relay.cs.net by RELAY.CS.NET id aa02884; 11 Oct 90 1:11 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa14522; 11 Oct 90 1:19 EDT
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 09:40:17 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA14457; Wed, 10 Oct 90 12:40:15 -0400
Date: Wed, 10 Oct 90 12:00:22 EST
From: Rex Jaeschke <[email protected]>
Subject: Re: report delivered to SC22 CHAR WG
Message-Id: <9010101200.1.UUL1.3#[email protected]>
To: [email protected]
Cc: [email protected]
In-Reply-To: Your message of Wed, 10 Oct 90 15:50:53 +0100
> From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
> To: [email protected]
> Subject: report delivered to SC22 CHAR WG
>
> Title: WG14 report to CHAR WG
>
> Source: Danish WG14 member, Keld Simonsen
>
> Date: 1990-10-07
>
> This report covers the work of SC22/WG14 (Programming language C)
> with respect to character sets, especially the requirements of the
> papers SC22 N623R.
>
> WG14 has just finished the IS 9899, which has several provisions for
> handling of international character sets. WG14 has also been charged
> by the SC22 Berlin plenary 1989 to produce a normative addendum to
> the IS 9899-1990, which amongst other things shall solve "character
> set handling issues".
>
> With respect to the requirements in N623R, the following comments can
> be made of the status of the work of WG14:
>
> 1. Extented character use in identifiers.
> This is not supported in the IS, but there is a proposal to solve it
> in the forthcoming addendum, based on the "alpha" class of the
> current "locale".
>
> 2. Internationalization
> The IS 9899-1990 provides standard functions to handle:
> character classification alpha, digit, hex digit,
> control, graphic, space etc
> lower and upper case, and conversion
> collating sequences
> date and time formatting
> day and month names selectable
> numeric formatting
> currency formatting
> language sensitive collating
>
> 3. Use of large character sets.
> IS 9899 has limited support for "multibyte characters". There is a
> proposal to include full support for multibyte characters in the
> addendum.
>
> 4. Support for national versions of ISO 646.
> The IS 9899 has specified an alternate representation for characters
> not in the invariant part of ISO 646, the so-called "trigraph"
> representation. This consists of two question marks and another
> character to represent the not-well-defined ISO 646 IRV character.
> The "trigraph" notation is not well-liked, and another alternate
> representation is proposed for the addendum, based on digraphs and
> new keywords.
> 5. Encoding of files
> Programming Language C has currently no way of specifying which
> character set a file is encoded in, and no work is planned. WG14
> would like to seek guidance on how this could be done.
>
> 6. Control characters in source files.
> C has no special rules for this.
Re your trigraph comments:
I think it must be stated that ``Trigraphs are already part of the
ANSI C standard on which IS 9899 is based. They were added to
provide a mechanical way of converting conforming programs into and
out of ISO 646 environments, and in that respect, do their intended
job.''
To say that `The trigraph notation is not well-liked'' is misleading
in this context. Certainly, there are few people who think trigraphs
are elegant. And most people think they are quite unnecessary. It
is generally acknowledged, however, that they do the job they were
designed for. It should be made clear that ONLY ONE WG14 member
dislikes them enough to seriously propose an alternative (and extra)
representation. Your report should in no way imply that an alternate
representation is the desire of WG14 as a whole.
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
11-Oct-90 01:08:13-PDT,5277;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Thu, 11 Oct 90 01:07:45 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA14462; Thu, 11 Oct 90 04:07:01 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA12195; Thu, 11 Oct 90 01:31:26 -0500
Date: Thu, 11 Oct 90 01:31:26 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA10279; Thu, 11 Oct 90 00:29:07 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA24837; Thu, 11 Oct 90 01:19:16 -0400
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 10 Oct 90 09:40:17 PDT
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA14457; Wed, 10 Oct 90 12:40:15 -0400
Date: Wed, 10 Oct 90 12:00:22 EST
From: uunet!aussie!rex (Rex Jaeschke)
Subject: Re: report delivered to SC22 CHAR WG
Message-Id: <9010101200.1.UUL1.3#[email protected]>
To: aussie!mcsun!dkuug.dk!keld
Cc: [email protected]
In-Reply-To: Your message of Wed, 10 Oct 90 15:50:53 +0100
> From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
> To: [email protected]
> Subject: report delivered to SC22 CHAR WG
>
> Title: WG14 report to CHAR WG
>
> Source: Danish WG14 member, Keld Simonsen
>
> Date: 1990-10-07
>
> This report covers the work of SC22/WG14 (Programming language C)
> with respect to character sets, especially the requirements of the
> papers SC22 N623R.
>
> WG14 has just finished the IS 9899, which has several provisions for
> handling of international character sets. WG14 has also been charged
> by the SC22 Berlin plenary 1989 to produce a normative addendum to
> the IS 9899-1990, which amongst other things shall solve "character
> set handling issues".
>
> With respect to the requirements in N623R, the following comments can
> be made of the status of the work of WG14:
>
> 1. Extented character use in identifiers.
> This is not supported in the IS, but there is a proposal to solve it
> in the forthcoming addendum, based on the "alpha" class of the
> current "locale".
>
> 2. Internationalization
> The IS 9899-1990 provides standard functions to handle:
> character classification alpha, digit, hex digit,
> control, graphic, space etc
> lower and upper case, and conversion
> collating sequences
> date and time formatting
> day and month names selectable
> numeric formatting
> currency formatting
> language sensitive collating
>
> 3. Use of large character sets.
> IS 9899 has limited support for "multibyte characters". There is a
> proposal to include full support for multibyte characters in the
> addendum.
>
> 4. Support for national versions of ISO 646.
> The IS 9899 has specified an alternate representation for characters
> not in the invariant part of ISO 646, the so-called "trigraph"
> representation. This consists of two question marks and another
> character to represent the not-well-defined ISO 646 IRV character.
> The "trigraph" notation is not well-liked, and another alternate
> representation is proposed for the addendum, based on digraphs and
> new keywords.
> 5. Encoding of files
> Programming Language C has currently no way of specifying which
> character set a file is encoded in, and no work is planned. WG14
> would like to seek guidance on how this could be done.
>
> 6. Control characters in source files.
> C has no special rules for this.
Re your trigraph comments:
I think it must be stated that ``Trigraphs are already part of the
ANSI C standard on which IS 9899 is based. They were added to
provide a mechanical way of converting conforming programs into and
out of ISO 646 environments, and in that respect, do their intended
job.''
To say that `The trigraph notation is not well-liked'' is misleading
in this context. Certainly, there are few people who think trigraphs
are elegant. And most people think they are quite unnecessary. It
is generally acknowledged, however, that they do the job they were
designed for. It should be made clear that ONLY ONE WG14 member
dislikes them enough to seriously propose an alternative (and extra)
representation. Your report should in no way imply that an alternate
representation is the desire of WG14 as a whole.
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
uunet!aussie!rex | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
13-Oct-90 09:52:21-PDT,1867;000000000000
Return-Path: <Mailer-Daemon@home>
Received: from home ([128.103.250.1]) by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 09:51:33 PDT
Received: from harvard.harvard.edu ([128.103.1.1]) by home (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0-clp)
id AA00228; Sat, 13 Oct 90 12:50:12 EDT
Date: Sat, 13 Oct 90 12:50:12 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <9010131650.AA00228@home>
To: <[email protected]>
----- Transcript of session follows -----
Connected to SABER.SABER.COM:
>>> HELO home
<<< 553 home host name configuration error
554 <[email protected]>... Service unavailable
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: from harvard.harvard.edu ([128.103.1.1]) by home (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0-clp)
id AA00226; Sat, 13 Oct 90 12:50:12 EDT
Errors-To: <[email protected]>
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA09160; Sat, 13 Oct 90 12:45:15 EDT
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 09:33:43 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA16843; Sat, 13 Oct 90 17:30:08 +0100
Date: Sat, 13 Oct 90 17:30:08 +0100
From: Keld J|rn Simonsen <[email protected]>
Message-Id: <[email protected]>
To: rex%[email protected]
Subject: Re: report delivered to SC22 CHAR WG
Cc: [email protected]
X-Charset: ASCII
X-Char-Esc: 29
Hi Rex!
Thanks for your comments to my report.
I think your statement on the workings of trigraphs is included
in the report, just with other words. Nobody is saying that
trigraphs does not work.
On the alternate trigraph proposal: This was just described
as a proposal, and no opinion of WG14 was attached to it,
as support from WG14 has been varying...
Regards
Keld
13-Oct-90 09:54:34-PDT,2042;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 09:54:30 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa13665; 13 Oct 90 12:54 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA29592; Sat, 13 Oct 90 09:54:57 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AA07637; Sat, 13 Oct 90 09:54:53 PDT
Date: Sat, 13 Oct 90 09:54:53 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB07603; Sat, 13 Oct 90 09:54:53 PDT
Received: from relay.cs.net by RELAY.CS.NET id ab10839; 13 Oct 90 12:43 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa13629; 13 Oct 90 12:52 EDT
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 09:33:43 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA16843; Sat, 13 Oct 90 17:30:08 +0100
Date: Sat, 13 Oct 90 17:30:08 +0100
From: Keld J|rn Simonsen <[email protected]>
Message-Id: <[email protected]>
To: rex%[email protected]
Subject: Re: report delivered to SC22 CHAR WG
Cc: [email protected]
X-Charset: ASCII
X-Char-Esc: 29
Hi Rex!
Thanks for your comments to my report.
I think your statement on the workings of trigraphs is included
in the report, just with other words. Nobody is saying that
trigraphs does not work.
On the alternate trigraph proposal: This was just described
as a proposal, and no opinion of WG14 was attached to it,
as support from WG14 has been varying...
Regards
Keld
13-Oct-90 09:58:03-PDT,1155;000000000000
Date: Sat, 13 Oct 90 09:53:25 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Oct-90 09:34:19
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 09:33:43 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA16843; Sat, 13 Oct 90 17:30:08 +0100
Date: Sat, 13 Oct 90 17:30:08 +0100
From: Keld J|rn Simonsen <[email protected]>
Message-Id: <[email protected]>
To: rex%[email protected]
Subject: Re: report delivered to SC22 CHAR WG
Cc: [email protected]
X-Charset: ASCII
X-Char-Esc: 29
Hi Rex!
Thanks for your comments to my report.
I think your statement on the workings of trigraphs is included
in the report, just with other words. Nobody is saying that
trigraphs does not work.
On the alternate trigraph proposal: This was just described
as a proposal, and no opinion of WG14 was attached to it,
as support from WG14 has been varying...
Regards
Keld
-------
13-Oct-90 20:36:32-PDT,1580;000000000000
Return-Path: <Mailer-Daemon@home>
Received: from home (clp.harvard.edu) by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 20:35:42 PDT
Received: from harvard.harvard.edu by home (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0-clp)
id AA01079; Sat, 13 Oct 90 23:35:26 EDT
Date: Sat, 13 Oct 90 23:35:26 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <9010140335.AA01079@home>
To: <[email protected]>
----- Transcript of session follows -----
Connected to SABER.SABER.COM:
>>> HELO home
<<< 553 home host name configuration error
554 <[email protected]>... Service unavailable
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by home (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0-clp)
id AA01077; Sat, 13 Oct 90 23:35:26 EDT
Errors-To: <[email protected]>
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA14681; Sat, 13 Oct 90 23:32:06 EDT
Received: from vgr.brl.mil by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 19:56:38 PDT
Date: Sat, 13 Oct 90 22:49:55 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: Keld J|rn Simonsen <[email protected]>
Cc: rex%[email protected], [email protected]
Subject: Re: report delivered to SC22 CHAR WG
Message-Id: <[email protected]>
"Support from WG14" has hardly been varying. The trigraph alternative
proposal was brought up for a vote in WG14 and was defeated. In any
reasonable consensus process that would be the end of the matter.
13-Oct-90 20:45:53-PDT,916;000000000000
Date: Sat, 13 Oct 90 20:42:23 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Oct-90 19:56:43
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from vgr.brl.mil by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 19:56:38 PDT
Date: Sat, 13 Oct 90 22:49:55 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: Keld J|rn Simonsen <[email protected]>
cc: rex%[email protected], [email protected]
Subject: Re: report delivered to SC22 CHAR WG
Message-ID: <[email protected]>
"Support from WG14" has hardly been varying. The trigraph alternative
proposal was brought up for a vote in WG14 and was defeated. In any
reasonable consensus process that would be the end of the matter.
-------
13-Oct-90 20:47:30-PDT,1787;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 20:47:28 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa21479; 13 Oct 90 23:47 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA11371; Sat, 13 Oct 90 20:47:45 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC23448; Sat, 13 Oct 90 20:47:37 PDT
Date: Sat, 13 Oct 90 20:47:37 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB23448; Sat, 13 Oct 90 20:47:37 PDT
Received: from relay.cs.net by RELAY.CS.NET id ab15911; 13 Oct 90 23:32 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa21421; 13 Oct 90 23:41 EDT
Received: from vgr.brl.mil by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 19:56:38 PDT
Date: Sat, 13 Oct 90 22:49:55 EDT
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: Keld J|rn Simonsen <[email protected]>
Cc: rex%[email protected], [email protected]
Subject: Re: report delivered to SC22 CHAR WG
Message-Id: <[email protected]>
"Support from WG14" has hardly been varying. The trigraph alternative
proposal was brought up for a vote in WG14 and was defeated. In any
reasonable consensus process that would be the end of the matter.
13-Oct-90 23:46:42-PDT,1755;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 23:46:40 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA01344; Sun, 14 Oct 90 02:46:52 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA23438; Sat, 13 Oct 90 21:28:14 -0500
Date: Sat, 13 Oct 90 21:28:14 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA21106; Sat, 13 Oct 90 20:45:36 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA11822; Sat, 13 Oct 90 21:31:29 -0400
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 09:33:43 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA16843; Sat, 13 Oct 90 17:30:08 +0100
Date: Sat, 13 Oct 90 17:30:08 +0100
From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
Message-Id: <[email protected]>
To: rex%[email protected]
Subject: Re: report delivered to SC22 CHAR WG
Cc: [email protected]
X-Charset: ASCII
X-Char-Esc: 29
Hi Rex!
Thanks for your comments to my report.
I think your statement on the workings of trigraphs is included
in the report, just with other words. Nobody is saying that
trigraphs does not work.
On the alternate trigraph proposal: This was just described
as a proposal, and no opinion of WG14 was attached to it,
as support from WG14 has been varying...
Regards
Keld
14-Oct-90 00:51:22-PDT,1500;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 00:51:18 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23683; Sun, 14 Oct 90 03:51:30 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA00280; Sun, 14 Oct 90 02:28:11 -0500
Date: Sun, 14 Oct 90 02:28:11 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA29311; Sun, 14 Oct 90 01:58:03 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA13591; Sat, 13 Oct 90 23:40:54 -0400
Received: from vgr.brl.mil by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 19:56:38 PDT
Date: Sat, 13 Oct 90 22:49:55 EDT
From: Doug Gwyn (VLD/VMB) <uunet!BRL.MIL!gwyn>
To: Keld J|rn Simonsen <[email protected]>
Cc: rex%[email protected], [email protected]
Subject: Re: report delivered to SC22 CHAR WG
Message-Id: <[email protected]>
"Support from WG14" has hardly been varying. The trigraph alternative
proposal was brought up for a vote in WG14 and was defeated. In any
reasonable consensus process that would be the end of the matter.
14-Oct-90 07:14:46-PDT,1827;000000000000
Return-Path: <Mailer-Daemon@home>
Received: from home (clp.harvard.edu) by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 07:14:00 PDT
Received: from harvard.harvard.edu by home (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0-clp)
id AA01381; Sun, 14 Oct 90 10:13:51 EDT
Date: Sun, 14 Oct 90 10:13:51 EDT
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <9010141413.AA01381@home>
To: <[email protected]>
----- Transcript of session follows -----
Connected to SABER.SABER.COM:
>>> HELO home
<<< 553 home host name configuration error
554 <[email protected]>... Service unavailable
----- Unsent message follows -----
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by home (NeXT-1.0 (From Sendmail 5.52)/NeXT-1.0-clp)
id AA01379; Sun, 14 Oct 90 10:13:51 EDT
Errors-To: <[email protected]>
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA19777; Sun, 14 Oct 90 10:10:25 EDT
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 06:58:36 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA13576; Sun, 14 Oct 90 14:55:39 +0100
Date: Sun, 14 Oct 90 14:55:39 +0100
From: Keld J|rn Simonsen <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: report delivered to SC22 CHAR WG
Cc: [email protected], rex%[email protected]
X-Charset: ASCII
X-Char-Esc: 29
> "Support from WG14" has hardly been varying. The trigraph alternative
> proposal was brought up for a vote in WG14 and was defeated. In any
> reasonable consensus process that would be the end of the matter.
The support from WG14 has been varying: three times it has been put
to a vote for WG14, two times it passed, and once it did not pass.
Keld
14-Oct-90 07:21:43-PDT,1147;000000000000
Date: Sun, 14 Oct 90 07:20:09 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 14-Oct-90 06:58:44
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 06:58:36 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA13576; Sun, 14 Oct 90 14:55:39 +0100
Date: Sun, 14 Oct 90 14:55:39 +0100
From: Keld J|rn Simonsen <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: report delivered to SC22 CHAR WG
Cc: [email protected], rex%[email protected]
X-Charset: ASCII
X-Char-Esc: 29
> "Support from WG14" has hardly been varying. The trigraph alternative
> proposal was brought up for a vote in WG14 and was defeated. In any
> reasonable consensus process that would be the end of the matter.
The support from WG14 has been varying: three times it has been put
to a vote for WG14, two times it passed, and once it did not pass.
Keld
-------
14-Oct-90 07:27:10-PDT,2034;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 07:27:08 PDT
Received: from tektronix.tek.com by RELAY.CS.NET id aa28036; 14 Oct 90 10:27 EDT
Received: by tektronix.TEK.COM (5.51/7.1)
id AA20251; Sun, 14 Oct 90 07:27:28 PDT
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC06592; Sun, 14 Oct 90 07:27:23 PDT
Date: Sun, 14 Oct 90 07:27:23 PDT
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB06592; Sun, 14 Oct 90 07:27:23 PDT
Received: from relay.cs.net by RELAY.CS.NET id aa20236; 14 Oct 90 10:10 EDT
Received: from nic.ddn.mil by RELAY.CS.NET id aa27960; 14 Oct 90 10:19 EDT
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 06:58:36 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA13576; Sun, 14 Oct 90 14:55:39 +0100
Date: Sun, 14 Oct 90 14:55:39 +0100
From: Keld J|rn Simonsen <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: report delivered to SC22 CHAR WG
Cc: [email protected], rex%[email protected]
X-Charset: ASCII
X-Char-Esc: 29
> "Support from WG14" has hardly been varying. The trigraph alternative
> proposal was brought up for a vote in WG14 and was defeated. In any
> reasonable consensus process that would be the end of the matter.
The support from WG14 has been varying: three times it has been put
to a vote for WG14, two times it passed, and once it did not pass.
Keld
14-Oct-90 17:40:52-PDT,1747;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 17:40:50 PDT
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22085; Sun, 14 Oct 90 20:41:01 -0400
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA11329; Sun, 14 Oct 90 19:39:56 -0500
Date: Sun, 14 Oct 90 19:39:56 -0500
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA10836; Sun, 14 Oct 90 19:29:05 -0500
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA16548; Sun, 14 Oct 90 20:17:54 -0400
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 06:58:36 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA13576; Sun, 14 Oct 90 14:55:39 +0100
Date: Sun, 14 Oct 90 14:55:39 +0100
From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
Message-Id: <[email protected]>
To: [email protected]
Subject: Re: report delivered to SC22 CHAR WG
Cc: [email protected], rex%[email protected]
X-Charset: ASCII
X-Char-Esc: 29
> "Support from WG14" has hardly been varying. The trigraph alternative
> proposal was brought up for a vote in WG14 and was defeated. In any
> reasonable consensus process that would be the end of the matter.
The support from WG14 has been varying: three times it has been put
to a vote for WG14, two times it passed, and once it did not pass.
Keld
14-Oct-90 23:46:58-PDT,1852;000000000000
Return-Path: <[email protected]>
Received: from ames.arc.nasa.gov by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 23:46:56 PDT
Received: by ames.arc.nasa.gov (5.64/1.2); Sun, 14 Oct 90 23:47:10 -0700
Received: by AMD.COM (4.1/SMI-4.1-AMD-90.4.28)
id AA20250; Sun, 14 Oct 90 23:46:06 PDT
Date: Sun, 14 Oct 90 23:46:06 PDT
From: [email protected]
Message-Id: <[email protected]>
Subject: Warning From uucp
Apparently-To: [email protected]
To: [email protected]
We have been unable to contact machine 'sun0' since you queued your job.
mail sun0!fay (Date 10/13)
Attempts will continue for a few more days.
Sincerely,
amdcad!uucp
#############################################
##### Data File: ############################
From NIC.DDN.MIL!X3J11-RELAY Sat Oct 13 09:54:58 1990 remote from amdcad
Received: from NIC.DDN.MIL by AMD.COM (4.1/SMI-4.1-AMD-90.4.28)
id AA08701; Sat, 13 Oct 90 09:54:58 PDT
Received: by decwrl.dec.com; id AA26146; Sat, 13 Oct 90 09:52:50 -0700
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 09:33:43 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA16843; Sat, 13 Oct 90 17:30:08 +0100
Date: Sat, 13 Oct 90 17:30:08 +0100
From: Keld J|rn Simonsen <amdcad!dkuug.dk!keld>
Message-Id: <[email protected]>
To: relay.eu.net!rex%aussie
Subject: Re: report delivered to SC22 CHAR WG
Cc: NIC.DDN.MIL!X3J11
X-Charset: ASCII
X-Char-Esc: 29
Hi Rex!
Thanks for your comments to my report.
I think your statement on the workings of trigraphs is included
in the report, just with other words. Nobody is saying that
trigraphs does not work.
On the alternate trigraph proposal: This was just described
as a proposal, and no opinion of WG14 was attached to it,
as support from WG14 has been varying...
Regards
Keld
14-Oct-90 23:47:04-PDT,1597;000000000000
Return-Path: <[email protected]>
Received: from ames.arc.nasa.gov by NIC.DDN.MIL with TCP; Sun, 14 Oct 90 23:47:02 PDT
Received: by ames.arc.nasa.gov (5.64/1.2); Sun, 14 Oct 90 23:47:14 -0700
Received: by AMD.COM (4.1/SMI-4.1-AMD-90.4.28)
id AA20260; Sun, 14 Oct 90 23:46:12 PDT
Date: Sun, 14 Oct 90 23:46:12 PDT
From: [email protected]
Message-Id: <[email protected]>
Subject: Warning From uucp
Apparently-To: [email protected]
To: [email protected]
We have been unable to contact machine 'sun0' since you queued your job.
mail sun0!fay (Date 10/13)
Attempts will continue for a few more days.
Sincerely,
amdcad!uucp
#############################################
##### Data File: ############################
From NIC.DDN.MIL!X3J11-RELAY Sat Oct 13 20:45:07 1990 remote from amdcad
Received: from NIC.DDN.MIL by AMD.COM (4.1/SMI-4.1-AMD-90.4.28)
id AA20813; Sat, 13 Oct 90 20:45:07 PDT
Received: by decwrl.dec.com; id AA18269; Sat, 13 Oct 90 20:41:40 -0700
Received: from vgr.brl.mil by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 19:56:38 PDT
Date: Sat, 13 Oct 90 22:49:55 EDT
From: Doug Gwyn (VLD/VMB) <amdcad!BRL.MIL!gwyn>
To: Keld J|rn Simonsen <dkuug.dk!keld>
Cc: relay.eu.net!rex%aussie, nic.ddn.mil!X3J11
Subject: Re: report delivered to SC22 CHAR WG
Message-Id: <[email protected]>
"Support from WG14" has hardly been varying. The trigraph alternative
proposal was brought up for a vote in WG14 and was defeated. In any
reasonable consensus process that would be the end of the matter.
18-Oct-90 21:23:37-PDT,1085;000000000000
Date: Thu, 18 Oct 90 19:48:47 PDT
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 13-Oct-90 09:34:19
Message undeliverable and dequeued after 5 days:
[email protected]: Cannot connect to host
------------
Received: from dkuug.dk by NIC.DDN.MIL with TCP; Sat, 13 Oct 90 09:33:43 PDT
Received: by dkuug.dk (5.64+/8+bit/IDA-1.2.8)
id AA16843; Sat, 13 Oct 90 17:30:08 +0100
Date: Sat, 13 Oct 90 17:30:08 +0100
From: Keld J|rn Simonsen <[email protected]>
Message-Id: <[email protected]>
To: rex%[email protected]
Subject: Re: report delivered to SC22 CHAR WG
Cc: [email protected]
X-Charset: ASCII
X-Char-Esc: 29
Hi Rex!
Thanks for your comments to my report.
I think your statement on the workings of trigraphs is included
in the report, just with other words. Nobody is saying that
trigraphs does not work.
On the alternate trigraph proposal: This was just described
as a proposal, and no opinion of WG14 was attached to it,
as support from WG14 has been varying...
Regards
Keld
-------
2-Nov-90 10:15:50-PST,3510;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 10:15:42 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA03573; Fri, 2 Nov 90 13:16:02 EST
Date: Fri, 2 Nov 90 13:16:02 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 07:52:53 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA14620; Fri, 2 Nov 90 10:32:47 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02113; Fri, 2 Nov 90 11:10:48 EST
Date: Fri, 2 Nov 90 11:10:48 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: 90-085
WG14/N________
X3J16/________
Accredited Standards Committee Doc No: X3J11/90-085
X3, Information Processing Systems*
Date: 02 Nov 90
*Operating under the procedures of the Project: 381-D
American National Standards Institute Ref Doc:
Reply to: Thomas Plum
Proposing <wchar.h>
I am personally persuaded of the importance of the Multibyte Sup-
port Extension proposed by the ITSCJ.
It appears to have the necessary generality to allow C programs
to be written to be able to support any of the planet-Earth char-
acter sets.
It provides enough functionality that programs can use wchar_t
as a basic data type, performing I/O, classification, string
manipulation, etc, consistently within this type.
My only suggestion would be to request that, as discussed in the
Multibyte Rationale section 2.4.2, alternative iii -- a new
header file -- be adopted as the location for all the new proto-
types. For discussion purposes, I propose the name <wchar.h> .
My reasons concern issues of the format of standards, and of con-
sideration for existing tutorial materials.
The ISO Normative Addendum will provide extra pages to be
attached to the ISO Standard for C. It will make a more coherent
document if those extra pages constitute an extra section for the
Library documentation, one which describes a new, internally-
coherent set of capabilities. The other approach -- modifying
the existing header files -- will produce an Addendum which modi-
fies bits and pieces of the Library sections.
Providing an addendum header will have less impact upon existing
tutorial materials -- manuals, seminars, textbooks. This is the
less confrontational approach.
[These are the personal observations of one individual partici-
pant, not official positions of X3J11, WG14, or X3J16.]
-----------------------------------------------------------------
Standards Secretariats: CBEMA --
Computer and Business Equipment Manufacturers Association
311 First Street NW, Suite 500, Washington DC 20001-2178
Telephone: 202/737-8888 (press "1" twice)
FAX: 202-638-4922 or 202-628-2829
- 1 -
2-Nov-90 10:27:27-PST,3281;000000000000
Date: Fri, 2 Nov 90 10:25:41 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 2-Nov-90 07:53:10
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 07:52:53 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA14620; Fri, 2 Nov 90 10:32:47 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02113; Fri, 2 Nov 90 11:10:48 EST
Date: Fri, 2 Nov 90 11:10:48 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: 90-085
WG14/N________
X3J16/________
Accredited Standards Committee Doc No: X3J11/90-085
X3, Information Processing Systems*
Date: 02 Nov 90
*Operating under the procedures of the Project: 381-D
American National Standards Institute Ref Doc:
Reply to: Thomas Plum
Proposing <wchar.h>
I am personally persuaded of the importance of the Multibyte Sup-
port Extension proposed by the ITSCJ.
It appears to have the necessary generality to allow C programs
to be written to be able to support any of the planet-Earth char-
acter sets.
It provides enough functionality that programs can use wchar_t
as a basic data type, performing I/O, classification, string
manipulation, etc, consistently within this type.
My only suggestion would be to request that, as discussed in the
Multibyte Rationale section 2.4.2, alternative iii -- a new
header file -- be adopted as the location for all the new proto-
types. For discussion purposes, I propose the name <wchar.h> .
My reasons concern issues of the format of standards, and of con-
sideration for existing tutorial materials.
The ISO Normative Addendum will provide extra pages to be
attached to the ISO Standard for C. It will make a more coherent
document if those extra pages constitute an extra section for the
Library documentation, one which describes a new, internally-
coherent set of capabilities. The other approach -- modifying
the existing header files -- will produce an Addendum which modi-
fies bits and pieces of the Library sections.
Providing an addendum header will have less impact upon existing
tutorial materials -- manuals, seminars, textbooks. This is the
less confrontational approach.
[These are the personal observations of one individual partici-
pant, not official positions of X3J11, WG14, or X3J16.]
-----------------------------------------------------------------
Standards Secretariats: CBEMA --
Computer and Business Equipment Manufacturers Association
311 First Street NW, Suite 500, Washington DC 20001-2178
Telephone: 202/737-8888 (press "1" twice)
FAX: 202-638-4922 or 202-628-2829
- 1 -
-------
2-Nov-90 10:32:20-PST,4162;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 10:32:14 PST
Received: from tektronix.tek.com by RELAY.CS.NET id aa18700; 2 Nov 90 13:31 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA25569; Fri, 2 Nov 90 10:31:53 PST
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AA22797; Fri, 2 Nov 90 10:31:45 PST
Date: Fri, 2 Nov 90 10:31:45 PST
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB22667; Fri, 2 Nov 90 10:31:45 PST
Received: from relay.cs.net by RELAY.CS.NET id am24748; 2 Nov 90 13:23 EST
Received: from nic.ddn.mil by RELAY.CS.NET id aa18415; 2 Nov 90 13:18 EST
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 07:52:53 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA14620; Fri, 2 Nov 90 10:32:47 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02113; Fri, 2 Nov 90 11:10:48 EST
Date: Fri, 2 Nov 90 11:10:48 EST
From: Thomas Plum <[email protected]>
Message-Id: <[email protected]>
To: [email protected]
Subject: 90-085
WG14/N________
X3J16/________
Accredited Standards Committee Doc No: X3J11/90-085
X3, Information Processing Systems*
Date: 02 Nov 90
*Operating under the procedures of the Project: 381-D
American National Standards Institute Ref Doc:
Reply to: Thomas Plum
Proposing <wchar.h>
I am personally persuaded of the importance of the Multibyte Sup-
port Extension proposed by the ITSCJ.
It appears to have the necessary generality to allow C programs
to be written to be able to support any of the planet-Earth char-
acter sets.
It provides enough functionality that programs can use wchar_t
as a basic data type, performing I/O, classification, string
manipulation, etc, consistently within this type.
My only suggestion would be to request that, as discussed in the
Multibyte Rationale section 2.4.2, alternative iii -- a new
header file -- be adopted as the location for all the new proto-
types. For discussion purposes, I propose the name <wchar.h> .
My reasons concern issues of the format of standards, and of con-
sideration for existing tutorial materials.
The ISO Normative Addendum will provide extra pages to be
attached to the ISO Standard for C. It will make a more coherent
document if those extra pages constitute an extra section for the
Library documentation, one which describes a new, internally-
coherent set of capabilities. The other approach -- modifying
the existing header files -- will produce an Addendum which modi-
fies bits and pieces of the Library sections.
Providing an addendum header will have less impact upon existing
tutorial materials -- manuals, seminars, textbooks. This is the
less confrontational approach.
[These are the personal observations of one individual partici-
pant, not official positions of X3J11, WG14, or X3J16.]
-----------------------------------------------------------------
Standards Secretariats: CBEMA --
Computer and Business Equipment Manufacturers Association
311 First Street NW, Suite 500, Washington DC 20001-2178
Telephone: 202/737-8888 (press "1" twice)
FAX: 202-638-4922 or 202-628-2829
- 1 -
3-Nov-90 01:57:46-PST,1120;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 01:57:42 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA19570; Sat, 3 Nov 90 04:57:29 EST
Date: Sat, 3 Nov 90 04:57:29 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 00:44:04 PST
Received: from vgr.brl.mil by uunet.uu.net (5.61/1.14) with SMTP
id AA23229; Sat, 3 Nov 90 03:44:25 -0500
Date: Fri, 2 Nov 90 21:19:03 EST
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: [email protected]
Cc: @uunet.uu.net:[email protected]
Subject: Re: 90-085
Message-Id: <[email protected]>
I agree that a new header is needed for (almost) all the new prototypes,
and <wchar.h> seems like a reasonable name for such a header.
3-Nov-90 02:04:58-PST,940;000000000000
Date: Sat, 3 Nov 90 02:00:09 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 3-Nov-90 00:44:11
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 00:44:04 PST
Received: from vgr.brl.mil by uunet.uu.net (5.61/1.14) with SMTP
id AA23229; Sat, 3 Nov 90 03:44:25 -0500
Date: Fri, 2 Nov 90 21:19:03 EST
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: 90-085
Message-Id: <[email protected]>
I agree that a new header is needed for (almost) all the new prototypes,
and <wchar.h> seems like a reasonable name for such a header.
-------
3-Nov-90 02:31:58-PST,1768;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 02:31:54 PST
Received: from tektronix.tek.com by RELAY.CS.NET id aa03468; 3 Nov 90 5:15 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA23967; Sat, 3 Nov 90 02:15:26 PST
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AC20421; Sat, 3 Nov 90 02:15:24 PST
Date: Sat, 3 Nov 90 02:15:24 PST
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from by zephyr.ENS.TEK.COM (4.1/7.1)
id AB20421; Sat, 3 Nov 90 02:15:24 PST
Received: from relay.cs.net by RELAY.CS.NET id aa05278; 3 Nov 90 5:00 EST
Received: from nic.ddn.mil by RELAY.CS.NET id aa03303; 3 Nov 90 4:59 EST
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 00:44:04 PST
Received: from vgr.brl.mil by uunet.uu.net (5.61/1.14) with SMTP
id AA23229; Sat, 3 Nov 90 03:44:25 -0500
Date: Fri, 2 Nov 90 21:19:03 EST
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: 90-085
Message-Id: <[email protected]>
I agree that a new header is needed for (almost) all the new prototypes,
and <wchar.h> seems like a reasonable name for such a header.
3-Nov-90 04:18:16-PST,1460;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 04:18:13 PST
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22309; Sat, 3 Nov 90 07:18:36 -0500
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA26558; Sat, 3 Nov 90 06:05:44 -0600
Date: Sat, 3 Nov 90 06:05:44 -0600
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA25466; Sat, 3 Nov 90 04:34:54 -0600
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA22293; Sat, 3 Nov 90 04:59:18 -0500
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 00:44:04 PST
Received: from vgr.brl.mil by uunet.uu.net (5.61/1.14) with SMTP
id AA23229; Sat, 3 Nov 90 03:44:25 -0500
Date: Fri, 2 Nov 90 21:19:03 EST
From: Doug Gwyn (VLD/VMB) <uunet!BRL.MIL!gwyn>
To: plumhall!plum
Cc: [email protected]
Subject: Re: 90-085
Message-Id: <[email protected]>
I agree that a new header is needed for (almost) all the new prototypes,
and <wchar.h> seems like a reasonable name for such a header.
3-Nov-90 04:18:29-PST,3845;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 04:18:26 PST
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA22366; Sat, 3 Nov 90 07:18:46 -0500
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AB26558; Sat, 3 Nov 90 06:05:59 -0600
Date: Sat, 3 Nov 90 06:05:59 -0600
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA25465; Sat, 3 Nov 90 04:34:52 -0600
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA27313; Sat, 3 Nov 90 03:57:01 -0500
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Fri, 2 Nov 90 07:52:53 PST
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA14620; Fri, 2 Nov 90 10:32:47 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA02113; Fri, 2 Nov 90 11:10:48 EST
Date: Fri, 2 Nov 90 11:10:48 EST
From: uunet!plumhall!plum (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: 90-085
WG14/N________
X3J16/________
Accredited Standards Committee Doc No: X3J11/90-085
X3, Information Processing Systems*
Date: 02 Nov 90
*Operating under the procedures of the Project: 381-D
American National Standards Institute Ref Doc:
Reply to: Thomas Plum
Proposing <wchar.h>
I am personally persuaded of the importance of the Multibyte Sup-
port Extension proposed by the ITSCJ.
It appears to have the necessary generality to allow C programs
to be written to be able to support any of the planet-Earth char-
acter sets.
It provides enough functionality that programs can use wchar_t
as a basic data type, performing I/O, classification, string
manipulation, etc, consistently within this type.
My only suggestion would be to request that, as discussed in the
Multibyte Rationale section 2.4.2, alternative iii -- a new
header file -- be adopted as the location for all the new proto-
types. For discussion purposes, I propose the name <wchar.h> .
My reasons concern issues of the format of standards, and of con-
sideration for existing tutorial materials.
The ISO Normative Addendum will provide extra pages to be
attached to the ISO Standard for C. It will make a more coherent
document if those extra pages constitute an extra section for the
Library documentation, one which describes a new, internally-
coherent set of capabilities. The other approach -- modifying
the existing header files -- will produce an Addendum which modi-
fies bits and pieces of the Library sections.
Providing an addendum header will have less impact upon existing
tutorial materials -- manuals, seminars, textbooks. This is the
less confrontational approach.
[These are the personal observations of one individual partici-
pant, not official positions of X3J11, WG14, or X3J16.]
-----------------------------------------------------------------
Standards Secretariats: CBEMA --
Computer and Business Equipment Manufacturers Association
311 First Street NW, Suite 500, Washington DC 20001-2178
Telephone: 202/737-8888 (press "1" twice)
FAX: 202-638-4922 or 202-628-2829
- 1 -
7-Nov-90 05:31:53-PST,1528;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Wed, 7 Nov 90 05:31:48 PST
Received: from relay2.cs.net by RELAY.CS.NET id cx14756; 7 Nov 90 8:25 EST
Date: Wed, 7 Nov 90 8:10:23 EST
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa05260)
To: [email protected]
After 5 days (98 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa05260; 3 Nov 90 4:59 EST
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 00:44:04 PST
Received: from vgr.brl.mil by uunet.uu.net (5.61/1.14) with SMTP
id AA23229; Sat, 3 Nov 90 03:44:25 -0500
Date: Fri, 2 Nov 90 21:19:03 EST
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: 90-085
Message-Id: <[email protected]>
I agree that a new header is needed for (almost) all the new prototypes,
and <wchar.h> seems like a reasonable name for such a header.
...
9-Nov-90 11:12:40-PST,1395;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Fri, 9 Nov 90 11:12:36 PST
Received: from relay2.cs.net by RELAY.CS.NET id ae05383; 9 Nov 90 12:38 EST
Date: Fri, 9 Nov 90 12:32:53 EST
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Failed mail (msg.aa05260)
To: [email protected]
After 7 days (147 hours), your message could not be
fully delivered.
It failed to be received by the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa05260; 3 Nov 90 4:59 EST
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sat, 3 Nov 90 00:44:04 PST
Received: from vgr.brl.mil by uunet.uu.net (5.61/1.14) with SMTP
id AA23229; Sat, 3 Nov 90 03:44:25 -0500
Date: Fri, 2 Nov 90 21:19:03 EST
From: Doug Gwyn (VLD/VMB) <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: 90-085
Message-Id: <[email protected]>
I agree that a new header is needed for (almost) all the new prototypes,
and <wchar.h> seems like a reasonable name for such a header.
18-Nov-90 21:43:52-PST,1775;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 21:43:49 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA04511; Mon, 19 Nov 90 00:43:57 EST
Date: Mon, 19 Nov 90 00:43:57 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 21:34:37 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02773; Mon, 19 Nov 90 00:35:47 -0500
Date: Sun, 18 Nov 90 14:51:33 EST
From: [email protected] (Rex Jaeschke)
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#[email protected]>
To: [email protected], [email protected]
Please note I now have a domain-style e-mail address. It's
[email protected]
The old address (uunet!aussie!rex) should continue to work, however.
Rex
----------------------------------------------------------------------------
** Note I now have a domain-style address **
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
18-Nov-90 21:46:57-PST,2641;000000000000
Return-Path: <[email protected]>
Received: from decpa.pa.dec.com by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 21:46:53 PST
Received: by decpa.pa.dec.com; id AA06777; Sun, 18 Nov 90 21:47:16 -0800
Date: Sun, 18 Nov 90 21:47:16 -0800
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: [email protected]
----- Transcript of session follows -----
mail11: Error from DECnet MAIL object on node "tle",
during mail delivery to <TLE::RMEYERS>.
Remote error code is 0x7e81fa, message is:
%MAIL-E-OPENOUT, error opening $1$DJA40:[DECNET]MAIL.TXT; as output
-RMS-E-DNR, device not ready, not mounted, or unavailable
(can't decypher error code)
550 <[email protected]>... User unknown
mail11: Error from DECnet MAIL object on node "tle",
during mail delivery to <TLE::BJORK>.
Remote error code is 0x7e81fa, message is:
%MAIL-E-OPENOUT, error opening $1$DJA40:[DECNET]MAIL.TXT; as output
-RMS-E-DNR, device not ready, not mounted, or unavailable
(can't decypher error code)
550 <[email protected]>... User unknown
----- Recipients of this delivery -----
<[email protected]> (bounced)
<[email protected]> (bounced)
----- Unsent message follows -----
Received: by decpa.pa.dec.com; id AA06746; Sun, 18 Nov 90 21:47:16 -0800
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 21:34:37 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02773; Mon, 19 Nov 90 00:35:47 -0500
Date: Sun, 18 Nov 90 14:51:33 EST
From: [email protected] (Rex Jaeschke)
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#[email protected]>
To: [email protected], [email protected]
Please note I now have a domain-style e-mail address. It's
[email protected]
The old address (uunet!aussie!rex) should continue to work, however.
Rex
----------------------------------------------------------------------------
** Note I now have a domain-style address **
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
18-Nov-90 21:49:48-PST,1555;000000000000
Date: Sun, 18 Nov 90 21:46:53 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Nov-90 21:34:44
Message failed for the following:
[email protected].#Internet: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 21:34:37 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02773; Mon, 19 Nov 90 00:35:47 -0500
Date: Sun, 18 Nov 90 14:51:33 EST
From: [email protected] (Rex Jaeschke)
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#[email protected]>
To: [email protected], [email protected]
Please note I now have a domain-style e-mail address. It's
[email protected]
The old address (uunet!aussie!rex) should continue to work, however.
Rex
----------------------------------------------------------------------------
** Note I now have a domain-style address **
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
18-Nov-90 21:59:38-PST,2443;000000000000
Return-Path: <MAILER-DAEMON%[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 21:59:36 PST
Received: from tektronix.tek.com by RELAY.CS.NET id aa16650; 19 Nov 90 0:53 EST
Received: by tektronix.TEK.COM (5.51/7.1)
id AA19108; Sun, 18 Nov 90 21:53:31 PST
Received: by zephyr.ENS.TEK.COM (4.1/7.1)
id AB17922; Sun, 18 Nov 90 21:53:26 PST
Date: Sun, 18 Nov 90 21:53:26 PST
From: Mail Delivery Subsystem <MAILER-DAEMON%[email protected]>
Subject: Returned mail: User unknown
Message-Id: <[email protected]>
To: @RELAY.CS.NET:[email protected]
MMDF-Warning: Parse error in original version of preceding line at RELAY.CS.NET
----- Transcript of session follows -----
Connected to tektronix.tek.com:
>>> RCPT To:<[email protected]>
<<< 550 <[email protected]>... User unknown
550 <[email protected]>... User unknown
----- Unsent message follows -----
Received: from RELAY.CS.NET by zephyr.ENS.TEK.COM (4.1/7.1)
id AA17922; Sun, 18 Nov 90 21:53:26 PST
Received: from relay.cs.net by RELAY.CS.NET id aa09056; 19 Nov 90 0:48 EST
Received: from nic.ddn.mil by RELAY.CS.NET id aa16564; 19 Nov 90 0:47 EST
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 21:34:37 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02773; Mon, 19 Nov 90 00:35:47 -0500
Date: Sun, 18 Nov 90 14:51:33 EST
From: Rex Jaeschke <[email protected]>
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#[email protected]>
To: [email protected], [email protected]
Please note I now have a domain-style e-mail address. It's
[email protected]
The old address (uunet!aussie!rex) should continue to work, however.
Rex
----------------------------------------------------------------------------
** Note I now have a domain-style address **
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
19-Nov-90 10:12:27-PST,1495;000000000000
Date: Mon, 19 Nov 90 10:10:44 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Nov-90 21:34:44
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 21:34:37 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02773; Mon, 19 Nov 90 00:35:47 -0500
Date: Sun, 18 Nov 90 14:51:33 EST
From: [email protected] (Rex Jaeschke)
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#[email protected]>
To: [email protected], [email protected]
Please note I now have a domain-style e-mail address. It's
[email protected]
The old address (uunet!aussie!rex) should continue to work, however.
Rex
----------------------------------------------------------------------------
** Note I now have a domain-style address **
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
19-Nov-90 15:37:02-PST,2147;000000000000
Return-Path: <[email protected]>
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Mon, 19 Nov 90 15:36:57 PST
Received: from convex.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA12458; Mon, 19 Nov 90 17:20:14 -0500
Message-Id: <[email protected]>
Received: by convex.COM (5.61/4.7)
id AA03928; Mon, 19 Nov 90 16:07:59 -0600
Date: Mon, 19 Nov 90 16:07:59 -0600
From: [email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: [email protected]
----- Transcript of session follows -----
bad system name: stellar
uux failed. code 68
550 stellar!pete... Host unknown
----- Unsent message follows -----
Received: from uunet.UUCP by convex.COM (5.61/4.7)
id AA03698; Mon, 19 Nov 90 15:53:50 -0600
Received: from NIC.DDN.MIL by uunet.uu.net (5.61/1.14) with SMTP
id AA06137; Mon, 19 Nov 90 00:46:44 -0500
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Sun, 18 Nov 90 21:34:37 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02773; Mon, 19 Nov 90 00:35:47 -0500
Date: Sun, 18 Nov 90 14:51:33 EST
From: uunet!aussie.COM!rex (Rex Jaeschke)
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#[email protected]>
To: [email protected], [email protected]
Please note I now have a domain-style e-mail address. It's
[email protected]
The old address (uunet!aussie!rex) should continue to work, however.
Rex
----------------------------------------------------------------------------
** Note I now have a domain-style address **
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
12-Dec-90 15:54:01-PST,3096;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Wed, 12 Dec 90 15:53:51 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA08338; Wed, 12 Dec 90 18:53:02 EST
Date: Wed, 12 Dec 90 18:53:02 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 12 Dec 90 02:11:16 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23892; Wed, 12 Dec 90 05:11:12 -0500
Date: Tue, 11 Dec 90 22:05:11 EST
From: [email protected] (Rex Jaeschke)
Subject: Proposed Digraphs
Message-Id: <9012112205.2.UUL1.3#[email protected]>
To: [email protected], [email protected], [email protected],
[email protected]
As you may know, the most recent proposal from Stroustrup continues to
promote alternate spellings for { and }, using (: and :), respectively.
It ocurred to me that these spellings might not be a good idea.
Consider the following program which I believe is ANSI/ISO C conforming.
Granted, such code isn't likely to exist very much (if at all) but
nevertheless, it IS sanctioned by the standards.
#include <stdio.h>
#define M(arg) printf("arg is >" #arg "<\n")
main()
{
M(: :);
M(| |);
M(; ;);
}
arg is >: :<
arg is >| |<
arg is >; ;<
Since you can put pretty much any preprocessing token in a macro argument,
most new spellings of tokens that BEGIN with ( or END with ) can result in
either A QUIET CHANGE TO, OR THE INTRODUCTION OF AN ERROR IN, EXISTING
STANDARD-CONFORMING PROGRAMS. I don't think this is a good thing to do,
politically, particularly if this proposal is supposed to be adopted by ISO
only 2 years after the first ISO standard comes out.
Also, it precludes a program using these new digraphs for { and } from also
calling a macro as shown above. Of course, you could always make the call
M( : : ) so there is space separating the characters but that seems a bit
of a kludge.
Since the pairs {} and [] require trigraphs and I'm suggesting that () may
not be usable either, what about <: and :>? Does this conflict with any
prior art? (Actually, as soon as I wrote this suggestion I recalled that
Microsoft's V6 compiler added the :> operator for based pointer stuff. Oh
well ...)
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
12-Dec-90 15:57:58-PST,3016;000000000000
Date: Wed, 12 Dec 90 15:57:16 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 12-Dec-90 02:11:26
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.uu.net by NIC.DDN.MIL with TCP; Wed, 12 Dec 90 02:11:16 PST
Received: from aussie.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA23892; Wed, 12 Dec 90 05:11:12 -0500
Date: Tue, 11 Dec 90 22:05:11 EST
From: [email protected] (Rex Jaeschke)
Subject: Proposed Digraphs
Message-Id: <9012112205.2.UUL1.3#[email protected]>
To: [email protected], [email protected], [email protected],
[email protected]
As you may know, the most recent proposal from Stroustrup continues to
promote alternate spellings for { and }, using (: and :), respectively.
It ocurred to me that these spellings might not be a good idea.
Consider the following program which I believe is ANSI/ISO C conforming.
Granted, such code isn't likely to exist very much (if at all) but
nevertheless, it IS sanctioned by the standards.
#include <stdio.h>
#define M(arg) printf("arg is >" #arg "<\n")
main()
{
M(: :);
M(| |);
M(; ;);
}
arg is >: :<
arg is >| |<
arg is >; ;<
Since you can put pretty much any preprocessing token in a macro argument,
most new spellings of tokens that BEGIN with ( or END with ) can result in
either A QUIET CHANGE TO, OR THE INTRODUCTION OF AN ERROR IN, EXISTING
STANDARD-CONFORMING PROGRAMS. I don't think this is a good thing to do,
politically, particularly if this proposal is supposed to be adopted by ISO
only 2 years after the first ISO standard comes out.
Also, it precludes a program using these new digraphs for { and } from also
calling a macro as shown above. Of course, you could always make the call
M( : : ) so there is space separating the characters but that seems a bit
of a kludge.
Since the pairs {} and [] require trigraphs and I'm suggesting that () may
not be usable either, what about <: and :>? Does this conflict with any
prior art? (Actually, as soon as I wrote this suggestion I recalled that
Microsoft's V6 compiler added the :> operator for based pointer stuff. Oh
well ...)
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
12-Dec-90 22:06:49-PST,5159;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Wed, 12 Dec 90 22:06:43 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA21988; Thu, 13 Dec 90 01:06:31 EST
Date: Thu, 13 Dec 90 01:06:31 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Wed, 12 Dec 90 20:59:58 PST
Received: from aussie.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA19776; Wed, 12 Dec 90 23:59:59 -0500
Date: Wed, 12 Dec 90 22:03:02 EST
From: [email protected] (Rex Jaeschke)
Subject: NIST Validation status
Message-Id: <9012122203.0.UUL1.3#[email protected]>
To: [email protected], [email protected], [email protected]
NIST is requesting people to beat on the Perennial suite they selected for
US Govt acceptence testing and issued a request for participation Nov
15. Unfortunately, I only found out about it this Monday and applications
close this Friday Dec 14. I will be forwarding something like the
attached message to NIST by email and post requesting to be an initial and
ongoing reviewer of the suite.
If you don't have the same letter I have you will likely be too late to
also participate since the form attached to it is supposed to be mailed in
too. However, I am enclosing the email address of Kathryn Miles at NIST;
she is the contact person there. If you REALLY want to particpate and this
is the first you have heard about this, I urge you to send an email
application to her IMMEDIATELY.
------------------------------------------------------------------
To Kathryn Miles, NIST
[email protected]
Kathryn, you may recall we have spoken several times re C validation.
Unfortunately, Arnold only sent me the `Request for Comments' announcement
Monday and it arrived today. I VERY MUCH want to be one of the 20
trial-use licensees and will mail in the form and letter tomorrow. It
might even reach you by the deadline on Friday.
Briefly, I think I am very well qualified to evaluate a suite and to
suggest improvements. I represent quite a broad audience in the C world.
I am an independent computer consultant, author, and seminar leader and
have the following C involvement:
++ A voting member of the ANSI C Standards Committee X3J11
++ The US International Representative to ISO C
++ Convener and Chairman of the Numerical C Extensions Group (NCEG)
(recently adopted as working group X3J11.1)
++ Publisher and Editor of The Journal of C Language Translation (aimed at
C compiler developers)
++ C Editor of DEC PROFESSIONAL
++ Contributing Editor for The C User's Journal
++ ANSI C columnist for the Programmers Journal
++ Author of numerous books including "Portability and the C
Language", Hayden, 1988; and "Mastering Standard C", Professional
Press, 1989.
++ I teach introductory, advanced, and portability C seminars on a regular
basis, stressing the importance of standards along the way
My book on portability mentions a small test suite I developed myself and
one which I have licensed free of charge to more than 100 companies and
individuals. I use this suite to do a `rough' ANSI C conformance review
of new compilers and so far, have broken EVERY one tested. Interestingly,
most of these vendors claim to have sucessfully passed a commercial suite
such as that from Plum Hall or Perennial. Over the years I have written
many tests to check out the dark corners of the language and I plan to
continue doing so.
With my many and varied involvements with C I have a vested interest in
the sucess of the current and future ANSI and ISO C standards and their
conformance validation processes.
I have about 12 compilers all running under native 16-bit PC/MS-DOS or in
extended mode on 386s under a DOS 32-bit extender. I expect to receive 2 or
3 new ones in the next few months.
As Editor of the Journal of C Language Translation and a member of X3J11
and ISO C's WG14 I am also in a position to inform the vendor community of
suite validation issues and to help get and collate their input. I can do
likewise with the user community via my user-oriented columns.
I look forward to the opportunity to work with you in this matter.
Sincerely,
------------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
12-Dec-90 22:14:11-PST,5079;000000000000
Date: Wed, 12 Dec 90 22:09:39 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 12-Dec-90 21:00:06
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Wed, 12 Dec 90 20:59:58 PST
Received: from aussie.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA19776; Wed, 12 Dec 90 23:59:59 -0500
Date: Wed, 12 Dec 90 22:03:02 EST
From: [email protected] (Rex Jaeschke)
Subject: NIST Validation status
Message-Id: <9012122203.0.UUL1.3#[email protected]>
To: [email protected], [email protected], [email protected]
NIST is requesting people to beat on the Perennial suite they selected for
US Govt acceptence testing and issued a request for participation Nov
15. Unfortunately, I only found out about it this Monday and applications
close this Friday Dec 14. I will be forwarding something like the
attached message to NIST by email and post requesting to be an initial and
ongoing reviewer of the suite.
If you don't have the same letter I have you will likely be too late to
also participate since the form attached to it is supposed to be mailed in
too. However, I am enclosing the email address of Kathryn Miles at NIST;
she is the contact person there. If you REALLY want to particpate and this
is the first you have heard about this, I urge you to send an email
application to her IMMEDIATELY.
------------------------------------------------------------------
To Kathryn Miles, NIST
[email protected]
Kathryn, you may recall we have spoken several times re C validation.
Unfortunately, Arnold only sent me the `Request for Comments' announcement
Monday and it arrived today. I VERY MUCH want to be one of the 20
trial-use licensees and will mail in the form and letter tomorrow. It
might even reach you by the deadline on Friday.
Briefly, I think I am very well qualified to evaluate a suite and to
suggest improvements. I represent quite a broad audience in the C world.
I am an independent computer consultant, author, and seminar leader and
have the following C involvement:
++ A voting member of the ANSI C Standards Committee X3J11
++ The US International Representative to ISO C
++ Convener and Chairman of the Numerical C Extensions Group (NCEG)
(recently adopted as working group X3J11.1)
++ Publisher and Editor of The Journal of C Language Translation (aimed at
C compiler developers)
++ C Editor of DEC PROFESSIONAL
++ Contributing Editor for The C User's Journal
++ ANSI C columnist for the Programmers Journal
++ Author of numerous books including "Portability and the C
Language", Hayden, 1988; and "Mastering Standard C", Professional
Press, 1989.
++ I teach introductory, advanced, and portability C seminars on a regular
basis, stressing the importance of standards along the way
My book on portability mentions a small test suite I developed myself and
one which I have licensed free of charge to more than 100 companies and
individuals. I use this suite to do a `rough' ANSI C conformance review
of new compilers and so far, have broken EVERY one tested. Interestingly,
most of these vendors claim to have sucessfully passed a commercial suite
such as that from Plum Hall or Perennial. Over the years I have written
many tests to check out the dark corners of the language and I plan to
continue doing so.
With my many and varied involvements with C I have a vested interest in
the sucess of the current and future ANSI and ISO C standards and their
conformance validation processes.
I have about 12 compilers all running under native 16-bit PC/MS-DOS or in
extended mode on 386s under a DOS 32-bit extender. I expect to receive 2 or
3 new ones in the next few months.
As Editor of the Journal of C Language Translation and a member of X3J11
and ISO C's WG14 I am also in a position to inform the vendor community of
suite validation issues and to help get and collate their input. I can do
likewise with the user community via my user-oriented columns.
I look forward to the opportunity to work with you in this matter.
Sincerely,
------------------------------------------------------------------
Rex
----------------------------------------------------------------------------
Rex Jaeschke | Journal of C Language Translation | C Users Journal
(703) 860-0091 | 2051 Swans Neck Way | DEC PROFESSIONAL
[email protected] | Reston, Virginia 22091, USA | Programmers Journal
----------------------------------------------------------------------------
Convener of the Numerical C Extensions Group (NCEG)
----------------------------------------------------------------------------
-------
18-Dec-90 17:34:56-PST,1691;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Tue, 18 Dec 90 17:34:51 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA00641; Tue, 18 Dec 90 20:33:54 EST
Date: Tue, 18 Dec 90 20:33:54 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from mail.think.com by NIC.DDN.MIL with TCP; Tue, 18 Dec 90 11:04:40 PST
Return-Path: <[email protected]>
Received: from Wotan.Think.COM by mail.think.com; Tue, 18 Dec 90 14:04:31 -0500
Received: by wotan.think.com (4.0/Think-1.0C)
id AA26485; Tue, 18 Dec 90 14:04:04 EST
Date: Tue, 18 Dec 90 14:04:04 EST
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: Thinking Machines reception during the next NCEG & X3J11 meeting
Date: Thu, 18 Oct 90 14:44:28 EDT
From: [email protected]
Thinking Machines Corporation is pleased to host a reception for NCEG
and X3J11 participants on the evening on Tuesday, March 5, 1991 with
food and refreshments at our site in Cambridge. NCEG and X3J11 delegates
interested in seeing TMC's Connection Machines, applications, parallel
languages, and enjoying superb food should plan to spend Tuesday night
at Thinking Machines. TMC is happy to supply transportation from/to the
meeting/hotel site. Busses will be leaving for Thinking Machines
from the hotel at approximately 6:30 PM.
Jamie Frankel
18-Dec-90 17:40:00-PST,1611;000000000000
Date: Tue, 18 Dec 90 17:38:04 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 18-Dec-90 11:04:49
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from mail.think.com by NIC.DDN.MIL with TCP; Tue, 18 Dec 90 11:04:40 PST
Return-Path: <[email protected]>
Received: from Wotan.Think.COM by mail.think.com; Tue, 18 Dec 90 14:04:31 -0500
Received: by wotan.think.com (4.0/Think-1.0C)
id AA26485; Tue, 18 Dec 90 14:04:04 EST
Date: Tue, 18 Dec 90 14:04:04 EST
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: Thinking Machines reception during the next NCEG & X3J11 meeting
Date: Thu, 18 Oct 90 14:44:28 EDT
From: [email protected]
Thinking Machines Corporation is pleased to host a reception for NCEG
and X3J11 participants on the evening on Tuesday, March 5, 1991 with
food and refreshments at our site in Cambridge. NCEG and X3J11 delegates
interested in seeing TMC's Connection Machines, applications, parallel
languages, and enjoying superb food should plan to spend Tuesday night
at Thinking Machines. TMC is happy to supply transportation from/to the
meeting/hotel site. Busses will be leaving for Thinking Machines
from the hotel at approximately 6:30 PM.
Jamie Frankel
-------
20-Dec-90 23:31:55-PST,2566;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 23:31:47 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA26905; Fri, 21 Dec 90 02:30:49 EST
Date: Fri, 21 Dec 90 02:30:49 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:20 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20336; Thu, 20 Dec 90 17:57:18 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00212; Thu, 20 Dec 90 17:51:25 EST
Date: Thu, 20 Dec 90 17:51:25 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 19:15:47 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AA03208; Tue, 18 Dec 90 19:15:47 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA01425; Tue, 18 Dec 90 16:15:43 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA08236; Tue, 18 Dec 90 16:10:49 -0800
Date: Tue, 18 Dec 90 16:10:49 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 4
Date: 1990 December 18
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 4
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, line 5:
What does '"C" locale' mean?
a) setlocale(LC_ALL,NULL) == "C"
b) setlocale(LC_NUMERIC,NULL) == "C"
c) a) && b)
d) a) || b)
e) something else.
What does 'other than the "C" locale' mean?
a) setlocale(LC_ALL,NULL) != "C"
b) setlocale(LC_NUMERIC,NULL) != "C"
c) a) && b)
d) a) || b)
e) something else.
Section 4.4.1 Locale Control, page 108 may help answer the questions.
20-Dec-90 23:37:43-PST,2486;000000000000
Date: Thu, 20 Dec 90 23:37:05 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Dec-90 14:57:29
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:20 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20336; Thu, 20 Dec 90 17:57:18 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00212; Thu, 20 Dec 90 17:51:25 EST
Date: Thu, 20 Dec 90 17:51:25 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 19:15:47 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AA03208; Tue, 18 Dec 90 19:15:47 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA01425; Tue, 18 Dec 90 16:15:43 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA08236; Tue, 18 Dec 90 16:10:49 -0800
Date: Tue, 18 Dec 90 16:10:49 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 4
Date: 1990 December 18
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 4
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, line 5:
What does '"C" locale' mean?
a) setlocale(LC_ALL,NULL) == "C"
b) setlocale(LC_NUMERIC,NULL) == "C"
c) a) && b)
d) a) || b)
e) something else.
What does 'other than the "C" locale' mean?
a) setlocale(LC_ALL,NULL) != "C"
b) setlocale(LC_NUMERIC,NULL) != "C"
c) a) && b)
d) a) || b)
e) something else.
Section 4.4.1 Locale Control, page 108 may help answer the questions.
-------
20-Dec-90 23:39:57-PST,2483;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 23:39:53 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA26982; Fri, 21 Dec 90 02:38:57 EST
Date: Fri, 21 Dec 90 02:38:57 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:21 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20100; Thu, 20 Dec 90 17:57:06 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00182; Thu, 20 Dec 90 17:51:16 EST
Date: Thu, 20 Dec 90 17:51:16 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 16:45:57 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AB27172; Tue, 18 Dec 90 16:45:57 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA00499; Tue, 18 Dec 90 13:45:54 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA05325; Tue, 18 Dec 90 13:42:25 -0800
Date: Tue, 18 Dec 90 13:42:25 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 1
Date: 1990 December 18
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 1
What is the result of: printf( "%#.4o", 345 );? Is it "0531" or is
it "00531"?
ANSI C X3.159-1989, page 133, lines 37-38: "For o conversion, it
increases the precision to force the first digit of the result to be a
zero."
Is this a conditional or an unconditional increase in the precision if
the most significant digit is not already a 0? Which is the correct
interpretation?
20-Dec-90 23:46:41-PST,3877;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 23:46:35 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA27015; Fri, 21 Dec 90 02:45:37 EST
Date: Fri, 21 Dec 90 02:45:37 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:26 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20195; Thu, 20 Dec 90 17:57:10 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00192; Thu, 20 Dec 90 17:51:21 EST
Date: Thu, 20 Dec 90 17:51:21 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 17:51:04 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AA15395; Tue, 18 Dec 90 17:51:04 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA00899; Tue, 18 Dec 90 14:51:01 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA06602; Tue, 18 Dec 90 14:44:40 -0800
Date: Tue, 18 Dec 90 14:44:40 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 2
Date: 1990 December 18
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 2
What is the result of: strtod( "100ergs", &ptr);? Is it 100.0 or is
it 0.0?
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 151, lines
36-38: 'The subject sequence is defined as the longest initial
subsequence of the input string, starting with the first
non-white-space character, that is of the expected form.' In this
case, the longest initial subsequence of the expected form is "100",
so 100.0 should be the return value. Also, since the entire string is
in memory, strtod can scan it as many times as need be to find the
longest valid initial subsequence.
ANSI C X3.159-1989, 4.9.6.2 The fscanf Function, page 137, lines
17-18: 'e,f,g Matches an optionally signed floating-point number,
whose format is the same as expected for the subject string of the
strtod function.' Later, page 139, lines 6, 16, and 25 show that
'100ergs' fails to match "%f". Those two show that '100ergs' is
invalid to fscanf and therefore, invalid to strtod. Then, page 152,
lines 11-12 'If no conversion could be performed, zero is returned'
indicates for an error input, 0.0 should be returned. The reason this
is invalid is spelled out in the Rationale, 4.9.6.2 The fscanf
function, page 95, 'One-character pushback is sufficient for the
implementation of fscanf. Given the invalid field "-.x", the
characters "-." are not pushed back.' And later, 'The conversions
performed by fscanf are compatible with those performed by strtod and
strtol.'
So, do strtod and fscanf act alike and both accept and fail on the
same inputs, by the one-character pushback scanning strategy, or do
they use different scanning strategies and strtod accept more than
fscanf?
20-Dec-90 23:47:41-PST,2403;000000000000
Date: Thu, 20 Dec 90 23:43:47 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Dec-90 14:57:43
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:21 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20100; Thu, 20 Dec 90 17:57:06 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00182; Thu, 20 Dec 90 17:51:16 EST
Date: Thu, 20 Dec 90 17:51:16 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 16:45:57 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AB27172; Tue, 18 Dec 90 16:45:57 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA00499; Tue, 18 Dec 90 13:45:54 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA05325; Tue, 18 Dec 90 13:42:25 -0800
Date: Tue, 18 Dec 90 13:42:25 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 1
Date: 1990 December 18
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 1
What is the result of: printf( "%#.4o", 345 );? Is it "0531" or is
it "00531"?
ANSI C X3.159-1989, page 133, lines 37-38: "For o conversion, it
increases the precision to force the first digit of the result to be a
zero."
Is this a conditional or an unconditional increase in the precision if
the most significant digit is not already a 0? Which is the correct
interpretation?
-------
20-Dec-90 23:52:43-PST,3797;000000000000
Date: Thu, 20 Dec 90 23:52:22 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Dec-90 14:57:54
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:26 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20195; Thu, 20 Dec 90 17:57:10 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00192; Thu, 20 Dec 90 17:51:21 EST
Date: Thu, 20 Dec 90 17:51:21 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 17:51:04 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AA15395; Tue, 18 Dec 90 17:51:04 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA00899; Tue, 18 Dec 90 14:51:01 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA06602; Tue, 18 Dec 90 14:44:40 -0800
Date: Tue, 18 Dec 90 14:44:40 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 2
Date: 1990 December 18
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 2
What is the result of: strtod( "100ergs", &ptr);? Is it 100.0 or is
it 0.0?
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 151, lines
36-38: 'The subject sequence is defined as the longest initial
subsequence of the input string, starting with the first
non-white-space character, that is of the expected form.' In this
case, the longest initial subsequence of the expected form is "100",
so 100.0 should be the return value. Also, since the entire string is
in memory, strtod can scan it as many times as need be to find the
longest valid initial subsequence.
ANSI C X3.159-1989, 4.9.6.2 The fscanf Function, page 137, lines
17-18: 'e,f,g Matches an optionally signed floating-point number,
whose format is the same as expected for the subject string of the
strtod function.' Later, page 139, lines 6, 16, and 25 show that
'100ergs' fails to match "%f". Those two show that '100ergs' is
invalid to fscanf and therefore, invalid to strtod. Then, page 152,
lines 11-12 'If no conversion could be performed, zero is returned'
indicates for an error input, 0.0 should be returned. The reason this
is invalid is spelled out in the Rationale, 4.9.6.2 The fscanf
function, page 95, 'One-character pushback is sufficient for the
implementation of fscanf. Given the invalid field "-.x", the
characters "-." are not pushed back.' And later, 'The conversions
performed by fscanf are compatible with those performed by strtod and
strtol.'
So, do strtod and fscanf act alike and both accept and fail on the
same inputs, by the one-character pushback scanning strategy, or do
they use different scanning strategies and strtod accept more than
fscanf?
-------
20-Dec-90 23:56:03-PST,3733;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 23:55:58 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA27171; Fri, 21 Dec 90 02:55:02 EST
Date: Fri, 21 Dec 90 02:55:02 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:22 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20282; Thu, 20 Dec 90 17:57:15 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00202; Thu, 20 Dec 90 17:51:23 EST
Date: Thu, 20 Dec 90 17:51:23 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 18:53:41 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AA28593; Tue, 18 Dec 90 18:53:41 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA01112; Tue, 18 Dec 90 15:25:46 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA07381; Tue, 18 Dec 90 15:20:10 -0800
Date: Tue, 18 Dec 90 15:20:10 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 3
Date: 1990 December 18
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 3
Assuming that 99999 is larger than DBL_MAX_10_EXP, what is the result
of: strtod( "0.0e99999", &ptr);? Is it 0.0, HUGE_VAL, or undefined?
ANSI C X3.159-1989, 3.1.3.1 Floating Constants, page 27, lines 30-32:
'The significand part is interpreted as a decimal rational number; the
digit sequence in the exponent part is interpreted as a decimal
integer. The exponent indicates the power of 10 by which the
significand part is to be scaled.' In this case 0.0e99999 means 0.0
times 10 to the power 99999, or 0.0 * 10 ** 99999, which has a scaled
value of 0.0; therefore, return 0.0
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, lines
12-14: 'If the correct value is outside the range of representable
values, plus or minus HUGE_VAL is returned (according to the sign of
the value), and the value of the macro ERANGE is stored in errno'.
Since the exponent (99999 in this case) is larger than DBL_MAX_10_EXP,
the value if outside the range of representable values (overflow).
Therefore, return HUGE_VAL.
ANSI C X3.159-1989, 2.2.4.2.2 Characteristics of Floating Types
<float.h>, pages 15 and 16, describe the model that defines the
floating-point types. The number 0.0e99999, as written, is not part
of that model (it cannot be represented since the exponent is larger
than e-max). From 3.2.1.4 Floating Types, page 36, lines 11-13,
'...if the value being converted is outside the range of values that
can be represented, the behavior is undefined.' Therefore, since this
number, as written, has no representation, the behavior is undefined.
21-Dec-90 00:07:44-PST,3653;000000000000
Date: Fri, 21 Dec 90 00:06:30 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Dec-90 14:58:06
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:22 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20282; Thu, 20 Dec 90 17:57:15 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00202; Thu, 20 Dec 90 17:51:23 EST
Date: Thu, 20 Dec 90 17:51:23 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 18:53:41 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AA28593; Tue, 18 Dec 90 18:53:41 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA01112; Tue, 18 Dec 90 15:25:46 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA07381; Tue, 18 Dec 90 15:20:10 -0800
Date: Tue, 18 Dec 90 15:20:10 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 3
Date: 1990 December 18
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 3
Assuming that 99999 is larger than DBL_MAX_10_EXP, what is the result
of: strtod( "0.0e99999", &ptr);? Is it 0.0, HUGE_VAL, or undefined?
ANSI C X3.159-1989, 3.1.3.1 Floating Constants, page 27, lines 30-32:
'The significand part is interpreted as a decimal rational number; the
digit sequence in the exponent part is interpreted as a decimal
integer. The exponent indicates the power of 10 by which the
significand part is to be scaled.' In this case 0.0e99999 means 0.0
times 10 to the power 99999, or 0.0 * 10 ** 99999, which has a scaled
value of 0.0; therefore, return 0.0
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, lines
12-14: 'If the correct value is outside the range of representable
values, plus or minus HUGE_VAL is returned (according to the sign of
the value), and the value of the macro ERANGE is stored in errno'.
Since the exponent (99999 in this case) is larger than DBL_MAX_10_EXP,
the value if outside the range of representable values (overflow).
Therefore, return HUGE_VAL.
ANSI C X3.159-1989, 2.2.4.2.2 Characteristics of Floating Types
<float.h>, pages 15 and 16, describe the model that defines the
floating-point types. The number 0.0e99999, as written, is not part
of that model (it cannot be represented since the exponent is larger
than e-max). From 3.2.1.4 Floating Types, page 36, lines 11-13,
'...if the value being converted is outside the range of values that
can be represented, the behavior is undefined.' Therefore, since this
number, as written, has no representation, the behavior is undefined.
-------
21-Dec-90 00:11:17-PST,13302;000000000000
Return-Path: <[email protected]>
Received: from harvard.harvard.edu by NIC.DDN.MIL with TCP; Fri, 21 Dec 90 00:11:04 PST
Received: by harvard.harvard.edu (5.54/a0.25)
(for [email protected]) id AA27475; Fri, 21 Dec 90 03:10:07 EST
Date: Fri, 21 Dec 90 03:10:07 EST
From: MAILER-DAEMON%[email protected] (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <[email protected]>
----- Transcript of session follows -----
550 <kendall%[email protected]>... Host unknown
----- Unsent message follows -----
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:33 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20388; Thu, 20 Dec 90 17:57:21 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00222; Thu, 20 Dec 90 17:51:28 EST
Date: Thu, 20 Dec 90 17:51:28 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Wed Dec 19 18:40:52 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AA28980; Wed, 19 Dec 90 18:40:52 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA08292; Wed, 19 Dec 90 15:40:49 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA22257; Wed, 19 Dec 90 15:38:09 -0800
Date: Wed, 19 Dec 90 15:38:09 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 5
Date: 1990 December 19
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 5
What is meant by 'representable floating-point value'? Assume double
precision, unless stated otherwise.
First, some definitions based partially upon the floating-point model
on pages 15-16 of ANSI C X3.159-1989:
1) +Normal Numbers: DBL_MIN to DBL_MAX, inclusive; normalized (first
significand digit is non-zero), sign is +1.
2) -Normal Numbers: -DBL_MAX to -DBL_MIN, inclusive; normalized.
3) +Zero: All digits zero, sign is +1; (true zero).
4) -Zero: All digits zero, sign is -1.
5) Zero: Union of +zero and -zero.
6) +Denormals: Exponent is "minimum" (Biased exponent is zero);
first significand digit is zero; sign is +1. These are in range
+DBL_DeN (inclusive) to +DBL_MIN (exclusive). Let DBL_DeN be the
symbol for the minimum denormal, so we can talk about it by name.
7) -Denormals: Same as +denormals, except sign, and range is
-DBL_MIN (exclusive) to -DBL_DeN (inclusive).
8) +Unnormals: Biased exponent is non-zero; first significand digit
is zero; sign is +1. These overlap the range of +normals and
+denormals.
9) -Unnormals: Same as +unnormals, except sign; range is over
-normals and -denormals.
10) +infinity: From IEEE-754.
11) -infinity: From IEEE-754.
12) Quiet NaN (Not a Number); sign does not matter; from IEEE-754.
13) Signaling NaN; sign does not matter; from IEEE-754.
14) NaN: Union of Quiet NaN and Signaling NaN.
15) Others: Reserved (VAX?) and Indefinite (CDC/Cray?) act like NaN.
On the real number line, these symbols order as:
[ 1 )[ 2 ]( 3 ]( 4 )[ 5 ]( 6 )[ 7 )[ 8 ]( 9 ]
+------+--------+--------+-----+---+-----+--------+--------+------+
-INF -DBL_MAX -DBL_MIN -DBL_DeN -0 +0 +DBL_DeN +DBL_MIN +DBL_MAX +INF
Non-real numbers are: SNaN, QNaN, and NaN, call this region 10.
Regions 1 and 9 are overflow, 2 and 8 are normal numbers, 3 and 7 are
denormal numbers (psuedo underflow), 4 and 6 are true underflow, and 5
is zero.
So, the question is: What does 'representable (double precision)
floating-point value' mean:
a) Regions 2, 5 and 8 (+/- normals and zero)
b) Regions 2, 3, 5, 7, and 8 (+/- normals, denormals, and zero)
c) Regions 2 through 8 [-DBL_MAX ... +DBL_MAX]
d) Regions 1 through 9 [-INF ... +INF]
e) Regions 1 through 10 (reals and non-reals)
f) What the hardware can represent
g) Something else? What?
Some things to consider in your answer follow. The questions that
follow are rhetorical and do not need answers.
ANSI C X3.159-1989, 2.2.4.2.2 Characteristics of Floating Types
<float.h>, page 15, lines 32-35, 'The characteristics of floating
types are defined in terms of a model that describes a representation
of floating-point numbers and values that provide information about an
implementation's floating-point arithmetic.' Same section, page 16
line 6, 'A normalized floating-point number x ... is defined by the
following model ...'.
That model is just normalized numbers and zero (appears to include
signed zeros). It excludes denormal and unnormal numbers,
infinities, and NaNs. Are signed zeros required, or just allowed?
ANSI C X3.159-1989, 3.1.3.1 Floating Constants, page 27, lines 32-35,
'If the scaled value is in the range of representable values (for its
type) the result is either the nearest representable value, or the
larger or smaller representable value immediately adjacent to the
nearest value, chosen in an implementation-defined manner.'
------+-----+------+--------+----...----+-----+---
A B y C x D E z F
-DBL_Den 0.0 +DBL_Den +DBL_MIN ... DBL_MAX INF
The representable numbers are A,B,C,D,E and F. The number x can be
converted to B, C, or D! But what if B is zero, C is DBL_DeN
(denormal), and D is DBL_MIN (normalized). Is x representable?
It is not in the range DBL_MIN...DBL_MAX and its inverse causes
overflow; so those say not valid. On the other hand, it is in the
range DBL_DeN...DBL_MAX and it does not cause underflow; so those
say it is valid.
What if B is zero, A is -DBL_DeN (denormal), and C is +DBL_DeN
(denormal). Is y representable? If so, its nearest value is
zero, and the immediately adjacent values include a positive and a
negative number. So a user written positive is allowed to end up
with a negative value!
What if E is DBL_MAX and F is infinity (on a machine that uses
infinities, IEEE-754)? Does z have a representation? If z came
from 1.0/x, then z caused overflow which says invalid. But on
IEEE-754 machines, it would either be DBL_MAX or infinity
depending upon the rounding control, so it has a representation
and is valid.
What is nearest? In linear or logarithmic sense? If the number
is between 0 and DBL_DeN, 1e-9999999 is linear nearest to zero,
but log nearest to DBL_DeN. If number is between DBL_MAX and INF,
1e+999999 is linear and log nearest to DBL_MAX. Or is everything
bigger than DBL_MAX nearest to INF?
ANSI C X3.159-1989, 3.2.1.3 Floating and Integral, page 36, footnote
29, 'Thus, the range of portable floating values is (-1,Utype_MAX+1).'
ANSI C X3.159-1989, 3.2.1.4 Floating Types, page 36, lines 11-15,
'When a double is demoted to float or a long double to double or
float, if the value being converted is outside the range of values
that can be represented, the behavior is undefined. If the value
being converted is in the range of values that can be represented but
cannot be represented exactly, the result is either the nearest higher
or nearest lower value, chosen in an implementation-defined manner.'
ANSI C X3.159-1989, 3.3 Expressions, page 39, lines 15-17, 'If an
exception occurs during the evaluation of an expression (that is, if
the result is not mathematically defined or not in the range of
representable values for its type), the behavior is undefined.'
w = 1.0 / 0.0 ; /* infinity in IEEE-754 */
x = 0.0 / 0.0 ; /* NaN in IEEE-754 */
y = +0.0 ; /* plus zero */
z = - y ; /* minus zero: Must this be -0.0? May it be +0.0? */
Are the above representable?
ANSI C X3.159-1989, 4.5.1 Treatment of Error Conditions, page 112,
lines 11-12, 'The behavior of each of these functions is defined for
all representable values of its input arguments.'
What about non-numbers? Are they representable? What is
sin(NaN);? If you got a NaN as input, then you can return NaN as
output. But, is it a domain error? Must errno be set to EDOM?
The NaN already indicates an error, so setting errno adds no more
information. Assuming NaN is not part of ANSI C representable,
but the hardware supports it, then using NaNs is an extension of
ANSI C and setting errno need not be required, but is allowed.
Correct?
ANSI C X3.159-1989, 4.5.1 Treatment of Error Conditions, page 112,
lines 20-27, 'Similarly, a range error occurs if the result of the
function cannot be represented as a double value. If the result
overflows (the magnitude of the result is so large that it cannot be
represented in an object of the specified type), the function returns
the value of the macro HUGE_VAL, with the same sign (except for the
tan function) as the correct value of the function; the value of the
macro ERANGE is stored in errno. If the result underflows (the
magnitude of the result is so small that it cannot be represented in
an object of the specified type), the function returns zero; whether
the integer expression errno acquires the value of the macro ERANGE is
implementation-defined.'
What about denormal numbers? What is sin(DBL_MIN / 3.0L);? Must
this be considered underflow and therefore return zero, and maybe
set errno to ERANGE? Or may it return DBL_MIN / 3.0, a denormal
number? Assuming denormals are not part of ANSI C representable,
but the hardware supports it, then using them is an extension of
ANSI C and setting errno need not be required, but is allowed.
Correct?
What about infinity? What is exp(INF);? If you got an INF as
input, then you can return INF as output. But, is it a range
error? The output value is representable, so that says no error.
The output value is bigger than DBL_MAX, so that says an error and
set errno to ERANGE. Assuming infinity is not part of ANSI C
representable, but the hardware supports it, then using INFs is an
extension of ANSI C and setting errno need not be required, but is
allowed. Correct?
What about signed zeros? What is sin(-0.0);? Must this return
-0.0? May it return -0.0? May it return +0.0? Signed zeros
appear to be required in the model on page 16.
What is sqrt(-0.0);? IEEE-754 and IEEE-854 (floating-point
standards) say this must be -0. Is -0.0 negative? Is this a
domain error?
ANSI C X3.159-1989, 4.9.6.1 The fprintf Function, page 133, lines
32-33, '(It will begin with a sign only when a negative value is
converted if this flag is not specified.)'
What is fprintf(stdout, "%+.1f", -0.0);? Must it be -0.0? May it
be +0.0? Is -0.0 a negative value? The model on page 16 appears
to require support for signed zeros.
What is fprintf(stdout, "%f %f", 1.0/0.0, 0.0/0.0);? May it be
the IEEE-854 strings of 'inf' or 'infinity' for the infinity and
'NaN' the quiet NaN? Would 'NaNQ' also be allowed for a quiet
NaN? Would 'NaNS' be allowed for a signaling NaN? Must the sign
be printed? Signs are optional in IEEE-754 and IEEE-854. Or,
must it be some decimal notation as specified by page 134, line
19. Does the locale matter?
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, lines 1-2,
'If the subject sequence begins with a minus sign, the value resulting
from the conversion is negated.'
What is strtod("-0.0", &ptr);? Must it be -0.0? May it be +0.0?
The model on page 16 appears to require support for signed zeros.
All floating-point hardware I know about support signed zeros at
least at the load, store, and negate/complement instruction level.
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, lines
12-15, 'If the correct value is outside the range of representable
values, plus or minus HUGE_VAL is returned (according to the sign of
the value), and the value of the macro ERANGE is stored in errno. If
the correct value would cause underflow, zero is returned and the
value of the macro ERANGE is stored in errno.'
If HUGE_VAL is +infinity, then is strtod("1e999999",&ptr); outside
the range of representable values and a range error? Or is it the
'nearest' of DBL_MAX and INF?
21-Dec-90 00:17:44-PST,13222;000000000000
Date: Fri, 21 Dec 90 00:15:00 PST
From: The Mailer Daemon <[email protected]>
To: [email protected]
Subject: Message of 20-Dec-90 14:58:28
Message failed for the following:
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
[email protected]: 550 <[email protected]>... User unknown
------------
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:33 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20388; Thu, 20 Dec 90 17:57:21 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00222; Thu, 20 Dec 90 17:51:28 EST
Date: Thu, 20 Dec 90 17:51:28 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Wed Dec 19 18:40:52 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
id AA28980; Wed, 19 Dec 90 18:40:52 -0500
Received: by ibminet.awdpa.ibm.com (5.61/1.14)
id AA08292; Wed, 19 Dec 90 15:40:49 -0800
Received: by ibmpa.awdpa.ibm.com (5.61/1.15)
id AA22257; Wed, 19 Dec 90 15:38:09 -0800
Date: Wed, 19 Dec 90 15:38:09 -0800
From: uunet!ibminet.awdpa.ibm.com!ibmpa!tydeman (Fred Tydeman)
Message-Id: <[email protected]>
To: [email protected]
Subject: RFI 5
Date: 1990 December 19
To: ANSI C committee via Thomas Plum, Vice-Chair
[email protected]
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430
Subject: Formal Request For Interpretation Number 5
What is meant by 'representable floating-point value'? Assume double
precision, unless stated otherwise.
First, some definitions based partially upon the floating-point model
on pages 15-16 of ANSI C X3.159-1989:
1) +Normal Numbers: DBL_MIN to DBL_MAX, inclusive; normalized (first
significand digit is non-zero), sign is +1.
2) -Normal Numbers: -DBL_MAX to -DBL_MIN, inclusive; normalized.
3) +Zero: All digits zero, sign is +1; (true zero).
4) -Zero: All digits zero, sign is -1.
5) Zero: Union of +zero and -zero.
6) +Denormals: Exponent is "minimum" (Biased exponent is zero);
first significand digit is zero; sign is +1. These are in range
+DBL_DeN (inclusive) to +DBL_MIN (exclusive). Let DBL_DeN be the
symbol for the minimum denormal, so we can talk about it by name.
7) -Denormals: Same as +denormals, except sign, and range is
-DBL_MIN (exclusive) to -DBL_DeN (inclusive).
8) +Unnormals: Biased exponent is non-zero; first significand digit
is zero; sign is +1. These overlap the range of +normals and
+denormals.
9) -Unnormals: Same as +unnormals, except sign; range is over
-normals and -denormals.
10) +infinity: From IEEE-754.
11) -infinity: From IEEE-754.
12) Quiet NaN (Not a Number); sign does not matter; from IEEE-754.
13) Signaling NaN; sign does not matter; from IEEE-754.
14) NaN: Union of Quiet NaN and Signaling NaN.
15) Others: Reserved (VAX?) and Indefinite (CDC/Cray?) act like NaN.
On the real number line, these symbols order as:
[ 1 )[ 2 ]( 3 ]( 4 )[ 5 ]( 6 )[ 7 )[ 8 ]( 9 ]
+------+--------+--------+-----+---+-----+--------+--------+------+
-INF -DBL_MAX -DBL_MIN -DBL_DeN -0 +0 +DBL_DeN +DBL_MIN +DBL_MAX +INF
Non-real numbers are: SNaN, QNaN, and NaN, call this region 10.
Regions 1 and 9 are overflow, 2 and 8 are normal numbers, 3 and 7 are
denormal numbers (psuedo underflow), 4 and 6 are true underflow, and 5
is zero.
So, the question is: What does 'representable (double precision)
floating-point value' mean:
a) Regions 2, 5 and 8 (+/- normals and zero)
b) Regions 2, 3, 5, 7, and 8 (+/- normals, denormals, and zero)
c) Regions 2 through 8 [-DBL_MAX ... +DBL_MAX]
d) Regions 1 through 9 [-INF ... +INF]
e) Regions 1 through 10 (reals and non-reals)
f) What the hardware can represent
g) Something else? What?
Some things to consider in your answer follow. The questions that
follow are rhetorical and do not need answers.
ANSI C X3.159-1989, 2.2.4.2.2 Characteristics of Floating Types
<float.h>, page 15, lines 32-35, 'The characteristics of floating
types are defined in terms of a model that describes a representation
of floating-point numbers and values that provide information about an
implementation's floating-point arithmetic.' Same section, page 16
line 6, 'A normalized floating-point number x ... is defined by the
following model ...'.
That model is just normalized numbers and zero (appears to include
signed zeros). It excludes denormal and unnormal numbers,
infinities, and NaNs. Are signed zeros required, or just allowed?
ANSI C X3.159-1989, 3.1.3.1 Floating Constants, page 27, lines 32-35,
'If the scaled value is in the range of representable values (for its
type) the result is either the nearest representable value, or the
larger or smaller representable value immediately adjacent to the
nearest value, chosen in an implementation-defined manner.'
------+-----+------+--------+----...----+-----+---
A B y C x D E z F
-DBL_Den 0.0 +DBL_Den +DBL_MIN ... DBL_MAX INF
The representable numbers are A,B,C,D,E and F. The number x can be
converted to B, C, or D! But what if B is zero, C is DBL_DeN
(denormal), and D is DBL_MIN (normalized). Is x representable?
It is not in the range DBL_MIN...DBL_MAX and its inverse causes
overflow; so those say not valid. On the other hand, it is in the
range DBL_DeN...DBL_MAX and it does not cause underflow; so those
say it is valid.
What if B is zero, A is -DBL_DeN (denormal), and C is +DBL_DeN
(denormal). Is y representable? If so, its nearest value is
zero, and the immediately adjacent values include a positive and a
negative number. So a user written positive is allowed to end up
with a negative value!
What if E is DBL_MAX and F is infinity (on a machine that uses
infinities, IEEE-754)? Does z have a representation? If z came
from 1.0/x, then z caused overflow which says invalid. But on
IEEE-754 machines, it would either be DBL_MAX or infinity
depending upon the rounding control, so it has a representation
and is valid.
What is nearest? In linear or logarithmic sense? If the number
is between 0 and DBL_DeN, 1e-9999999 is linear nearest to zero,
but log nearest to DBL_DeN. If number is between DBL_MAX and INF,
1e+999999 is linear and log nearest to DBL_MAX. Or is everything
bigger than DBL_MAX nearest to INF?
ANSI C X3.159-1989, 3.2.1.3 Floating and Integral, page 36, footnote
29, 'Thus, the range of portable floating values is (-1,Utype_MAX+1).'
ANSI C X3.159-1989, 3.2.1.4 Floating Types, page 36, lines 11-15,
'When a double is demoted to float or a long double to double or
float, if the value being converted is outside the range of values
that can be represented, the behavior is undefined. If the value
being converted is in the range of values that can be represented but
cannot be represented exactly, the result is either the nearest higher
or nearest lower value, chosen in an implementation-defined manner.'
ANSI C X3.159-1989, 3.3 Expressions, page 39, lines 15-17, 'If an
exception occurs during the evaluation of an expression (that is, if
the result is not mathematically defined or not in the range of
representable values for its type), the behavior is undefined.'
w = 1.0 / 0.0 ; /* infinity in IEEE-754 */
x = 0.0 / 0.0 ; /* NaN in IEEE-754 */
y = +0.0 ; /* plus zero */
z = - y ; /* minus zero: Must this be -0.0? May it be +0.0? */
Are the above representable?
ANSI C X3.159-1989, 4.5.1 Treatment of Error Conditions, page 112,
lines 11-12, 'The behavior of each of these functions is defined for
all representable values of its input arguments.'
What about non-numbers? Are they representable? What is
sin(NaN);? If you got a NaN as input, then you can return NaN as
output. But, is it a domain error? Must errno be set to EDOM?
The NaN already indicates an error, so setting errno adds no more
information. Assuming NaN is not part of ANSI C representable,
but the hardware supports it, then using NaNs is an extension of
ANSI C and setting errno need not be required, but is allowed.
Correct?
ANSI C X3.159-1989, 4.5.1 Treatment of Error Conditions, page 112,
lines 20-27, 'Similarly, a range error occurs if the result of the
function cannot be represented as a double value. If the result
overflows (the magnitude of the result is so large that it cannot be
represented in an object of the specified type), the function returns
the value of the macro HUGE_VAL, with the same sign (except for the
tan function) as the correct value of the function; the value of the
macro ERANGE is stored in errno. If the result underflows (the
magnitude of the result is so small that it cannot be represented in
an object of the specified type), the function returns zero; whether
the integer expression errno acquires the value of the macro ERANGE is
implementation-defined.'
What about denormal numbers? What is sin(DBL_MIN / 3.0L);? Must
this be considered underflow and therefore return zero, and maybe
set errno to ERANGE? Or may it return DBL_MIN / 3.0, a denormal
number? Assuming denormals are not part of ANSI C representable,
but the hardware supports it, then using them is an extension of
ANSI C and setting errno need not be required, but is allowed.
Correct?
What about infinity? What is exp(INF);? If you got an INF as
input, then you can return INF as output. But, is it a range
error? The output value is representable, so that says no error.
The output value is bigger than DBL_MAX, so that says an error and
set errno to ERANGE. Assuming infinity is not part of ANSI C
representable, but the hardware supports it, then using INFs is an
extension of ANSI C and setting errno need not be required, but is
allowed. Correct?
What about signed zeros? What is sin(-0.0);? Must this return
-0.0? May it return -0.0? May it return +0.0? Signed zeros
appear to be required in the model on page 16.
What is sqrt(-0.0);? IEEE-754 and IEEE-854 (floating-point
standards) say this must be -0. Is -0.0 negative? Is this a
domain error?
ANSI C X3.159-1989, 4.9.6.1 The fprintf Function, page 133, lines
32-33, '(It will begin with a sign only when a negative value is
converted if this flag is not specified.)'
What is fprintf(stdout, "%+.1f", -0.0);? Must it be -0.0? May it
be +0.0? Is -0.0 a negative value? The model on page 16 appears
to require support for signed zeros.
What is fprintf(stdout, "%f %f", 1.0/0.0, 0.0/0.0);? May it be
the IEEE-854 strings of 'inf' or 'infinity' for the infinity and
'NaN' the quiet NaN? Would 'NaNQ' also be allowed for a quiet
NaN? Would 'NaNS' be allowed for a signaling NaN? Must the sign
be printed? Signs are optional in IEEE-754 and IEEE-854. Or,
must it be some decimal notation as specified by page 134, line
19. Does the locale matter?
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, lines 1-2,
'If the subject sequence begins with a minus sign, the value resulting
from the conversion is negated.'
What is strtod("-0.0", &ptr);? Must it be -0.0? May it be +0.0?
The model on page 16 appears to require support for signed zeros.
All floating-point hardware I know about support signed zeros at
least at the load, store, and negate/complement instruction level.
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, lines
12-15, 'If the correct value is outside the range of representable
values, plus or minus HUGE_VAL is returned (according to the sign of
the value), and the value of the macro ERANGE is stored in errno. If
the correct value would cause underflow, zero is returned and the
value of the macro ERANGE is stored in errno.'
If HUGE_VAL is +infinity, then is strtod("1e999999",&ptr); outside
the range of representable values and a range error? Or is it the
'nearest' of DBL_MAX and INF?
-------
23-Dec-90 15:20:28-PST,1545;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Sun, 23 Dec 90 15:20:24 PST
Received: from relay2.cs.net by RELAY.CS.NET id ac09890; 23 Dec 90 18:18 EST
Date: Sun, 23 Dec 90 18:12:29 EST
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.ac02788)
To: [email protected]
After 5 days (107 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from [192.67.67.20] by RELAY.CS.NET id ac02788; 18 Dec 90 20:39 EST
Received: from mail.think.com by NIC.DDN.MIL with TCP; Tue, 18 Dec 90 11:04:40 PST
Return-Path: <[email protected]>
Received: from Wotan.Think.COM by mail.think.com; Tue, 18 Dec 90 14:04:31 -0500
Received: by wotan.think.com (4.0/Think-1.0C)
id AA26485; Tue, 18 Dec 90 14:04:04 EST
Date: Tue, 18 Dec 90 14:04:04 EST
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: Thinking Machines reception during the next NCEG & X3J11 meeting
Date: Thu, 18 Oct 90 14:44:28 EDT
From: [email protected]
...
25-Dec-90 04:21:38-PST,1634;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 25 Dec 90 04:21:34 PST
Received: from relay2.cs.net by RELAY.CS.NET id aj06692; 25 Dec 90 7:20 EST
Date: Tue, 25 Dec 90 7:13:14 EST
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa05158)
To: [email protected]
After 5 days (99 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa05158; 21 Dec 90 3:00 EST
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:22 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20282; Thu, 20 Dec 90 17:57:15 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00202; Thu, 20 Dec 90 17:51:23 EST
Date: Thu, 20 Dec 90 17:51:23 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 18:53:41 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
...
25-Dec-90 04:22:56-PST,1635;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 25 Dec 90 04:22:54 PST
Received: from relay2.cs.net by RELAY.CS.NET id ba06692; 25 Dec 90 7:21 EST
Date: Tue, 25 Dec 90 7:15:37 EST
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa05080)
To: [email protected]
After 5 days (100 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa05080; 21 Dec 90 2:44 EST
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:21 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20100; Thu, 20 Dec 90 17:57:06 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00182; Thu, 20 Dec 90 17:51:16 EST
Date: Thu, 20 Dec 90 17:51:16 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 16:45:57 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
...
25-Dec-90 04:46:25-PST,1634;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 25 Dec 90 04:46:23 PST
Received: from relay2.cs.net by RELAY.CS.NET id ah06979; 25 Dec 90 7:45 EST
Date: Tue, 25 Dec 90 7:33:11 EST
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa05096)
To: [email protected]
After 5 days (99 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa05096; 21 Dec 90 2:51 EST
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:26 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20195; Thu, 20 Dec 90 17:57:10 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00192; Thu, 20 Dec 90 17:51:21 EST
Date: Thu, 20 Dec 90 17:51:21 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 17:51:04 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
...
25-Dec-90 04:46:51-PST,1635;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 25 Dec 90 04:46:48 PST
Received: from relay2.cs.net by RELAY.CS.NET id am06979; 25 Dec 90 7:46 EST
Date: Tue, 25 Dec 90 7:33:54 EST
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa05043)
To: [email protected]
After 5 days (100 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa05043; 21 Dec 90 2:36 EST
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:20 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20336; Thu, 20 Dec 90 17:57:18 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00212; Thu, 20 Dec 90 17:51:25 EST
Date: Thu, 20 Dec 90 17:51:25 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Tue Dec 18 19:15:47 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
...
25-Dec-90 04:49:05-PST,1969;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 25 Dec 90 04:49:02 PST
Received: from relay2.cs.net by RELAY.CS.NET id an06996; 25 Dec 90 7:47 EST
Date: Tue, 25 Dec 90 7:36:32 EST
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Failed mail (msg.ac02788)
To: [email protected]
After 7 days (154 hours), your message could not be
fully delivered.
It failed to be received by the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message follows:
Received: from [192.67.67.20] by RELAY.CS.NET id ac02788; 18 Dec 90 20:39 EST
Received: from mail.think.com by NIC.DDN.MIL with TCP; Tue, 18 Dec 90 11:04:40 PST
Return-Path: <[email protected]>
Received: from Wotan.Think.COM by mail.think.com; Tue, 18 Dec 90 14:04:31 -0500
Received: by wotan.think.com (4.0/Think-1.0C)
id AA26485; Tue, 18 Dec 90 14:04:04 EST
Date: Tue, 18 Dec 90 14:04:04 EST
From: [email protected]
Message-Id: <[email protected]>
To: [email protected]
Subject: Thinking Machines reception during the next NCEG & X3J11 meeting
Date: Thu, 18 Oct 90 14:44:28 EDT
From: [email protected]
Thinking Machines Corporation is pleased to host a reception for NCEG
and X3J11 participants on the evening on Tuesday, March 5, 1991 with
food and refreshments at our site in Cambridge. NCEG and X3J11 delegates
interested in seeing TMC's Connection Machines, applications, parallel
languages, and enjoying superb food should plan to spend Tuesday night
at Thinking Machines. TMC is happy to supply transportation from/to the
meeting/hotel site. Busses will be leaving for Thinking Machines
from the hotel at approximately 6:30 PM.
Jamie Frankel
25-Dec-90 04:50:30-PST,1634;000000000000
Return-Path: <[email protected]>
Received: from RELAY.CS.NET by NIC.DDN.MIL with TCP; Tue, 25 Dec 90 04:50:28 PST
Received: from relay2.cs.net by RELAY.CS.NET id bl06992; 25 Dec 90 7:49 EST
Date: Tue, 25 Dec 90 7:39:00 EST
From: RELAY Mail System (MMDF) <[email protected]>
Sender: [email protected]
Subject: Waiting mail (msg.aa05284)
To: [email protected]
After 5 days (99 hours), your message has not yet been
fully delivered. Attempts to deliver the message will continue
for 2 more days. No further action is required by you.
Delivery attempts are still pending for the following address(es):
@ncr.com:[email protected] (host: ncr.com) (queue: ncr)
Problems usually are due to service interruptions at the receiving
machine. Less often, they are caused by the communication system.
Your message begins as follows:
Received: from [192.67.67.20] by RELAY.CS.NET id aa05284; 21 Dec 90 3:14 EST
Received: from uunet.UU.NET by NIC.DDN.MIL with TCP; Thu, 20 Dec 90 14:57:33 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA20388; Thu, 20 Dec 90 17:57:21 -0500
Received: by plumhall.UUCP (5.51/smail2.2/06-30-87)
id AA00222; Thu, 20 Dec 90 17:51:28 EST
Date: Thu, 20 Dec 90 17:51:28 EST
From: [email protected] (Thomas Plum)
Message-Id: <[email protected]>
To: [email protected]
Subject: Req Interp
>From ibminet.awdpa.ibm.com!ibmpa!tydeman Wed Dec 19 18:40:52 1990 remote from uunet
Received: from ibminet.awdpa.ibm.com by uunet.uu.net (5.61/1.14) with SMTP
...
7-Jan-91 06:21:46-PST,17138;000000000000
Return-Path: <[email protected]>
Received: from mail.think.com by NIC.DDN.MIL with TCP; Mon, 7 Jan 91 06:21:19 PST
Return-Path: <[email protected]>
Received: from Think.COM by mail.think.com; Mon, 7 Jan 91 09:21:49 -0500
Received: from compass.UUCP by Early-Bird.Think.COM; Mon, 7 Jan 91 09:21:46 EST
Received: from senduleak by compass with SMTP id AA12845
(5.65+/IDA-1.3.5 for [email protected]); Mon, 7 Jan 91 08:40:30 -0500
Received: by senduleak.compass.com (4.0/SMI-4.0)
id AA15971; Mon, 7 Jan 91 08:40:29 EST
Date: Mon, 7 Jan 91 08:40:29 EST
From: [email protected] (Ian Wells)
Message-Id: <[email protected]>
To: [email protected]
Subject: from numeric list
Return-Path: <think!sun!uunet.UU.NET!ibmsupt!ibmpa!tydeman%uunet.UU.NET@compass>
Date: Fri, 4 Jan 91 07:45:54 -0800
From: [email protected] (Fred Tydeman)
To: [email protected]
Subject: Numeric related Request For Interpretations to ANSI C
The following are numeric related ANSI C issues that have been
submitted to ANSI C for official interpretations that may be of
interest to this mailing list.
----------------------------------------------------------------------
Subject: Formal Request For Interpretation Number 2
What is the result of: strtod( "100ergs", &ptr);? Is it 100.0 or is
it 0.0?
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 151, lines
36-38: 'The subject sequence is defined as the longest initial
subsequence of the input string, starting with the first
non-white-space character, that is of the expected form.' In this
case, the longest initial subsequence of the expected form is "100",
so 100.0 should be the return value. Also, since the entire string is
in memory, strtod can scan it as many times as need be to find the
longest valid initial subsequence.
ANSI C X3.159-1989, 4.9.6.2 The fscanf Function, page 137, lines
17-18: 'e,f,g Matches an optionally signed floating-point number,
whose format is the same as expected for the subject string of the
strtod function.' Later, page 139, lines 6, 16, and 25 show that
'100ergs' fails to match "%f". Those two show that '100ergs' is
invalid to fscanf and therefore, invalid to strtod. Then, page 152,
lines 11-12 'If no conversion could be performed, zero is returned'
indicates for an error input, 0.0 should be returned. The reason this
is invalid is spelled out in the Rationale, 4.9.6.2 The fscanf
function, page 95, 'One-character pushback is sufficient for the
implementation of fscanf. Given the invalid field "-.x", the
characters "-." are not pushed back.' And later, 'The conversions
performed by fscanf are compatible with those performed by strtod and
strtol.'
So, do strtod and fscanf act alike and both accept and fail on the
same inputs, by the one-character pushback scanning strategy, or do
they use different scanning strategies and strtod accept more than
fscanf?
----------------------------------------------------------------------
Subject: Formal Request For Interpretation Number 3
Assuming that 99999 is larger than DBL_MAX_10_EXP, what is the result
of: strtod( "0.0e99999", &ptr);? Is it 0.0, HUGE_VAL, or undefined?
ANSI C X3.159-1989, 3.1.3.1 Floating Constants, page 27, lines 30-32:
'The significand part is interpreted as a decimal rational number; the
digit sequence in the exponent part is interpreted as a decimal
integer. The exponent indicates the power of 10 by which the
significand part is to be scaled.' In this case 0.0e99999 means 0.0
times 10 to the power 99999, or 0.0 * 10 ** 99999, which has a scaled
value of 0.0; therefore, return 0.0
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, lines
12-14: 'If the correct value is outside the range of representable
values, plus or minus HUGE_VAL is returned (according to the sign of
the value), and the value of the macro ERANGE is stored in errno'.
Since the exponent (99999 in this case) is larger than DBL_MAX_10_EXP,
the value if outside the range of representable values (overflow).
Therefore, return HUGE_VAL.
ANSI C X3.159-1989, 2.2.4.2.2 Characteristics of Floating Types
<float.h>, pages 15 and 16, describe the model that defines the
floating-point types. The number 0.0e99999, as written, is not part
of that model (it cannot be represented since the exponent is larger
than e-max). From 3.2.1.4 Floating Types, page 36, lines 11-13,
'...if the value being converted is outside the range of values that
can be represented, the behavior is undefined.' Therefore, since this
number, as written, has no representation, the behavior is undefined.
----------------------------------------------------------------------
Subject: Formal Request For Interpretation Number 4
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, line 5:
What does '"C" locale' mean?
a) setlocale(LC_ALL,NULL) == "C"
b) setlocale(LC_NUMERIC,NULL) == "C"
c) a) && b)
d) a) || b)
e) something else.
What does 'other than the "C" locale' mean?
a) setlocale(LC_ALL,NULL) != "C"
b) setlocale(LC_NUMERIC,NULL) != "C"
c) a) && b)
d) a) || b)
e) something else.
Section 4.4.1 Locale Control, page 108 may help answer the questions.
----------------------------------------------------------------------
Subject: Formal Request For Interpretation Number 5
What is meant by 'representable floating-point value'? Assume double
precision, unless stated otherwise.
First, some definitions based partially upon the floating-point model
on pages 15-16 of ANSI C X3.159-1989:
1) +Normal Numbers: DBL_MIN to DBL_MAX, inclusive; normalized (first
significand digit is non-zero), sign is +1.
2) -Normal Numbers: -DBL_MAX to -DBL_MIN, inclusive; normalized.
3) +Zero: All digits zero, sign is +1; (true zero).
4) -Zero: All digits zero, sign is -1.
5) Zero: Union of +zero and -zero.
6) +Denormals: Exponent is "minimum" (Biased exponent is zero);
first significand digit is zero; sign is +1. These are in range
+DBL_DeN (inclusive) to +DBL_MIN (exclusive). Let DBL_DeN be the
symbol for the minimum denormal, so we can talk about it by name.
7) -Denormals: Same as +denormals, except sign, and range is
-DBL_MIN (exclusive) to -DBL_DeN (inclusive).
8) +Unnormals: Biased exponent is non-zero; first significand digit
is zero; sign is +1. These overlap the range of +normals and
+denormals.
9) -Unnormals: Same as +unnormals, except sign; range is over
-normals and -denormals.
10) +infinity: From IEEE-754.
11) -infinity: From IEEE-754.
12) Quiet NaN (Not a Number); sign does not matter; from IEEE-754.
13) Signaling NaN; sign does not matter; from IEEE-754.
14) NaN: Union of Quiet NaN and Signaling NaN.
15) Others: Reserved (VAX?) and Indefinite (CDC/Cray?) act like NaN.
On the real number line, these symbols order as:
[ 1 )[ 2 ]( 3 ]( 4 )[ 5 ]( 6 )[ 7 )[ 8 ]( 9 ]
+------+--------+--------+-----+---+-----+--------+--------+------+
-INF -DBL_MAX -DBL_MIN -DBL_DeN -0 +0 +DBL_DeN +DBL_MIN +DBL_MAX +INF
Non-real numbers are: SNaN, QNaN, and NaN, call this region 10.
Regions 1 and 9 are overflow, 2 and 8 are normal numbers, 3 and 7 are
denormal numbers (psuedo underflow), 4 and 6 are true underflow, and 5
is zero.
So, the question is: What does 'representable (double precision)
floating-point value' mean:
a) Regions 2, 5 and 8 (+/- normals and zero)
b) Regions 2, 3, 5, 7, and 8 (+/- normals, denormals, and zero)
c) Regions 2 through 8 [-DBL_MAX ... +DBL_MAX]
d) Regions 1 through 9 [-INF ... +INF]
e) Regions 1 through 10 (reals and non-reals)
f) What the hardware can represent
g) Something else? What?
Some things to consider in your answer follow. The questions that
follow are rhetorical and do not need answers.
ANSI C X3.159-1989, 2.2.4.2.2 Characteristics of Floating Types
<float.h>, page 15, lines 32-35, 'The characteristics of floating
types are defined in terms of a model that describes a representation
of floating-point numbers and values that provide information about an
implementation's floating-point arithmetic.' Same section, page 16
line 6, 'A normalized floating-point number x ... is defined by the
following model ...'.
That model is just normalized numbers and zero (appears to include
signed zeros). It excludes denormal and unnormal numbers,
infinities, and NaNs. Are signed zeros required, or just allowed?
ANSI C X3.159-1989, 3.1.3.1 Floating Constants, page 27, lines 32-35,
'If the scaled value is in the range of representable values (for its
type) the result is either the nearest representable value, or the
larger or smaller representable value immediately adjacent to the
nearest value, chosen in an implementation-defined manner.'
------+-----+------+--------+----...----+-----+---
A B y C x D E z F
-DBL_Den 0.0 +DBL_Den +DBL_MIN ... DBL_MAX INF
The representable numbers are A,B,C,D,E and F. The number x can be
converted to B, C, or D! But what if B is zero, C is DBL_DeN
(denormal), and D is DBL_MIN (normalized). Is x representable?
It is not in the range DBL_MIN...DBL_MAX and its inverse causes
overflow; so those say not valid. On the other hand, it is in the
range DBL_DeN...DBL_MAX and it does not cause underflow; so those
say it is valid.
What if B is zero, A is -DBL_DeN (denormal), and C is +DBL_DeN
(denormal). Is y representable? If so, its nearest value is
zero, and the immediately adjacent values include a positive and a
negative number. So a user written positive is allowed to end up
with a negative value!
What if E is DBL_MAX and F is infinity (on a machine that uses
infinities, IEEE-754)? Does z have a representation? If z came
from 1.0/x, then z caused overflow which says invalid. But on
IEEE-754 machines, it would either be DBL_MAX or infinity
depending upon the rounding control, so it has a representation
and is valid.
What is nearest? In linear or logarithmic sense? If the number
is between 0 and DBL_DeN, 1e-9999999 is linear nearest to zero,
but log nearest to DBL_DeN. If number is between DBL_MAX and INF,
1e+999999 is linear and log nearest to DBL_MAX. Or is everything
bigger than DBL_MAX nearest to INF?
ANSI C X3.159-1989, 3.2.1.3 Floating and Integral, page 36, footnote
29, 'Thus, the range of portable floating values is (-1,Utype_MAX+1).'
ANSI C X3.159-1989, 3.2.1.4 Floating Types, page 36, lines 11-15,
'When a double is demoted to float or a long double to double or
float, if the value being converted is outside the range of values
that can be represented, the behavior is undefined. If the value
being converted is in the range of values that can be represented but
cannot be represented exactly, the result is either the nearest higher
or nearest lower value, chosen in an implementation-defined manner.'
ANSI C X3.159-1989, 3.3 Expressions, page 39, lines 15-17, 'If an
exception occurs during the evaluation of an expression (that is, if
the result is not mathematically defined or not in the range of
representable values for its type), the behavior is undefined.'
w = 1.0 / 0.0 ; /* infinity in IEEE-754 */
x = 0.0 / 0.0 ; /* NaN in IEEE-754 */
y = +0.0 ; /* plus zero */
z = - y ; /* minus zero: Must this be -0.0? May it be +0.0? */
Are the above representable?
ANSI C X3.159-1989, 4.5.1 Treatment of Error Conditions, page 112,
lines 11-12, 'The behavior of each of these functions is defined for
all representable values of its input arguments.'
What about non-numbers? Are they representable? What is
sin(NaN);? If you got a NaN as input, then you can return NaN as
output. But, is it a domain error? Must errno be set to EDOM?
The NaN already indicates an error, so setting errno adds no more
information. Assuming NaN is not part of ANSI C representable,
but the hardware supports it, then using NaNs is an extension of
ANSI C and setting errno need not be required, but is allowed.
Correct?
ANSI C X3.159-1989, 4.5.1 Treatment of Error Conditions, page 112,
lines 20-27, 'Similarly, a range error occurs if the result of the
function cannot be represented as a double value. If the result
overflows (the magnitude of the result is so large that it cannot be
represented in an object of the specified type), the function returns
the value of the macro HUGE_VAL, with the same sign (except for the
tan function) as the correct value of the function; the value of the
macro ERANGE is stored in errno. If the result underflows (the
magnitude of the result is so small that it cannot be represented in
an object of the specified type), the function returns zero; whether
the integer expression errno acquires the value of the macro ERANGE is
implementation-defined.'
What about denormal numbers? What is sin(DBL_MIN / 3.0L);? Must
this be considered underflow and therefore return zero, and maybe
set errno to ERANGE? Or may it return DBL_MIN / 3.0, a denormal
number? Assuming denormals are not part of ANSI C representable,
but the hardware supports it, then using them is an extension of
ANSI C and setting errno need not be required, but is allowed.
Correct?
What about infinity? What is exp(INF);? If you got an INF as
input, then you can return INF as output. But, is it a range
error? The output value is representable, so that says no error.
The output value is bigger than DBL_MAX, so that says an error and
set errno to ERANGE. Assuming infinity is not part of ANSI C
representable, but the hardware supports it, then using INFs is an
extension of ANSI C and setting errno need not be required, but is
allowed. Correct?
What about signed zeros? What is sin(-0.0);? Must this return
-0.0? May it return -0.0? May it return +0.0? Signed zeros
appear to be required in the model on page 16.
What is sqrt(-0.0);? IEEE-754 and IEEE-854 (floating-point
standards) say this must be -0. Is -0.0 negative? Is this a
domain error?
ANSI C X3.159-1989, 4.9.6.1 The fprintf Function, page 133, lines
32-33, '(It will begin with a sign only when a negative value is
converted if this flag is not specified.)'
What is fprintf(stdout, "%+.1f", -0.0);? Must it be -0.0? May it
be +0.0? Is -0.0 a negative value? The model on page 16 appears
to require support for signed zeros.
What is fprintf(stdout, "%f %f", 1.0/0.0, 0.0/0.0);? May it be
the IEEE-854 strings of 'inf' or 'infinity' for the infinity and
'NaN' the quiet NaN? Would 'NaNQ' also be allowed for a quiet
NaN? Would 'NaNS' be allowed for a signaling NaN? Must the sign
be printed? Signs are optional in IEEE-754 and IEEE-854. Or,
must it be some decimal notation as specified by page 134, line
19. Does the locale matter?
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, lines 1-2,
'If the subject sequence begins with a minus sign, the value resulting
from the conversion is negated.'
What is strtod("-0.0", &ptr);? Must it be -0.0? May it be +0.0?
The model on page 16 appears to require support for signed zeros.
All floating-point hardware I know about support signed zeros at
least at the load, store, and negate/complement instruction level.
ANSI C X3.159-1989, 4.10.1.4 The strtod Function, page 152, lines
12-15, 'If the correct value is outside the range of representable
values, plus or minus HUGE_VAL is returned (according to the sign of
the value), and the value of the macro ERANGE is stored in errno. If
the correct value would cause underflow, zero is returned and the
value of the macro ERANGE is stored in errno.'
If HUGE_VAL is +infinity, then is strtod("1e999999",&ptr); outside
the range of representable values and a range error? Or is it the
'nearest' of DBL_MAX and INF?
From: Fred Tydeman, IBM's NCEG representative
Mail Stop 35A
1510 Page Mill Road
Palo Alto, California 94304
Internet: [email protected]
UUCP: uunet!ibmsupt!tydeman
(415) 855-4430