Google
 

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: <mmdf@BRL.MIL>
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) <mmdf@BRL.MIL>
Sender:   mmdf@BRL.MIL
Subject:  Waiting mail  (msg.aa08384)
To:       x3j11-RELAY@sri-nic.arpa
Message-ID:  <8906152010.aa00234@SMOKE.BRL.MIL>

    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):

	gwyn@vgr.brl.mil (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 <KLH@SRI-NIC.ARPA>
Subject: Re: X3J11 mailing list.
To: keie@cs.vu.nl, x3j11@SRI-NIC.ARPA
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8906121601.aa09219@pequod.cs.vu.nl>
Message-ID: <12501595637.23.KLH@SRI-NIC.ARPA>

Hi... I'm not sure, but I'll check and let you know.
-------
...
15-Jun-89 17:57:37-PDT,1758;000000000000
Return-Path: <mmdf@BRL.MIL>
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) <mmdf@BRL.MIL>
Sender:   mmdf@BRL.MIL
Subject:  Waiting mail  (msg.aa06081)
To:       x3j11-RELAY@sri-nic.arpa
Message-ID:  <8906152010.ab00234@SMOKE.BRL.MIL>

    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):

	gwyn@vgr.brl.mil (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 <keie@cs.vu.nl>
To: x3j11@sri-nic.ARPA
Subject:  X3J11 mailing list.
Message-Id:  <8906121601.aa09219@pequod.cs.vu.nl>

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 <Mailer@SRI-NIC.ARPA>
To: x3j11-RELAY@SRI-NIC.ARPA
Subject: Message of 5-Jun-89 15:18:51

Message undeliverable and dequeued after 10 days:
Walter@HPDA.HP.COM: Cannot connect to host
alanf@SUN.COM: Cannot connect to host
cmeissen@SUN.COM: Cannot connect to host
eager@SUN.COM: Cannot connect to host
stellar!pete@UCBVAX.BERKELEY.EDU: 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: pete@stellar.COM (Peter Darnell @stellar)
Message-Id: <8906051917.AA02260@capricorn.stellar.COM>
To: Ken Harrenstien <ucbcad!SRI-NIC.ARPA!KLH@uunet.UU.NET>
Cc: x3j11@SRI-NIC.ARPA
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 <Mailer@SRI-NIC.ARPA>
To: X3J11-RELAY@SRI-NIC.ARPA
Subject: Message of 7-Jun-89 12:30:21

Message undeliverable and dequeued after 8 days:
davewe@MICROSOFT.UU.NET: 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: plumhall!plum@uunet.uu.net
Message-Id: <8906071930.AA26895@uunet.uu.net>
To: X3J11@SRI-NIC.ARPA
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 plum@PLUMHALL.UU.NET .
.IP o
If you have a new or changed net-address to report,
please send email to Ken Harrenstien, klh@SRI-NIC.ARPA .
.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 <Mailer@SRI-NIC.ARPA>
To: X3J11-RELAY@SRI-NIC.ARPA
Subject: Message of 10-Jun-89 18:47:09

Message undeliverable and dequeued after 5 days:
Walter@HPDA.HP.COM: 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: plumhall!root@uunet.uu.net
Message-Id: <8906110146.AA08395@uunet.uu.net>
To: voting@uunet.UU.NET
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 klh@SRI-NIC.ARPA
    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; rmeyers@dec-tle.dec.com 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; andyj@ENX.PRIME.COM P-J11
P359 Plauger, P J; 398 Main St; Concord, MA  01742; 508-369-8489; P-J11  
## -IS-      pjp@INMET.INMET.COM (?)
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;;   rgh@INMET.INMET.COM 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     ;   dfp@ATTUNIX.ATT.COM P-J11
5049 Plum, Thomas; Plum Hall; 1 Spruce Av; Cardiff, NJ  08232; 808-879-4449;
## EIS-     ;   plum@PLUMHALL.UU.NET P-J11
H383 Adamczyk, J Stephen  Edison Design Group; 907 Timber Oaks Rd; Edison, NJ  08820;
## --S-      201-769-8262;;   jsa@EDG1.UU.NET 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; gwyn@BRL.MIL P-J11
E235 Williams, James; Naval Research Laboratory; 55 Joyceton Wy; Upper Marlboro, MD  20772;
## E---      202-767-9035(w);;   williams@CSS.NRL.NAVY.MIL P-J11
B085 Jaeschke, Rex; DEC Professional; 1810 Michael Faraday Dr #101; Reston, VA  22090;
## E-S-     ;   703-860-0091; rex@AUSSIE.UU.NET P-J11
4226 Meissner, Michael; Data General; 62 Alexander Drive; Research Triangle, NC  22709;
## --S-     ;   919-248-6250; meissner@DG-RTP.DG.COM (?) 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; srd@PEORIA.CCUR.COM 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; mbennett@GOULD.UU.NET P-J11

------- OH -------
1333 Jones, Larry; SDRC; 2000 Eastman Dr; Milford, OH  45150; 513-576-2070;
## EIS-      scjones@SDRC.UU.NET 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;;   tam@CRAY.COM 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; linda@LLL-LCC.LLNL.GOV P-J11
K425 Rasbold, Chuck; Supercomputer Systems Inc; 1404 Concannon Blvd;
## EIS-      Livermore, CA  94550; 415-449-9392;;   rasbold@LLL-LLC.LLNL.GOV 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; eec1@APPLE.COM P-J11
N438 Murray, Walter J; Hewlett Packard; 19447 Pruneridge Av; Cupertino, CA  95014;
## EISX      408-447-6129;;   walter@HPDA.HP.COM P-J11
N871 Walcott, Zona; Pyramid Technology; 1295 Charleston Rd; POB 7295;
## EIS-      Mountain View, CA  94039;    415-965-7200; zona@PYRPS5.PYRAMID.COM P-J11P-J11
K375 Meissen, Courtney; Sun Microsystems; MS/1-40; 2550 Garcia Av; Mountain View, CA  94043;
## EISX     ;   415-336-7397; cmeissen@SUN.COM P-J11
B088 Weidenhofer, Neal; Amdahl; MS 316; 1250 E Arques; Sunnyvale, CA  94088;
## EIS-      408-737-5007;;   nw@UTS.AMDAHL.COM 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;;   davewe@MICROSOFT.UU.NET P-J11
K915 Sutton, Carl; Tektronix; POB 500  MS 19-333; Beaverton, OR  97077;
## ----      503-627-7111;;   sutton@TEKTRONIX.TEK.COM P-J11
M708 Nelson, Clark; Intel; 5200 Elam Young Pkwy MS HF280; Hillsboro, OR  97124;
## EIS-     ;   503-681-2018; clark@LANGLAB1.HF.INTEL.COM P-J11
N403 Ryan, Ralph; Chiron Systems; 14486 NE 58 St; Bellevue, WA  98007;
## EIS-      206-869-0141(W); c-ralphr@MICROSOFT.UU.NET 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; elliott@IBM.COM 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; fwc@WATCSG.BITNET P-J11

-------
16-Jun-89 13:14:38-PDT,667;000000000000
Date: Fri, 16 Jun 89 13:06:02 PDT
From: The Mailer Daemon <Mailer@SRI-NIC.ARPA>
To: X3J11-RELAY@SRI-NIC.ARPA
Subject: Message of 10-Jun-89 20:09:29

Message undeliverable and dequeued after 5 days:
Walter@HPDA.HP.COM: 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: plumhall!root@uunet.uu.net
Message-Id: <8906110309.AA00969@uunet.uu.net>
To: X3J11@SRI-NIC.ARPA, eec1@apple.com, pete@stellar.com
Date: Sat Jun 10 22:52:46 1989

	Welcome to XENIX!

-------
16-Jun-89 20:23:44-PDT,765;000000000000
Return-Path: <plumhall!root@uunet.UU.NET>
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: plumhall!root@uunet.UU.NET
Message-Id: <8906160011.AA27966@uunet.uu.net>
To: X3J11-REQUEST@SRI-NIC.ARPA
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 jbb@tekirl.labs.tek.com
Carl Sutton  sutton@pyrps5.pyramid.com

Thanks for the careful work.


Thomas Plum  609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum  OR  plum@PLUMHALL.UU.NET

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 <Mailer@SRI-NIC.ARPA>
To: x3j11-RELAY@SRI-NIC.ARPA
Subject: Message of 12-Jun-89 09:51:34

Message undeliverable and dequeued after 6 days:
Walter@HPDA.HP.COM: 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 <keie@cs.vu.nl>
To: x3j11@sri-nic.ARPA
Subject:  X3J11 mailing list.
Message-Id:  <8906121601.aa09219@pequod.cs.vu.nl>

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 <Mailer@SRI-NIC.ARPA>
To: x3j11-RELAY@SRI-NIC.ARPA
Subject: Message of 12-Jun-89 12:27:28

Message undeliverable and dequeued after 5 days:
Walter@HPDA.HP.COM: Cannot connect to host
	    ------------
Date: Mon, 12 Jun 89 12:15:53 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: X3J11 mailing list.
To: keie@cs.vu.nl, x3j11@SRI-NIC.ARPA
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8906121601.aa09219@pequod.cs.vu.nl>
Message-ID: <12501595637.23.KLH@SRI-NIC.ARPA>

Hi... I'm not sure, but I'll check and let you know.
-------
-------
22-Jun-89 10:51:01-PDT,1141;000000000000
Return-Path: <eager@Sun.COM>
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: eager@Sun.COM (Mike Eager)
Message-Id: <8906221746.AA15420@ringworld.sun.com>
To: ALLANV@cc.usu.edu, KLH@SRI-NIC.ARPA, X3J11-RELAY@SRI-NIC.ARPA, aj@Sun.COM,
        att!houxs!rmk@Sun.COM, attunix!houxs!elh@Sun.COM,
        attunix!houxs!wgt@Sun.COM, aussie!rex@uunet.UU.NET, birss@Sun.COM,
        bwc@Sun.COM, damico@Sun.COM, netcom!eager@Sun.COM, eager@Sun.COM,
        gingerf@Sun.COM, hpda!kerschen@Sun.COM, mhelft@Sun.COM, scei@Sun.COM,
        tchaparala@Sun.COM, toy@Sun.COM

Change of address:
	Michael J. Eager
	Eager Consulting
	481 Century Drive
	Campbell, CA 95008
	(408) 378-8820

UUCP:	eager@netcom.UUCP	<=== 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 <Mailer@SRI-NIC.ARPA>
To: X3J11-RELAY@SRI-NIC.ARPA
Subject: Message of 16-Jun-89 13:54:52

Message undeliverable and dequeued after 7 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: plumhall!root@uunet.UU.NET
Message-Id: <8906152048.AA13949@uunet.uu.net>
To: x3j11@uunet.UU.NET
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: <mmdf@BRL.MIL>
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) <mmdf@BRL.MIL>
Sender:   mmdf@BRL.MIL
Subject:  Failed mail  (msg.aa08384)
To:       x3j11-RELAY@sri-nic.arpa
Message-ID:  <8906232010.ae08388@SMOKE.BRL.MIL>

    After 11 days (262 hours), your message could not be
fully delivered.

    It failed to be received by the following address(es):

	gwyn@vgr.brl.mil (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 <KLH@SRI-NIC.ARPA>
Subject: Re: X3J11 mailing list.
To: keie@cs.vu.nl, x3j11@SRI-NIC.ARPA
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8906121601.aa09219@pequod.cs.vu.nl>
Message-ID: <12501595637.23.KLH@SRI-NIC.ARPA>

Hi... I'm not sure, but I'll check and let you know.
-------
23-Jun-89 18:37:39-PDT,1796;000000000000
Return-Path: <mmdf@BRL.MIL>
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) <mmdf@BRL.MIL>
Sender:   mmdf@BRL.MIL
Subject:  Failed mail  (msg.aa06081)
To:       x3j11-RELAY@sri-nic.arpa
Message-ID:  <8906232011.at08388@SMOKE.BRL.MIL>

    After 12 days (265 hours), your message could not be
fully delivered.

    It failed to be received by the following address(es):

	gwyn@vgr.brl.mil (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 <keie@cs.vu.nl>
To: x3j11@sri-nic.ARPA
Subject:  X3J11 mailing list.
Message-Id:  <8906121601.aa09219@pequod.cs.vu.nl>

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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <8907050231.AA26469@Sun.COM>
To: <X3J11-RELAY@SRI-NIC.ARPA>

   ----- 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: plumhall!plum@uunet.uu.net
Message-Id: <8907050202.AA02085@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <8907050247.AA26686@Sun.COM>
To: <X3J11-RELAY@SRI-NIC.ARPA>

   ----- 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: plumhall!plum@uunet.uu.net
Message-Id: <8907050204.AA03144@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

 5-Jul-89 09:59:50-PDT,3830;000000000000
Return-Path: <intelhf!medusa!intelhf!uucp%ihf1.intel.com@RELAY.CS.NET>
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: intelhf!medusa!intelhf!uucp@ihf1.intel.com
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
 <m0fcorE-0004GvC@ihf1.intel.com>; 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
 <m0fVD8T-000BR9C@medusa.intel.com>; 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%sc.intel.com@RELAY.CS.NET
Subject: OpenNET mail delivery problem
To: sri-nic.arpa!X3J11-RELAY%medusa.intel.com@RELAY.CS.NET
Message-Id: <8906071713.AA21577@intelhf.hf.intel.com>

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 <m0fVD1k-000BR9C@medusa.intel.com>; Wed, 7 Jun 89 17:13 PDT
Return-path: X3J11-RELAY%sri-nic.arpa@relay.cs.net
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%uunet.uu.NET@relay.cs.net
Subject: 89-051
To: X3J11@sri-nic.arpa
Message-Id: <8906071930.AA26895@uunet.uu.net>

..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 plum@PLUMHALL.UU.NET .
..IP o
If you have a new or changed net-address to report,
please send email to Ken Harrenstien, klh@SRI-NIC.ARPA .
..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%ihf1.intel.com@RELAY.CS.NET>
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: intelhf!medusa!intelhf!root@ihf1.intel.com
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
 <m0fcorH-0004GwC@ihf1.intel.com>; 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
 <m0fXv7d-000BTCC@medusa.intel.com>; 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%medusa.intel.com@RELAY.CS.NET
Subject: SWCAD netmail delivery problem
To: sri-nic.arpa!X3J11-RELAY%medusa.intel.com@RELAY.CS.NET
Message-Id: <8906150440.AA07782@intelhf.hf.intel.com>

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 <m0fXY0F-000BatC@medusa.intel.com>; Wed, 14 Jun 89 04:02 PDT
Return-path: X3J11-RELAY%sri-nic.arpa@relay.cs.net
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%uunet.uu.NET@relay.cs.net
Subject: 89-052
To: voting%uunet.UU.NET@relay.cs.net
Message-Id: <8906110146.AA08395@uunet.uu.net>

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 klh@SRI-NIC.ARPA
    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; rmeyers@dec-tle.dec.com 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; andyj@ENX.PRIME.COM P-J11
P359 Plauger, P J; 398 Main St; Concord, MA  01742; 508-369-8489; P-J11  
## -IS-      pjp@INMET.INMET.COM (?)
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;;   rgh@INMET.INMET.COM 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     ;   dfp@ATTUNIX.ATT.COM P-J11
5049 Plum, Thomas; Plum Hall; 1 Spruce Av; Cardiff, NJ  08232; 808-879-4449;
## EIS-     ;   plum@PLUMHALL.UU.NET P-J11
H383 Adamczyk, J Stephen  Edison Design Group; 907 Timber Oaks Rd; Edison, NJ  08820;
## --S-      201-769-8262;;   jsa@EDG1.UU.NET 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; gwyn@BRL.MIL P-J11
E235 Williams, James; Naval Research Laboratory; 55 Joyceton Wy; Upper Marlboro, MD  20772;
## E---      202-767-9035(w);;   williams@CSS.NRL.NAVY.MIL P-J11
B085 Jaeschke, Rex; DEC Professional; 1810 Michael Faraday Dr #101; Reston, VA  22090;
## E-S-     ;   703-860-0091; rex@AUSSIE.UU.NET P-J11
4226 Meissner, Michael; Data General; 62 Alexander Drive; Research Triangle, NC  22709;
## --S-     ;   919-248-6250; meissner@DG-RTP.DG.COM (?) 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; srd@PEORIA.CCUR.COM 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; mbennett@GOULD.UU.NET P-J11

------- OH -------
1333 Jones, Larry; SDRC; 2000 Eastman Dr; Milford, OH  45150; 513-576-2070;
## EIS-      scjones@SDRC.UU.NET 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;;   tam@CRAY.COM 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; linda@LLL-LCC.LLNL.GOV P-J11
K425 Rasbold, Chuck; Supercomputer Systems Inc; 1404 Concannon Blvd;
## EIS-      Livermore, CA  94550; 415-449-9392;;   rasbold@LLL-LLC.LLNL.GOV 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; eec1@APPLE.COM P-J11
N438 Murray, Walter J; Hewlett Packard; 19447 Pruneridge Av; Cupertino, CA  95014;
## EISX      408-447-6129;;   walter@HPDA.HP.COM P-J11
N871 Walcott, Zona; Pyramid Technology; 1295 Charleston Rd; POB 7295;
## EIS-      Mountain View, CA  94039;    415-965-7200; zona@PYRPS5.PYRAMID.COM P-J11P-J11
K375 Meissen, Courtney; Sun Microsystems; MS/1-40; 2550 Garcia Av; Mountain View, CA  94043;
## EISX     ;   415-336-7397; cmeissen@SUN.COM P-J11
B088 Weidenhofer, Neal; Amdahl; MS 316; 1250 E Arques; Sunnyvale, CA  94088;
## EIS-      408-737-5007;;   nw@UTS.AMDAHL.COM 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;;   davewe@MICROSOFT.UU.NET P-J11
K915 Sutton, Carl; Tektronix; POB 500  MS 19-333; Beaverton, OR  97077;
## ----      503-627-7111;;   sutton@TEKTRONIX.TEK.COM P-J11
M708 Nelson, Clark; Intel; 5200 Elam Young Pkwy MS HF280; Hillsboro, OR  97124;
## EIS-     ;   503-681-2018; clark@LANGLAB1.HF.INTEL.COM P-J11
N403 Ryan, Ralph; Chiron Systems; 14486 NE 58 St; Bellevue, WA  98007;
## EIS-      206-869-0141(W); c-ralphr@MICROSOFT.UU.NET 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; elliott@IBM.COM 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; fwc@WATCSG.BITNET P-J11

 5-Jul-89 11:49:56-PDT,2202;000000000000
Return-Path: <intelhf!medusa!intelhf!root%ihf1.intel.com@RELAY.CS.NET>
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: intelhf!medusa!intelhf!root@ihf1.intel.com
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
 <m0fcp2f-0004GvC@ihf1.intel.com>; 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
 <m0fXvCI-000BTDC@medusa.intel.com>; 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%medusa.intel.com@RELAY.CS.NET
Subject: SWCAD netmail delivery problem
To: sri-nic.arpa!X3J11-RELAY%medusa.intel.com@RELAY.CS.NET
Message-Id: <8906150442.AA07805@intelhf.hf.intel.com>

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 <m0fXY2f-000BazC@medusa.intel.com>; Wed, 14 Jun 89 04:04 PDT
Return-path: X3J11-RELAY%sri-nic.arpa@relay.cs.net
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%uunet.uu.NET@relay.cs.net
To: X3J11@sri-nic.arpa, eec1%apple.COM@relay.cs.net,
 pete%stellar.COM@relay.cs.net
Message-Id: <8906110309.AA00969@uunet.uu.net>

	Welcome to XENIX!

 5-Jul-89 21:30:29-PDT,3720;000000000000
Return-Path: <aussie!rex@uunet.UU.NET>
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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Re: 89-057
Message-Id: <8907060009.0.UUL1.3#5077@aussie.UUCP>
To: aussie!SRI-NIC.ARPA!X3J11-RELAY@uunet.UU.NET
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: <plumhall!plum@uunet.UU.NET>
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: plumhall!plum@uunet.uu.net
Message-Id: <8907061101.AA06518@uunet.uu.net>
To: X3J11-REQUEST@SRI-NIC.ARPA
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: <8907052022.AA16269@uunet.uu.net>
>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: dfp@attunix.att.com@dpw.NYU.EDU
	Cc: yost@cmcl2.NYU.EDU
	Subject: Please take me off the X3J11 lists
	Reply-To: esquire!yost@cmcl2.NYU.EDU
	Date: Wed, 05 Jul 89 09:33:35 -0400
	From: yost@info8.NYU.EDU
	
	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: <medusa@intelhf.hf.intel.com>
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 <m0ffQGS-000BR8C@medusa.intel.com>; Wed, 5 Jul 89 21:23 PDT
Received: by intelhf.hf.intel.com (smail2.5s1); 5 Jul 89 21:24:26 PDT (Wed)
To: X3J11-RELAY@sri-nic.arpa
Subject: OpenNET mail delivery problem
Message-Id: <8907052124.AA18788@intelhf.hf.intel.com>
Date: 5 Jul 89 21:24:26 PDT (Wed)
From: intelhf_OpenNET_mailer@cse.ogc.edu

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 <m0ffQCs-000BR8C@medusa.intel.com>; Wed, 5 Jul 89 21:19 PDT
Return-path: X3J11-RELAY%sri-nic.arpa@relay.cs.net
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%uunet.uu.NET@relay.cs.net
Subject: 89-057
To: x3j11%uunet.UU.NET@relay.cs.net
Message-Id: <8907052020.AA16070@uunet.uu.net>

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  plum@PLUMHALL.UU.NET

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 <Mailer@SRI-NIC.ARPA>
To: X3J11-RELAY@SRI-NIC.ARPA
Subject: Message of 4-Jul-89 19:03:30

Message undeliverable and dequeued after 6 days:
keie@CS.VU.NL: Cannot connect to host
Walter@hpda.hp.com: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#Internet: Cannot connect to host
srd@PEORA.CCUR.COM: 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: plumhall!plum@uunet.uu.net
Message-Id: <8907050202.AA02085@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

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 <Mailer@SRI-NIC.ARPA>
To: X3J11-RELAY@SRI-NIC.ARPA
Subject: Message of 4-Jul-89 19:05:56

Message undeliverable and dequeued after 6 days:
keie@CS.VU.NL: Cannot connect to host
Walter@hpda.hp.com: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#Internet: Cannot connect to host
srd@PEORA.CCUR.COM: 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: plumhall!plum@uunet.uu.net
Message-Id: <8907050204.AA03144@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

-------
11-Jul-89 15:53:42-PDT,2066;000000000000
Date: Tue, 11 Jul 89 12:05:24 PDT
From: The Mailer Daemon <Mailer@SRI-NIC.ARPA>
To: X3J11-RELAY@SRI-NIC.ARPA
Subject: Message of 5-Jul-89 13:22:05

Message undeliverable and dequeued after 6 days:
tam@cray.com: Cannot connect to host
keie@CS.VU.NL: Cannot connect to host
vandepas@DEC-DECWET.DEC.COM: Cannot connect to host
rmeyers@DEC-TLE.DEC.COM: Cannot connect to host
bjork@DEC-TLE.DEC.COM: Cannot connect to host
Walter@hpda.hp.com: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#Internet: Cannot connect to host
srd@PEORA.CCUR.COM: 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: plumhall!root@uunet.uu.net
Message-Id: <8907052020.AA16070@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

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 <KLH@SRI-NIC.ARPA>
Subject: Re: delete Yost
To: plumhall!plum@uunet.UU.NET, X3J11-REQUEST@SRI-NIC.ARPA
cc: KLH@SRI-NIC.ARPA
In-Reply-To: <8907061101.AA06518@uunet.uu.net>
Message-ID: <12509592071.24.KLH@SRI-NIC.ARPA>

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 peyton@APOLLO.COM.

A few people are still failing to get their mail, e.g. keie@cs.vu.nl 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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8907150612.AB25501@Sun.COM>
To: <X3J11-RELAY@SRI-NIC.ARPA>

   ----- 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: plumhall!root@uunet.uu.net
Message-Id: <8907052020.AA16070@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

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: <ukc!root@uunet.UU.NET>
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: <8907150714.AA15435@uunet.uu.net>
To: x3j11-RELAY@sri-nic.ARPA
From: UKC FTP Daemon <FTP@ukc.ac.uk>
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%uk.co.bt.kyns@uk.co.bt.axion

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) <gwyn@mil.brl>
To: KLH@arpa.sri-nic
Cc: x3j11@arpa.sri-nic
Subject:  Re:  recursive main()? (and invisible prototype query)
Message-Id:  <8907150022.aa12869@VGR.BRL.MIL>
Sender: x3j11-RELAY@arpa.sri-nic

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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8907160828.AA12718@Sun.COM>
To: <x3j11-RELAY@SRI-NIC.ARPA>

   ----- 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 <KLH@SRI-NIC.ARPA>
Subject: [aussie!rex@uunet.UU.NET (Rex Jaeschke): Pls foreward to X3J11 dist list]
To: x3j11@SRI-NIC.ARPA
Message-Id: <12509590179.24.KLH@SRI-NIC.ARPA>

Forwarding at Rex's request:
                ---------------
Date: Wed, 12 Jul 89 16:01:25 EST
From: aussie!rex@uunet.UU.NET (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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8907160932.AA15256@Sun.COM>
To: <x3j11-RELAY@SRI-NIC.ARPA>

   ----- 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) <gwyn@BRL.MIL>
To: Ken Harrenstien <KLH@sri-nic.arpa>
Cc: x3j11@sri-nic.arpa
Subject:  Re:  [aussie!rex@uunet.UU.NET (Rex Jaeschke): Pls foreward to X3J11 dist list]
Message-Id:  <8907130357.aa02785@VGR.BRL.MIL>

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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8907180746.AD09528@Sun.COM>
To: <x3j11-RELAY@SRI-NIC.ARPA>

   ----- 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) <gwyn@BRL.MIL>
To: Ken Harrenstien <KLH@sri-nic.arpa>
Cc: x3j11@sri-nic.arpa
Subject:  Re:  recursive main()? (and invisible prototype query)
Message-Id:  <8907150022.aa12869@VGR.BRL.MIL>

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 <Mailer@SRI-NIC.ARPA>
To: x3j11-RELAY@SRI-NIC.ARPA
Subject: Message of 13-Jul-89 00:11:20

Message undeliverable and dequeued after 6 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#Internet: Cannot connect to host
	    ------------
Date: Thu, 13 Jul 89 00:11:12 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: [aussie!rex@uunet.UU.NET (Rex Jaeschke): Pls foreward to X3J11 dist list]
To: x3j11@SRI-NIC.ARPA
Message-ID: <12509590179.24.KLH@SRI-NIC.ARPA>

Forwarding at Rex's request:
                ---------------
Date: Wed, 12 Jul 89 16:01:25 EST
From: aussie!rex@uunet.UU.NET (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 <Mailer@SRI-NIC.ARPA>
To: x3j11-RELAY@SRI-NIC.ARPA
Subject: Message of 13-Jul-89 00:58:59

Message undeliverable and dequeued after 6 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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) <gwyn@BRL.MIL>
To:       Ken Harrenstien <KLH@sri-nic.arpa>
cc:       x3j11@sri-nic.arpa
Subject:  Re:  [aussie!rex@uunet.UU.NET (Rex Jaeschke): Pls foreward to X3J11 dist list]
Message-ID:  <8907130357.aa02785@VGR.BRL.MIL>

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 <Mailer@SRI-NIC.ARPA>
To: x3j11-RELAY@SRI-NIC.ARPA
Subject: Message of 13-Jul-89 06:47:11

Message undeliverable and dequeued after 5 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#Internet: Cannot connect to host
2bixler@SX1100.SP.UNISYS.COM: Cannot connect to host
sutton@TEKTRONIX.TEK.COM: Cannot connect to host
fwc%watcsg.bitnet@CUNYVM.CUNY.EDU: Cannot connect to host
bsiqa!neil@MCVAX.UU.NET: Cannot connect to host
ssiwest!ohair@LLL-LCC.UU.NET: Cannot connect to host
ames!oliveb!peritus!sassan@MIMSY.UU.NET: Cannot connect to host
	    ------------
Received: from arpa.att.com by SRI-NIC.ARPA with TCP; Thu, 13 Jul 89 06:46:28 PDT
From: dfp@attunix.att.com
Date: Thu, 13 Jul 89 09:36 EDT
To: x3j11@sri-nic.arpa
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 <Mailer@SRI-NIC.ARPA>
To: x3j11-RELAY@SRI-NIC.ARPA
Subject: Message of 13-Jul-89 14:03:28

Message undeliverable and dequeued after 5 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#Internet: Cannot connect to host
	    ------------
Date: Thu, 13 Jul 89 14:03:00 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Re: recursive main()? (and invisible prototype query)
To: x3j11@SRI-NIC.ARPA
cc: KLH@SRI-NIC.ARPA
In-Reply-To: Message from "dfp@attunix.att.com" of Thu, 13 Jul 89 06:55:05 PDT
Message-ID: <12509741602.24.KLH@SRI-NIC.ARPA>

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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8907200345.AB27378@Sun.COM>
To: <x3j11-RELAY@SRI-NIC.ARPA>

   ----- 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: <8907162319.AA19093@Sun.COM>
Received: from arpa.att.com by SRI-NIC.ARPA with TCP; Thu, 13 Jul 89 06:46:28 PDT
From: dfp@attunix.att.com
Date: Thu, 13 Jul 89 09:36 EDT
To: x3j11@sri-nic.arpa
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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8907200614.AA03406@Sun.COM>
To: <x3j11-RELAY@SRI-NIC.ARPA>

   ----- 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 <KLH@SRI-NIC.ARPA>
Subject: Re: recursive main()? (and invisible prototype query)
To: x3j11@SRI-NIC.ARPA
Cc: KLH@SRI-NIC.ARPA
In-Reply-To: Message from "dfp@attunix.att.com" of Thu, 13 Jul 89 06:55:05 PDT
Message-Id: <12509741602.24.KLH@SRI-NIC.ARPA>

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: <aussie!rex@uunet.UU.NET>
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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Re: recursive main()? (and invisible prototype query)
Message-Id: <8907212348.0.UUL1.3#5077@aussie.UUCP>
To: aussie!SRI-NIC.ARPA!x3j11-RELAY@uunet.UU.NET
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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8907240805.AA29585@Sun.COM>
To: <x3j11-RELAY@SRI-NIC.ARPA>

   ----- 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: <8907210804.AA23730@Sun.COM>
Received: from arpa.att.com by SRI-NIC.ARPA with TCP; Mon, 17 Jul 89 07:28:50 PDT
From: dfp@attunix.att.com
Date: Mon, 17 Jul 89 10:18 EDT
To: attunix!arpa!SRI-NIC.ARPA!KLH, x3j11@SRI-NIC.ARPA
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 <Mailer@SRI-NIC.ARPA>
To: x3j11-RELAY@SRI-NIC.ARPA
Subject: Message of 14-Jul-89 21:30:06

Message undeliverable and dequeued after 10 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM: Cannot connect to host
rgh@INMET.INMET.COM: 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) <gwyn@BRL.MIL>
To:       Ken Harrenstien <KLH@sri-nic.arpa>
cc:       x3j11@sri-nic.arpa
Subject:  Re:  recursive main()? (and invisible prototype query)
Message-ID:  <8907150022.aa12869@VGR.BRL.MIL>

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 <Mailer@SRI-NIC.ARPA>
To: x3j11-RELAY@SRI-NIC.ARPA
Subject: Message of 28-Jul-89 11:30:27

Message undeliverable and dequeued after 6 days:
dfp@attunix.att.com: Cannot connect to host
kordonov@attunix.att.com: Cannot connect to host
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
elliott@IBM.COM: Cannot connect to host
elliott@IBM.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#Internet: Cannot connect to host
alanf@sun.com: Cannot connect to host
cmeissen@sun.com: Cannot connect to host
eager@sun.com: Cannot connect to host
nw@UTS.AMDAHL.COM: Cannot connect to host
fwc%watcsg.bitnet@cunyvm.cuny.edu: Cannot connect to host
amdcad!sun0!sun4!fay@DECWRL.DEC.COM.#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: x3j11@SRI-NIC.ARPA
From: rns%se-sd.sandiego.ncr.com@RELAY.CS.NET
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 (rns@se-sd.sandiego.NCR.COM)
-------
 4-Aug-89 16:29:15-PDT,4627;000000000000
Date: Fri, 4 Aug 89 16:28:22 PDT
From: The Mailer Daemon <Mailer@SRI-NIC.ARPA>
To: X3J11-RELAY@SRI-NIC.ARPA
Subject: Message of 1-Aug-89 10:23:20

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... 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: plumhall!root@uunet.uu.net
Message-Id: <8908011705.AA28723@uunet.uu.net>
To: x3j11@uunet.UU.NET
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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 1-Aug-89 10:23:20

Message undeliverable and dequeued after 5 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: plumhall!root@uunet.uu.net
Message-Id: <8908011705.AA28723@uunet.uu.net>
To: x3j11@uunet.UU.NET
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:plumhall!root@uunet.UU.NET>
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: plumhall!root@uunet.UU.NET
Message-Id: <8908051226.AA19661@uunet.uu.net>
To: X3J11-REQUEST@SRI-NIC.ARPA
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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8908080354.AD17142@Sun.COM>
To: <X3J11-RELAY@SRI-NIC.ARPA>

   ----- 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: plumhall!root@uunet.uu.net
Message-Id: <8908011705.AA28723@uunet.uu.net>
To: x3j11@uunet.UU.NET
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 <Mailer@NIC.DDN.MIL>
To: x3j11-RELAY@NIC.DDN.MIL
Subject: Message of 9-Aug-89 17:41:18

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... 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: tam@hilbert.cray.com (Tom MacDonald)
Message-Id: <8908100040.AA05419@tmacd.cray.com>
To: x3j11@NIC.DDN.MIL
Subject: Supercomputing 89


			CALL FOR SPEAKERS

			     from

			Tom MacDonald
			Cray Research, Inc.
			1345 Northland Drive
			Mendota Heights, MN  55120
			(612) 681 - 5818
			tam@cray.com
			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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8908130323.AB12979@Sun.COM>
To: <x3j11-RELAY@NIC.DDN.MIL>

   ----- 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: tam@hilbert.cray.com (Tom MacDonald)
Message-Id: <8908100040.AA05419@tmacd.cray.com>
To: x3j11@NIC.DDN.MIL
Subject: Supercomputing 89


			CALL FOR SPEAKERS

			     from

			Tom MacDonald
			Cray Research, Inc.
			1345 Northland Drive
			Mendota Heights, MN  55120
			(612) 681 - 5818
			tam@cray.com
			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 <Mailer@NIC.DDN.MIL>
To: x3j11-RELAY@NIC.DDN.MIL
Subject: Message of 9-Aug-89 17:41:18

Message undeliverable and dequeued after 5 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: tam@hilbert.cray.com (Tom MacDonald)
Message-Id: <8908100040.AA05419@tmacd.cray.com>
To: x3j11@NIC.DDN.MIL
Subject: Supercomputing 89


			CALL FOR SPEAKERS

			     from

			Tom MacDonald
			Cray Research, Inc.
			1345 Northland Drive
			Mendota Heights, MN  55120
			(612) 681 - 5818
			tam@cray.com
			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: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8908151008.AA22926@decwrl.dec.com>
Received: from NIC.DDN.MIL by decwrl.dec.com (5.54.5/4.7.34)
	for x3j11-RELAY@nic.ddn.mil; id AA22926; Tue, 15 Aug 89 03:08:02 PDT
To: <x3j11-RELAY@nic.ddn.mil>

   ----- Transcript of session follows -----
>>> MAIL From:<x3j11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-decwet
554 <vandepas@DEC-DECWET.DEC.COM>... 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: tam@hilbert.cray.com (Tom MacDonald)
Message-Id: <8908100040.AA05419@tmacd.cray.com>
To: x3j11@NIC.DDN.MIL
Subject: Supercomputing 89


			CALL FOR SPEAKERS

			     from

			Tom MacDonald
			Cray Research, Inc.
			1345 Northland Drive
			Mendota Heights, MN  55120
			(612) 681 - 5818
			tam@cray.com
			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: <plumhall!plum@uunet.UU.NET>
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: plumhall!plum@uunet.uu.net
Message-Id: <8908181703.AA25702@uunet.uu.net>
To: X3J11-REQUEST@SRI-NIC.ARPA
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: <8908160014.AA27793@uunet.uu.net>
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 (rns@se-sd.sandiego.NCR.COM)

28-Aug-89 17:00:57-PDT,1490;000000000000
Date: Mon, 28 Aug 89 16:57:20 PDT
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 28-Aug-89 16:30:05

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... 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: plumhall!root@uunet.uu.net
Message-Id: <8908282329.AA23692@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

-------
28-Aug-89 17:48:04-PDT,1977;000000000000
Return-Path: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8908290046.AB28671@decwrl.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<X3J11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-decwet
554 <vandepas@DEC-DECWET.DEC.COM>... 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: plumhall!root@uunet.uu.net
Message-Id: <8908282329.AA23692@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

28-Aug-89 18:25:09-PDT,1994;000000000000
Return-Path: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8908290123.AA01838@decwrl.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<X3J11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-tle
554 <rmeyers@DEC-TLE.DEC.COM>,<bjork@DEC-TLE.DEC.COM>... 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: plumhall!root@uunet.uu.net
Message-Id: <8908282329.AA23692@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

29-Aug-89 12:53:48-PDT,2687;000000000000
Return-Path: <ukc!axion.bt.co.uk!bsiqa.uucp!bsiqa_mailer_daemon@uunet.UU.NET>
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: x3j11-relay@nic.ddn.mil
Subject: mail problem
From: bsiqa!bsiqa_mailer_daemon@uunet.UU.NET
Date: Tue, 29 Aug 89 14:40:54 GMT
Message-Id:  <8908291650.aa11858@zaphod.axion.bt.co.uk>

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: root@uucp.plumhall
Message-Id: <8908282329.AA23692@uunet.uu.net>
To: x3j11@net.uu.uunet
Subject: sad_news
Date: Mon Aug 28 19:22:22 1989
Sender: X3J11-RELAY@mil.ddn.nic

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  plum@PLUMHALL.UU.NET



 1-Sep-89 04:08:58-PDT,1849;000000000000
Return-Path: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8909011024.AB13199@Sun.COM>
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- 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: plumhall!root@uunet.uu.net
Message-Id: <8908282329.AA23692@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

 4-Sep-89 13:17:44-PDT,1687;000000000000
Date: Mon, 4 Sep 89 13:16:11 PDT
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 28-Aug-89 16:30:05

Message undeliverable and dequeued after 7 days:
keie@CS.VU.NL: Cannot connect to host
meissner@DG-RTP.DG.COM: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: plumhall!root@uunet.uu.net
Message-Id: <8908282329.AA23692@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

-------
 9-Sep-89 14:40:43-PDT,541;000000000000
Return-Path: <plumhall!root@uunet.UU.NET>
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: plumhall!root@uunet.UU.NET
Message-Id: <8909092127.AA13466@uunet.uu.net>
To: X3J11-REQUEST@SRI-NIC.ARPA
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: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8910140832.AA25615@decwrl.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<X3J11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-decwet
554 <vandepas@DEC-DECWET.DEC.COM>... 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: plumhall!root@uunet.uu.net
Message-Id: <8910131457.AA24041@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

14-Oct-89 01:31:58-PDT,2379;000000000000
Return-Path: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8910140833.AA25634@decwrl.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<X3J11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-tle
554 <rmeyers@DEC-TLE.DEC.COM>,<bjork@DEC-TLE.DEC.COM>... 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: plumhall!root@uunet.uu.net
Message-Id: <8910131457.AA24041@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

14-Oct-89 01:56:47-PDT,1875;000000000000
Date: Sat, 14 Oct 89 01:54:20 PDT
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 13-Oct-89 08:00:41

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... 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: plumhall!root@uunet.uu.net
Message-Id: <8910131457.AA24041@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

-------
14-Oct-89 03:24:27-PDT,2598;000000000000
Return-Path: <sae!MAILER-DAEMON@itd.nrl.navy.mil>
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: sae!MAILER-DAEMON@itd.nrl.navy.mil (Mail Delivery Subsystem)
Subject: Returned mail: Bad usage
Message-Id: <8910140929.AB16586@sae.com>
To: NIC.DDN.MIL!X3J11-RELAY@itd.nrl.navy.mil

   ----- 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: <8910131457.AA24041@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

14-Oct-89 03:24:31-PDT,2849;000000000000
Return-Path: <sae!callisto!MAILER-DAEMON@itd.nrl.navy.mil>
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: sae!callisto!MAILER-DAEMON@itd.nrl.navy.mil (Mail Delivery Subsystem)
Subject: Returned mail: Bad usage
Message-Id: <8910140929.AB08647@callisto.sae.com>
To: <NIC.DDN.MIL!X3J11-RELAY@itd.nrl.navy.mil>

   ----- 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: <8910131457.AA24041@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

17-Oct-89 16:50:07-PDT,2263;000000000000
Return-Path: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8910170854.AB13379@Sun.COM>
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- 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: plumhall!root@uunet.uu.net
Message-Id: <8910131457.AA24041@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

19-Oct-89 16:53:20-PDT,2025;000000000000
Date: Thu, 19 Oct 89 11:16:55 PDT
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 13-Oct-89 08:00:41

Message undeliverable and dequeued after 6 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: plumhall!root@uunet.uu.net
Message-Id: <8910131457.AA24041@uunet.uu.net>
To: x3j11@uunet.UU.NET
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  plum@PLUMHALL.UU.NET

-------
25-Oct-89 22:09:19-PDT,808;000000000000
Return-Path: <plumhall!root@uunet.UU.NET>
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: plumhall!root@uunet.uu.net
Message-Id: <8910260505.AA00667@uunet.uu.net>
To: X3J11-REQUEST@SRI-NIC.ARPA
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    jbb@tekirl.labs.tek.com
  Carl Sutton     sutton@pyrps5.pyramid.com
  Tom Pennello    sun!acad!metaware!tom
  Rick Schubert   rns@se-sd.sandiego.NCR.COM

This one is new:

  Walter Nielsen  wnielsen@sum.com

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: <andyj@osf.org>
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: <8910271436.AA22774@osf.osf.org>
To: X3J11-REQUEST@SRI-NIC.ARPA
Subject: Change to Mailing List
Date: Fri, 27 Oct 89 10:36:31 -0400
From: andyj@osf.org

Please change my mailing list from:
	andyj@enx.prime.com
to:
	andyj@osf.org

This is effective immediately.  Thank you.

-Andy Johnson
30-Oct-89 23:17:43-PST,2169;000000000000
Return-Path: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8910310718.AA03856@decwrl.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<X3J11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-tle
554 <rmeyers@DEC-TLE.DEC.COM>,<bjork@DEC-TLE.DEC.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#5077@aussie.UUCP>
To: aussie!d-all@uunet.UU.NET

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: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8910310718.AA03849@decwrl.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<X3J11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-decwet
554 <vandepas@DEC-DECWET.DEC.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#5077@aussie.UUCP>
To: aussie!d-all@uunet.UU.NET

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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 30-Oct-89 14:38:37

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#5077@aussie.UUCP>
To: aussie!d-all@uunet.UU.NET

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: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8911030758.AA17771@Sun.COM>
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#5077@aussie.UUCP>
To: aussie!d-all@uunet.UU.NET

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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 30-Oct-89 14:38:37

Message undeliverable and dequeued after 9 days:
keie@CS.VU.NL: Cannot connect to host
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Change of Address
Message-Id: <8910301243.201.UUL1.3#5077@aussie.UUCP>
To: aussie!d-all@uunet.UU.NET

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: <plumhall!root@uunet.UU.NET>
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: plumhall!root@uunet.uu.net
Message-Id: <8912212008.AA03529@uunet.uu.net>
To: X3J11-REQUEST@NIC.DDN.MIL
Subject: new names for J11
Date: Thu Dec 21 00:15:36 1989

! Wendy Merrill     !       merrill@s55.prime.com
! Sheryl Horowitz   !       sheryl@end.prime.com


Thomas Plum  609-927-3770
Plum Hall Inc
1 Spruce Av, Cardiff NJ 08232 USA
uunet!plumhall!plum  OR  plum@PLUMHALL.UU.NET

22-Dec-89 22:17:50-PST,2161;000000000000
Return-Path: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8912230617.AA10073@decwrl.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<X3J11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-tle
554 <rmeyers@DEC-TLE.DEC.COM>... Remote protocol error
While talking to /usr/bin/mail11v3:
>>> MAIL From:<X3J11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-tle
554 <bjork@DEC-TLE.DEC.COM>... 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: plumhall!plum@uunet.uu.net
Message-Id: <8912230603.AA22648@uunet.uu.net>
To: X3J11@NIC.DDN.MIL, uunet!cs.vu.nl!keie@uunet.UU.NET,
        jbb@tekirl.labs.tek.com, rns@se-sd.sandiego.NCR.COM,
        uunet!sun!acad!metaware!ken@uunet.UU.NET,
        uunet!sun!acad!metaware!tom@uunet.UU.NET, sutton@pyrps5.pyramid.com,
        uunet!ukc!knosof!derek@uunet.UU.NET, wnielsen@sum.com
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  plum@PLUMHALL.UU.NET

22-Dec-89 22:17:53-PST,2003;000000000000
Return-Path: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Remote protocol error
Message-Id: <8912230617.AA10055@decwrl.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
While talking to /usr/bin/mail11v3:
>>> MAIL From:<X3J11-RELAY@NIC.DDN.MIL>
<<< 559 No such node as dec-decwet
554 <vandepas@DEC-DECWET.DEC.COM>... 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: plumhall!plum@uunet.uu.net
Message-Id: <8912230603.AA22648@uunet.uu.net>
To: X3J11@NIC.DDN.MIL, uunet!cs.vu.nl!keie@uunet.UU.NET,
        jbb@tekirl.labs.tek.com, rns@se-sd.sandiego.NCR.COM,
        uunet!sun!acad!metaware!ken@uunet.UU.NET,
        uunet!sun!acad!metaware!tom@uunet.UU.NET, sutton@pyrps5.pyramid.com,
        uunet!ukc!knosof!derek@uunet.UU.NET, wnielsen@sum.com
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  plum@PLUMHALL.UU.NET

22-Dec-89 22:33:30-PST,1516;000000000000
Date: Fri, 22 Dec 89 22:29:53 PST
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 22-Dec-89 22:04:00

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... 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: plumhall!plum@uunet.uu.net
Message-Id: <8912230603.AA22648@uunet.uu.net>
To: X3J11@NIC.DDN.MIL, uunet!cs.vu.nl!keie@uunet.UU.NET,
        jbb@tekirl.labs.tek.com, rns@se-sd.sandiego.NCR.COM,
        uunet!sun!acad!metaware!ken@uunet.UU.NET,
        uunet!sun!acad!metaware!tom@uunet.UU.NET, sutton@pyrps5.pyramid.com,
        uunet!ukc!knosof!derek@uunet.UU.NET, wnielsen@sum.com
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  plum@PLUMHALL.UU.NET

-------
26-Dec-89 15:48:51-PST,1961;000000000000
Return-Path: <Mailer-Daemon@Sun.COM>
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: Mailer-Daemon@Sun.COM (Mail Delivery Subsystem)
Subject: Returned mail: Cannot send message for 3 days
Message-Id: <8912261836.AJ00112@Sun.COM>
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- 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: plumhall!plum@uunet.uu.net
Message-Id: <8912230603.AA22648@uunet.uu.net>
To: X3J11@NIC.DDN.MIL, uunet!cs.vu.nl!keie@uunet.UU.NET,
        jbb@tekirl.labs.tek.com, rns@se-sd.sandiego.NCR.COM,
        uunet!sun!acad!metaware!ken@uunet.UU.NET,
        uunet!sun!acad!metaware!tom@uunet.UU.NET, sutton@pyrps5.pyramid.com,
        uunet!ukc!knosof!derek@uunet.UU.NET, wnielsen@sum.com
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  plum@PLUMHALL.UU.NET

28-Dec-89 08:38:50-PST,1627;000000000000
Date: Thu, 28 Dec 89 08:36:09 PST
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 22-Dec-89 22:04:00

Message undeliverable and dequeued after 5 days:
Walter@hpda.hp.com: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: plumhall!plum@uunet.uu.net
Message-Id: <8912230603.AA22648@uunet.uu.net>
To: X3J11@NIC.DDN.MIL, uunet!cs.vu.nl!keie@uunet.UU.NET,
        jbb@tekirl.labs.tek.com, rns@se-sd.sandiego.NCR.COM,
        uunet!sun!acad!metaware!ken@uunet.UU.NET,
        uunet!sun!acad!metaware!tom@uunet.UU.NET, sutton@pyrps5.pyramid.com,
        uunet!ukc!knosof!derek@uunet.UU.NET, wnielsen@sum.com
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  plum@PLUMHALL.UU.NET

-------
28-Dec-89 11:14:08-PST,727;000000000000
Return-Path: <andyj@osf.org>
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: <8912281802.AA23285@osf.osf.org>
To: x3j11-request@sri-nic.arpa
Cc: klh@sri-nic.arpa, andyj@osf.org
Subject: Change of address
Date: Thu, 28 Dec 89 13:02:17 -0500
From: andyj@osf.org

I had sent a request earlier, but it didn't seem to be acted upon.

Please change:
   andyj@enx.prime.com
to:
   andyj@osf.org
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: <MAILER-DAEMON@decpa.pa.dec.com>
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: MAILER-DAEMON@decpa.pa.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9001191840.AA14068@decpa.pa.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
550 dec-decwet.dec.com (tcp)... 550 Host unknown
554 <vandepas@DEC-DECWET.DEC.COM>... 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%plumhall@uunet.UU.NET (Thomas Plum)
Subject: No appeals; FINAL!
Message-Id: <9001171732.0.UUL1.3#20135@plumhall.uu.net>
To: X3J11@NIC.DDN.MIL


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
plum@plumhall.uu.net   (USA) 609-927-3770

19-Jan-90 10:44:21-PST,1946;000000000000
Return-Path: <MAILER-DAEMON@decpa.pa.dec.com>
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: MAILER-DAEMON@decpa.pa.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9001191841.AA14113@decpa.pa.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
550 dec-tle.dec.com (tcp)... 550 Host unknown
554 <rmeyers@DEC-TLE.DEC.COM>,<bjork@DEC-TLE.DEC.COM>... 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%plumhall@uunet.UU.NET (Thomas Plum)
Subject: No appeals; FINAL!
Message-Id: <9001171732.0.UUL1.3#20135@plumhall.uu.net>
To: X3J11@NIC.DDN.MIL


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
plum@plumhall.uu.net   (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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 18-Jan-90 17:04:11

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... User unknown
eager@SUN.COM: 550 <eager@SUN.COM>... 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%plumhall@uunet.UU.NET (Thomas Plum)
Subject: No appeals; FINAL!
Message-Id: <9001171732.0.UUL1.3#20135@plumhall.uu.net>
To: X3J11@NIC.DDN.MIL


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
plum@plumhall.uu.net   (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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 18-Jan-90 17:04:11

Message undeliverable and dequeued after 7 days:
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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%plumhall@uunet.UU.NET (Thomas Plum)
Subject: No appeals; FINAL!
Message-Id: <9001171732.0.UUL1.3#20135@plumhall.uu.net>
To: X3J11@NIC.DDN.MIL


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
plum@plumhall.uu.net   (USA) 609-927-3770

-------
 3-Feb-90 00:07:21-PST,4683;000000000000
Return-Path: <MAILER-DAEMON@decpa.pa.dec.com>
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: <9002030804.AA17927@decpa.pa.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
550 dec-decwet.dec.com (tcp)... 550 Host unknown
554 <vandepas@DEC-DECWET.DEC.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@SRI-NIC.ARPA

%---------------------------------------------------------------

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: MAILER-DAEMON@Relay.Prime.COM (PDNmail version 2.3.x123)
Subject: returned mail
Message-Type: Return
Encoding: 6 text, message
To: <X3J11-RELAY@NIC.DDN.MIL>

Mail addressed to "andyj@s55.prime.com" 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@SRI-NIC.ARPA

%---------------------------------------------------------------

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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 2-Feb-90 19:18:17

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... User unknown
eager@SUN.COM: 550 <eager@SUN.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@SRI-NIC.ARPA

%---------------------------------------------------------------

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: <MAILER-DAEMON@decpa.pa.dec.com>
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: MAILER-DAEMON@decpa.pa.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
Message-Id: <9002030804.AA17946@decpa.pa.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
550 dec-tle.dec.com (tcp)... 550 Host unknown
554 <rmeyers@DEC-TLE.DEC.COM>,<bjork@DEC-TLE.DEC.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@SRI-NIC.ARPA

%---------------------------------------------------------------

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: <MAILER-DAEMON@decpa.pa.dec.com>
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: <9002042256.AA08929@decpa.pa.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
550 dec-decwet.dec.com (tcp)... 550 Host unknown
554 <vandepas@DEC-DECWET.DEC.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

---------------------------------------------------------------------

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: <MAILER-DAEMON@decpa.pa.dec.com>
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: <9002042256.AA08935@decpa.pa.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
550 dec-tle.dec.com (tcp)... 550 Host unknown
554 <rmeyers@DEC-TLE.DEC.COM>,<bjork@DEC-TLE.DEC.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

---------------------------------------------------------------------

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: MAILER-DAEMON@Relay.Prime.COM (PDNmail version 2.3.x123)
Subject: returned mail
Message-Type: Return
Encoding: 6 text, message
To: <X3J11-RELAY@NIC.DDN.MIL>

Mail addressed to "andyj@s55.prime.com" 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

---------------------------------------------------------------------

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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 4-Feb-90 14:18:51

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... User unknown
eager@SUN.COM: 550 <eager@SUN.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

---------------------------------------------------------------------

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: <MAILER-DAEMON@decpa.pa.dec.com>
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: <9002051723.AA27171@decpa.pa.dec.com>
To: x3j11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
550 dec-decwet.dec.com (tcp)... 550 Host unknown
554 <vandepas@DEC-DECWET.DEC.COM>... 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%thor@uunet.UU.NET>
Message-Id: <9002051457.AA00211@thor>
To: uunet!sri-nic.arpa!x3j11@uunet.UU.NET
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                                      scjones@SDRC.UU.NET
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: <MAILER-DAEMON@decpa.pa.dec.com>
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: <9002051723.AA27188@decpa.pa.dec.com>
To: x3j11-RELAY@NIC.DDN.MIL

   ----- Transcript of session follows -----
550 dec-tle.dec.com (tcp)... 550 Host unknown
554 <rmeyers@DEC-TLE.DEC.COM>,<bjork@DEC-TLE.DEC.COM>... 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%thor@uunet.UU.NET>
Message-Id: <9002051457.AA00211@thor>
To: uunet!sri-nic.arpa!x3j11@uunet.UU.NET
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                                      scjones@SDRC.UU.NET
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 <Mailer@NIC.DDN.MIL>
To: x3j11-RELAY@NIC.DDN.MIL
Subject: Message of 5-Feb-90 07:17:40

Message failed for the following:
cmeissen@SUN.COM: 550 <cmeissen@SUN.COM>... User unknown
eager@SUN.COM: 550 <eager@SUN.COM>... 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%thor@uunet.UU.NET>
Message-Id: <9002051457.AA00211@thor>
To: uunet!sri-nic.arpa!x3j11@uunet.UU.NET
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                                      scjones@SDRC.UU.NET
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: MAILER-DAEMON@Relay.Prime.COM (PDNmail version 2.3.x144)
Subject: returned mail
Message-Type: Return
Encoding: 6 text, message
To: <x3j11-RELAY@NIC.DDN.MIL>

Mail addressed to "andyj@s55.prime.com" 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%thor@uunet.UU.NET>
Message-Id: <9002051457.AA00211@thor>
To: uunet!sri-nic.arpa!x3j11@uunet.UU.NET
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                                      scjones@SDRC.UU.NET
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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 2-Feb-90 19:18:17

Message undeliverable and dequeued after 5 days:
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: ANSI C Information
Message-Id: <9002021549.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@SRI-NIC.ARPA

%---------------------------------------------------------------

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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 4-Feb-90 14:18:51

Message undeliverable and dequeued after 7 days:
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

---------------------------------------------------------------------

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 <Mailer@NIC.DDN.MIL>
To: x3j11-RELAY@NIC.DDN.MIL
Subject: Message of 5-Feb-90 07:17:40

Message undeliverable and dequeued after 6 days:
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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%thor@uunet.UU.NET>
Message-Id: <9002051457.AA00211@thor>
To: uunet!sri-nic.arpa!x3j11@uunet.UU.NET
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                                      scjones@SDRC.UU.NET
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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 4-Feb-90 14:18:51

Message undeliverable and dequeued after 10 days:
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: C Aid to Eastern Europe
Message-Id: <9002031948.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

---------------------------------------------------------------------

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 <Mailer@NIC.DDN.MIL>
To: x3j11-RELAY@NIC.DDN.MIL
Subject: Message of 5-Feb-90 07:17:40

Message undeliverable and dequeued after 10 days:
Walter@HPDA.HP.COM: Cannot connect to host
pjp@INMET.INMET.COM.#Internet: Cannot connect to host
rgh@INMET.INMET.COM.#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%thor@uunet.UU.NET>
Message-Id: <9002051457.AA00211@thor>
To: uunet!sri-nic.arpa!x3j11@uunet.UU.NET
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                                      scjones@SDRC.UU.NET
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 <KLH@NIC.DDN.MIL>
Subject: Which address?
To: linda@LLL-LCC.LLNL.GOV, linda@OCFMAIL.OCF.LLNL.GOV
cc: x3j11-request@NIC.DDN.MIL
Message-ID: <12566665006.18.KLH@NIC.DDN.MIL>

I have two addresses shown for you on the X3J11 e-mail list that I maintain:

	linda@LLL-LCC.LLNL.GOV
	linda@OCFMAIL.OCF.LLNL.GOV

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 <KLH@NIC.DDN.MIL>
Subject: Does this address work?
To: kordonov@attunix.att.com
cc: x3j11-request@NIC.DDN.MIL
Message-ID: <12566665616.18.KLH@NIC.DDN.MIL>

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: <linda@ocfmail.ocf.llnl.gov>
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: linda@ocfmail.ocf.llnl.gov (Linda Stanberry)
Message-Id: <9002161521.AA11996@ocfmail.ocf.llnl.gov>
To: KLH@NIC.DDN.MIL, linda@LLL-LCC.LLNL.GOV, linda@OCFMAIL.ocf.llnl.gov
Subject: Re:  Which address?
Cc: x3j11-request@NIC.DDN.MIL

The linda@ocfmail.ocf.llnl.gov 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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 17-Feb-90 08:09:52

Message undeliverable and dequeued after 7 days:
rex@AUSSIE.UU.NET: Cannot connect to host
srd@PEORA.CCUR.COM: Cannot connect to host
pete@STELLAR.COM: 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: NIST Address Correction
Message-Id: <9002141546.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

%---------------------------------------------------------------

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: <plumhall!root@uunet.UU.NET>
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: plumhall!root@uunet.UU.NET (0000-Admin(0000))
Message-Id: <9005241808.AA21778@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11-REQUEST@uunet.UU.NET
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 plum@plumhall.uu.net
25-May-90 19:47:30-PDT,3241;000000000000
Return-Path: <MAILER-DAEMON%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9005260245.AA18715@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:x3j11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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: <9005260245.AB18713@zephyr.ENS.TEK.COM>
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: dfp@attunix.att.COM
Date: Fri, 25 May 90 14:00 EDT
To: x3j11@nic.ddn.mil
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: <gould!MAILER-DAEMON@uunet.UU.NET>
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: gould!MAILER-DAEMON@uunet.UU.NET (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: uunet!NIC.DDN.MIL!x3j11-RELAY@uunet.UU.NET

   ----- 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: <9005262020.AA21334@uunet.uu.net>
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: <MAILER-DAEMON@harvard.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA13361; Thu, 31 May 90 23:18:46 EDT
Date: Thu, 31 May 90 23:18:46 EDT
From: MAILER-DAEMON@harvard.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 saber.ether-mailer... 550 Host unknown
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: plumhall!root@uunet.UU.NET (0000-Admin(0000))
Message-Id: <9005312131.AA02885@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET, uunet!cs.vu.nl!keie@uunet.UU.NET,
        uunet!pyrps5.pyramid.com!sutton@uunet.UU.NET,
        uunet!se-sd.sandiego.NCR.COM!rns@uunet.UU.NET,
        uunet!sun!acad!metaware!ken@uunet.UU.NET,
        uunet!sun!acad!metaware!tom@uunet.UU.NET,
        uunet!sun.com!wnielsen@uunet.UU.NET,
        uunet!tekirl.labs.tek.com!jbb@uunet.UU.NET,
        uunet!ukc!knosof!derek@uunet.UU.NET
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 plum@plumhall.com
          NOTE: ----------------------> NEW DOMAIN ADDR ++++++++++++
31-May-90 21:07:55-PDT,3455;000000000000
Return-Path: <MAILER-DAEMON%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9006010405.AC23354@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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" <plumhall!root@uunet.uu.net>
Mmdf-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <9005312131.AA02885@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.uu.net, uunet!cs.vu.nl!keie@uunet.uu.net,
        uunet!pyrps5.pyramid.com!sutton@uunet.uu.net,
        uunet!se-sd.sandiego.NCR.COM!rns@uunet.uu.net,
        uunet!sun!acad!metaware!ken@uunet.uu.net,
        uunet!sun!acad!metaware!tom@uunet.uu.net,
        uunet!sun.com!wnielsen@uunet.uu.net,
        uunet!tekirl.labs.tek.com!jbb@uunet.uu.net,
        uunet!ukc!knosof!derek@uunet.uu.net
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 plum@plumhall.com
          NOTE: ----------------------> NEW DOMAIN ADDR ++++++++++++
 1-Jun-90 08:12:52-PDT,2269;000000000000
Return-Path: <MAILER-DAEMON@harvard.harvard.edu>
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 x3j11-RELAY@NIC.DDN.MIL) id AA22356; Fri, 1 Jun 90 11:12:48 EDT
Date: Fri, 1 Jun 90 11:12:48 EDT
From: MAILER-DAEMON@harvard.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <x3j11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 saber.ether-mailer... 550 Host unknown
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: dfp@attunix.att.com
Date: Fri, 1 Jun 90 08:44 EDT
To: x3j11@sri-nic.arpa
Subject: Re: Interesting observation/informal interpretation request

Sam Kendall (kendall@Saber.COM) 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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9006011646.AC10035@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:x3j11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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: <9006011646.AB10035@zephyr.ENS.TEK.COM>
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: dfp@attunix.att.COM
Date: Fri, 1 Jun 90 08:44 EDT
To: x3j11@nic.ddn.mil
Subject: Re: Interesting observation/informal interpretation request

Sam Kendall (kendall@Saber.COM) 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: <gould!MAILER-DAEMON@uunet.UU.NET>
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: gould!MAILER-DAEMON@uunet.UU.NET (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: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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: <9005312131.AA02885@plumhall.UUCP>
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 plum@plumhall.com
          NOTE: ----------------------> NEW DOMAIN ADDR ++++++++++++
 3-Jun-90 18:03:45-PDT,2570;000000000000
Return-Path: <gould!MAILER-DAEMON@uunet.UU.NET>
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: gould!MAILER-DAEMON@uunet.UU.NET (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: uunet!NIC.DDN.MIL!x3j11-RELAY@uunet.UU.NET

   ----- 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: <9006031119.AA25102@uunet.uu.net>
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 (kendall@Saber.COM) 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: <oresoft!m2xenix!randy@uunet.UU.NET>
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 <m0hbutI-00028CC@oresoft.oresoft.com>; Sun, 3 Jun 90 06:21 PDT
Received: by m2xenix.psg.com (/\=-/\ Smail3.1.18.1 #18.11)
	id <m0hbuUX-0004HyC@m2xenix.psg.com>; Sun, 3 Jun 90 05:55 PDT
Message-Id: <m0hbuUX-0004HyC@m2xenix.psg.com>
From: randy@m2xenix.psg.com (Randy Bush)
To: x3j11-RELAY@NIC.DDN.MIL
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: <oresoft!m2xenix!randy@uunet.UU.NET>
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 <m0hbutK-00028GC@oresoft.oresoft.com>; Sun, 3 Jun 90 06:21 PDT
Received: by m2xenix.psg.com (/\=-/\ Smail3.1.18.1 #18.11)
	id <m0hbuUW-0000OqC@m2xenix.psg.com>; Sun, 3 Jun 90 05:55 PDT
Message-Id: <m0hbuUW-0000OqC@m2xenix.psg.com>
From: randy@m2xenix.psg.com (Randy Bush)
To: X3J11-RELAY@NIC.DDN.MIL
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: <plumhall!plum@uunet.UU.NET>
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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9006041412.AA01035@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11-REQUEST@uunet.UU.NET
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 plum@plumhall.com
           NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
 6-Jun-90 22:45:00-PDT,1900;000000000000
Return-Path: <MAILER-DAEMON%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9006070542.AC08094@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:x3j11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <ibmsupt!ibmpa!tydeman@uunet.uu.net>
Message-Id: <9006061754.AA05805@ibmpa.paloalto.ibm.com>
To: uunet!sri-nic.arpa!x3j11@uunet.uu.net
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: <tam@hilbert.cray.com>
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: tam@hilbert.cray.com (Tom MacDonald)
Message-Id: <9007070603.AA27506@hilbert.cray.com>
Subject:  TMacD's gone to Montana
To: X3J11-RELAY@NIC.DDN.MIL

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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9007070616.AC29268@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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" <plumhall!root@uunet.uu.net>
Mmdf-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <9007070028.AA01605@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.uu.net, uunet!dkuug.dk!wg14@uunet.uu.net,
        uunet!redbone.att.com!x3j16@uunet.uu.net
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 plum@plumhall.com
 7-Jul-90 05:08:58-PDT,10494;000000000000
Date: Sat, 7 Jul 90 05:04:05 PDT
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 6-Jul-90 17:59:20

Message failed for the following:
alanf@sun.com: 550 <alanf@sun.com>... 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: plumhall!root@uunet.UU.NET (0000-Admin(0000))
Message-Id: <9007070028.AA01605@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET, uunet!dkuug.dk!wg14@uunet.UU.NET,
        uunet!redbone.att.com!x3j16@uunet.UU.NET
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 plum@plumhall.com
-------
 7-Jul-90 21:26:44-PDT,804;000000000000
Date: Sat, 7 Jul 90 21:22:34 PDT
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 7-Jul-90 20:41:05

Message failed for the following:
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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) <gwyn@BRL.MIL>
To:       plumhall!plum@uunet.uu.net
cc:       X3J11@sri-nic.arpa, wg14@dkuug.dk
Subject:  Re:  X3J11/90-048
Message-ID:  <9007072332.aa01092@VGR.BRL.MIL>

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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9007080427.AC26698@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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) <gwyn@brl.mil>
To: plumhall!plum@uunet.uu.net
Cc: X3J11@nic.ddn.mil, wg14@dkuug.dk
Subject:  Re:  X3J11/90-048
Message-Id:  <9007072332.aa01092@VGR.BRL.MIL>

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: <plumhall!plum@uunet.UU.NET>
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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9007161439.AA05934@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11-REQUEST@uunet.UU.NET
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 linda@lll-lcc.llnl.gov.

Linda Stanberry
Lawrence Livermore National Laboratory

16-Jul-90 13:27:00-PDT,1416;000000000000
Return-Path: <klh@NISC.SRI.COM>
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: <9007162025.AA05409@churchy.nisc.sri.com>
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: MAILER-DAEMON@NISC.SRI.COM (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown 
Message-Id: <9007161950.AA05389@churchy.nisc.sri.com> 
To: klh@NISC.SRI.COM
Resent-To: x3j11-request@nic.ddn.mil
Resent-Date: Mon, 16 Jul 1990 13:25:24 PDT
Resent-From: Ken Harrenstien <klh@NISC.SRI.COM>

   ----- Transcript of session follows -----
550 x3j11-request@ddn.nic.mil... 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 <klh@NISC.SRI.COM>
To: plumhall!plum@uunet.UU.NET (Thomas Plum)
Cc: x3j11-request@ddn.nic.mil
Subject: Re: Stanberry addr chg 
In-Reply-To: Your message of Mon, 16 Jul 90 10:39:22 EDT 
Message-Id: <CMM.0.88.648157838.klh@churchy.NISC.SRI.COM>

OK, done.

19-Jul-90 16:48:19-PDT,824;000000000000
Return-Path: <meissner@osf.org>
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: <9007192347.AA26316@osf.osf.org>
From: meissner@osf.org (Michael Meissner)
Subject: Out of the office until who knows when
Brought-To-You-By: the Vacation program
Apparently-To: X3J11-RELAY@NIC.DDN.MIL

	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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9007200020.AC17572@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <aussie!rex@uunet.uu.net>
Subject: extending identifier spellings
Message-Id: <9007190811.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@nic.ddn.mil

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: <9007171602.AA05387@dkuug.dk>
To: wg14@dkuug.dk
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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9007200158.AC19287@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <aussie!rex@uunet.uu.net>
Subject: More on extended identifier names
Message-Id: <9007190821.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@nic.ddn.mil

Some input from Japan.
----------------------

Return-Path: <kuma@cs1.shpcsl.sharp.co.jp>
Subject: Non-ASCII in identifiers (was Re: another item for the addendum)

  Keld J|rn Simonsen <keld@dkuug.dk> 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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 19-Jul-90 08:12:25

Message failed for the following:
alanf@sun.com: 550 <alanf@sun.com>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: extending identifier spellings
Message-Id: <9007190811.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

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: <9007171602.AA05387@dkuug.dk>
To: wg14@dkuug.dk
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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 19-Jul-90 08:12:30

Message failed for the following:
alanf@sun.com: 550 <alanf@sun.com>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: More on extended identifier names
Message-Id: <9007190821.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

Some input from Japan.
----------------------

Return-Path: <kuma@cs1.shpcsl.sharp.co.jp>
Subject: Non-ASCII in identifiers (was Re: another item for the addendum)

  Keld J|rn Simonsen <keld@dkuug.dk> 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%thor@uunet.UU.NET>
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%thor@uunet.UU.NET>
Message-Id: <9007271448.AA02362@thor>
To: uunet!sri-nic.arpa!x3j11-RELAY@uunet.UU.NET
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                                      scjones@thor.UUCP
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: <edg1!jsa@uunet.UU.NET>
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: edg1!jsa@uunet.UU.NET (J. Stephen Adamczyk)
Message-Id: <9008031224.AA12072@edg1.com>
To: uunet!sri-nic.arpa!x3j11-request@uunet.UU.NET
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:

jsa@EDG.COM

Would you please update my entry on the x3j11 list?  Thanks.

Steve Adamczyk (uunet!edg1!jsa or jsa@edg.com; 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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 29-Aug-90 11:57:11

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: plumhall!root@uunet.UU.NET (0000-Admin(0000))
Message-Id: <9008291835.AA05870@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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 plum@plumhall.com
           NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
-------
29-Aug-90 18:25:26-PDT,2663;000000000000
Return-Path: <MAILER-DAEMON%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9008300121.AA01198@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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" <plumhall!root@uunet.uu.net>
Mmdf-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <9008291835.AA05870@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.uu.net
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 plum@plumhall.com
           NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
29-Aug-90 19:14:47-PDT,2244;000000000000
Return-Path: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9008300214.AA07672@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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: <9008291835.AA05870@plumhall.UUCP>
To: X3J11@SRI-NIC.ARPA
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 plum@plumhall.com
           NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
 1-Sep-90 14:08:49-PDT,7567;000000000000
Return-Path: <MAILER-DAEMON%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9009012107.AA16394@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <aussie!rex@uunet.uu.net>
Subject: Request for Interpretation
Message-Id: <9009011516.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@nic.ddn.mil

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: <tsbome!ynk@tis1.tis.toshiba.co.jp>
Message-Id: <9008251838.AA01695@tis1.tis.toshiba.co.jp>
To: wg14@dkuug.dk
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: ynk@ome.toshiba.co.jp
---------------------------------------------------------------


I am able to reach him using 	uunet!ynk@ome.toshiba.co.jp
---------------------------------------------------------------

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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 1-Sep-90 13:51:08

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Request for Interpretation
Message-Id: <9009011516.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

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: <tsbome!ynk@tis1.tis.toshiba.co.jp>
Message-Id: <9008251838.AA01695@tis1.tis.toshiba.co.jp>
To: wg14@dkuug.dk
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: ynk@ome.toshiba.co.jp
---------------------------------------------------------------


I am able to reach him using 	uunet!ynk@ome.toshiba.co.jp
---------------------------------------------------------------

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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Waiting mail  (msg.aa07267)
To:       X3J11-RELAY@NIC.DDN.MIL

    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:rns@se-sd.sandiego.ncr.com (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: plumhall!root@uunet.UU.NET (0000-Admin(0000))
Message-Id: <9008291835.AA05870@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Failed mail  (msg.aa07267)
To:       X3J11-RELAY@NIC.DDN.MIL

    After 7 days (154 hours), your message could not be
fully delivered.

    It failed to be received by the following address(es):

	@ncr.com:rns@se-sd.sandiego.ncr.com (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: plumhall!root@uunet.UU.NET (0000-Admin(0000))
Message-Id: <9008291835.AA05870@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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 plum@plumhall.com
           NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++
 6-Sep-90 04:12:52-PDT,1507;000000000000
Return-Path: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Waiting mail  (msg.aa06367)
To:       X3J11-RELAY@NIC.DDN.MIL

    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:rns@se-sd.sandiego.ncr.com (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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Request for Interpretation
Message-Id: <9009011516.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL

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 <Mailer@NIC.DDN.MIL>
To: x3j11-RELAY@NIC.DDN.MIL
Subject: Message of 7-Sep-90 17:45:53

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: ibmsupt!ibmpa!tydeman@uunet.UU.NET (Fred Tydeman)
Message-Id: <9009071657.AA19713@ibmpa.awdpa.ibm.com>
To: uunet!sri-nic.arpa!x3j11@uunet.UU.NET
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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9009080301.AC08341@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:x3j11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <ibmsupt!ibmpa!tydeman@uunet.uu.net>
Message-Id: <9009071657.AA19713@ibmpa.awdpa.ibm.com>
To: uunet!sri-nic.arpa!x3j11@uunet.uu.net
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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9009081151.AA02138@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!x3j11-RELAY@uunet.UU.NET

   ----- 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: <9009071657.AA19713@ibmpa.awdpa.ibm.com>
To: x3j11@sri-nic.arpa
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: <amdcad!uucp@ames.arc.nasa.gov>
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: uucp@AMD.COM
Message-Id: <9009090646.AA17179@AMD.COM>
Subject: Warning From uucp
Apparently-To: x3j11-RELAY@NIC.DDN.MIL
To: NIC.DDN.MIL!x3j11-RELAY@AMD.COM

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: <9009071657.AA19713@ibmpa.awdpa.ibm.com>
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 <Mailer@NIC.DDN.MIL>
To: x3j11-RELAY@NIC.DDN.MIL
Subject: Message of 10-Sep-90 17:13:35

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: tatge@m2.csc.ti.com (Reid Tatge)
Message-Id: <9009101408.AA19823@m2.csc.ti.com>
To: ibmsupt!ibmpa!tydeman@uunet.uu.net, sri-nic.arpa!x3j11@uunet.uu.net
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 <Mailer@NIC.DDN.MIL>
To: x3j11-RELAY@NIC.DDN.MIL
Subject: Message of 10-Sep-90 17:23:55

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: meissner@osf.org
Message-Id: <9009101442.AA11695@curley.osf.org>
To: ibmsupt!ibmpa!tydeman@uunet.uu.net (Fred Tydeman)
Cc: sri-nic.arpa!x3j11@uunet.uu.net
In-Reply-To: <9009071657.AA19713@ibmpa.awdpa.ibm.com>
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: meissner@osf.org		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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9009110708.AA10941@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!x3j11-RELAY@uunet.UU.NET

   ----- 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: <9009101408.AA19823@m2.csc.ti.com>
To: ibmsupt!ibmpa!tydeman, x3j11@sri-nic.arpa
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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9009110708.AA11004@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!x3j11-RELAY@uunet.UU.NET

   ----- 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: <9009101442.AA11695@curley.osf.org>
To: ibmsupt!ibmpa!tydeman (Fred Tydeman)
Cc: x3j11@sri-nic.arpa
In-Reply-To: <9009071657.AA19713@ibmpa.awdpa.ibm.com>
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: meissner@osf.org		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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9009111302.AB26809@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:x3j11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <tatge@m2.csc.ti.COM>
Message-Id: <9009101408.AA19823@m2.csc.ti.com>
To: ibmsupt!ibmpa!tydeman@uunet.uu.net, sri-nic.arpa!x3j11@uunet.uu.net
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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9009111303.AA26693@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:x3j11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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: meissner@osf.org
Message-Id: <9009101442.AA11695@curley.osf.org>
To: Fred Tydeman <ibmsupt!ibmpa!tydeman@uunet.uu.net>
Cc: sri-nic.arpa!x3j11@uunet.uu.net
In-Reply-To: <9009071657.AA19713@ibmpa.awdpa.ibm.com>
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: meissner@osf.org		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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 18-Sep-90 14:03:13

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... 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: linda@ocfmail.ocf.llnl.gov (Linda Stanberry)
Message-Id: <9009182104.AA17591@ocfmail.ocf.llnl.gov>
To: X3J11@SRI-NIC.ARPA
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
linda@ocfmail.ocf.llnl.gov

-------
18-Sep-90 18:48:41-PDT,1965;000000000000
Return-Path: <MAILER-DAEMON%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9009190148.AC06140@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <linda@ocfmail.ocf.llnl.gov>
Message-Id: <9009182104.AA17591@ocfmail.ocf.llnl.gov>
To: X3J11@nic.ddn.mil
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
linda@ocfmail.ocf.llnl.gov

18-Sep-90 19:44:59-PDT,1003;000000000000
Date: Tue, 18 Sep 90 19:42:33 PDT
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 18-Sep-90 14:03:13

Message failed for the following:
alanf@sun.com: 550 <alanf@sun.com>... 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: linda@ocfmail.ocf.llnl.gov (Linda Stanberry)
Message-Id: <9009182104.AA17591@ocfmail.ocf.llnl.gov>
To: X3J11@SRI-NIC.ARPA
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
linda@ocfmail.ocf.llnl.gov

-------
18-Sep-90 19:49:20-PDT,1679;000000000000
Return-Path: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9009190249.AA15595@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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: <9009182104.AA17591@ocfmail.ocf.llnl.gov>
To: X3J11@SRI-NIC.ARPA
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
linda@ocfmail.ocf.llnl.gov

19-Sep-90 02:59:59-PDT,1427;000000000000
Date: Wed, 19 Sep 90 02:58:17 PDT
From: The Mailer Daemon <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 19-Sep-90 02:45:14

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@sun.com: 550 <alanf@sun.com>... 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 <m0iEz1r-00001DC@amdahl.uts.amdahl.com>; Wed, 19 Sep 90 00:39 PDT
Received: by tde.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.8)
	id <m0iEz1w-00006yC@tde.uts.amdahl.com>; Wed, 19 Sep 90 00:39 PDT
Message-Id: <m0iEz1w-00006yC@tde.uts.amdahl.com>
Date: Wed, 19 Sep 90 00:39 PDT
From: Neal Weidenhofer <nw%uts.amdahl.com@RELAY.CS.NET>
To: linda@OCFMAIL.OCF.LLNL.GOV
Cc: X3J11@NIC.DDN.MIL
In-Reply-To: Linda Stanberry's message of Tue, 18 Sep 90 14:04:37 PDT <9009182104.AA17591@ocfmail.ocf.llnl.gov>
Subject: ANSI C Meeting, September 24-25

I'll be there but I'll be commuting from San Jose.

				Neal Weidenhofer
				nw@amdahl.com
				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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9009191002.AC16214@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <m0iEz1r-00001DC@amdahl.uts.amdahl.com>; Wed, 19 Sep 90 00:39 PDT
Received: by tde.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.8)
	id <m0iEz1w-00006yC@tde.uts.amdahl.com>; Wed, 19 Sep 90 00:39 PDT
Message-Id: <m0iEz1w-00006yC@tde.uts.amdahl.com>
Date: Wed, 19 Sep 90 00:39 PDT
From: Neal Weidenhofer <nw%uts.amdahl.com@RELAY.CS.NET>
To: linda@ocfmail.ocf.llnl.gov
Cc: X3J11@nic.ddn.mil
In-Reply-To: Linda Stanberry's message of Tue, 18 Sep 90 14:04:37 PDT <9009182104.AA17591@ocfmail.ocf.llnl.gov>
Subject: ANSI C Meeting, September 24-25

I'll be there but I'll be commuting from San Jose.

				Neal Weidenhofer
				nw@amdahl.com
				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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9009191355.AA05169@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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 <m0iEz1r-00001DC@amdahl.uts.amdahl.com>; Wed, 19 Sep 90 00:39 PDT
Received: by tde.uts.amdahl.com (/\../\ Smail3.1.14.4 #14.8)
	id <m0iEz1w-00006yC@tde.uts.amdahl.com>; Wed, 19 Sep 90 00:39 PDT
Message-Id: <m0iEz1w-00006yC@tde.uts.amdahl.com>
Date: Wed, 19 Sep 90 00:39 PDT
From: Neal Weidenhofer <uunet!RELAY.CS.NET!nw@uts.amdahl.com>
To: linda@OCFMAIL.OCF.LLNL.GOV
Cc: X3J11@NIC.DDN.MIL
In-Reply-To: Linda Stanberry's message of Tue, 18 Sep 90 14:04:37 PDT <9009182104.AA17591@ocfmail.ocf.llnl.gov>
Subject: ANSI C Meeting, September 24-25

I'll be there but I'll be commuting from San Jose.

				Neal Weidenhofer
				nw@amdahl.com
				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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 19-Sep-90 13:59:16

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@sun.com: 550 <alanf@sun.com>... 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: plumhall!root@uunet.UU.NET (0000-Admin(0000))
Message-Id: <9009191822.AA02906@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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 plum@plumhall.com
           NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++






-------
20-Sep-90 02:59:37-PDT,4256;000000000000
Return-Path: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Failed mail  (msg.ab09980)
To:       @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL

    Your message could not be delivered to
'sutton@tektronix.tek.com (host: tektronix.tek.com) (queue: tektronix)' for the following
reason:  ' <sutton@tektronix.tek.com>... 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" <plumhall!root@UUNET.UU.NET>
MMDF-Warning:  Parse error in original version of preceding line at RELAY.CS.NET
Message-Id: <9009191822.AA02906@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@UUNET.UU.NET
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 plum@plumhall.com
           NOTE: ---------------------> NEW DOMAIN ADDR ++++++++++++






21-Sep-90 10:22:05-PDT,4304;000000000000
Return-Path: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9009211721.AA16061@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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: <9009191822.AA02906@plumhall.UUCP>
To: X3J11@SRI-NIC.ARPA
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 plum@plumhall.com
           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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 30-Sep-90 16:14:31

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: NIST selects validation suite
Message-Id: <9009302316.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL, aussie!plumhall!plum@uunet.UU.NET,
        aussie!attcan!utzoo!hcr!paul@uunet.UU.NET, john@ace.nl

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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9009302332.AA19211@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <aussie!rex@uunet.uu.net>
Subject: NIST selects validation suite
Message-Id: <9009302316.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@nic.ddn.mil, aussie!plumhall!plum@uunet.uu.net,
        aussie!attcan!utzoo!hcr!paul@uunet.uu.net, john@ace.nl

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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9010011243.AA25776@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL, aussie!plumhall!plum, aussie!attcan!utzoo!hcr!paul,
        john@ace.nl

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: <amdcad!uucp@ames.arc.nasa.gov>
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: uucp@AMD.COM
Message-Id: <9010020646.AA25085@AMD.COM>
Subject: Warning From uucp
Apparently-To: X3J11-RELAY@NIC.DDN.MIL
To: NIC.DDN.MIL!X3J11-RELAY@AMD.COM

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#5077@aussie.UUCP>
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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 2-Oct-90 02:03:44

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: RFI #18 from Japan
Message-Id: <9010011757.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL
Cc: ynk@ome.toshiba.co.jp

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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9010020927.AA02667@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <aussie!rex@uunet.uu.net>
Subject: RFI #18 from Japan
Message-Id: <9010011757.0.UUL1.3#5077@aussie.UUCP>
To: X3J11@nic.ddn.mil
Cc: ynk@ome.toshiba.co.jp

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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9010021101.AA12691@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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#5077@aussie.UUCP>
To: X3J11@NIC.DDN.MIL
Cc: ynk@ome.toshiba.co.jp

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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 10-Oct-90 09:40:24

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: aussie!rex@uunet.UU.NET (Rex Jaeschke)
Subject: Re: report delivered to SC22 CHAR WG
Message-Id: <9010101200.1.UUL1.3#5077@aussie.UUCP>
To: aussie!mcsun!dkuug.dk!keld@uunet.UU.NET
Cc: X3J11@NIC.DDN.MIL
In-Reply-To: Your message of Wed, 10 Oct 90 15:50:53 +0100

> From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
> To: wg14@dkuug.dk
> 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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9010110528.AC21648@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <aussie!rex@uunet.uu.net>
Subject: Re: report delivered to SC22 CHAR WG
Message-Id: <9010101200.1.UUL1.3#5077@aussie.UUCP>
To: aussie!mcsun!dkuug.dk!keld@uunet.uu.net
Cc: X3J11@nic.ddn.mil
In-Reply-To: Your message of Wed, 10 Oct 90 15:50:53 +0100

> From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
> To: wg14@dkuug.dk
> 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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9010110807.AA14462@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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#5077@aussie.UUCP>
To: aussie!mcsun!dkuug.dk!keld
Cc: X3J11@NIC.DDN.MIL
In-Reply-To: Your message of Wed, 10 Oct 90 15:50:53 +0100

> From: Keld J|rn Simonsen <uunet!dkuug.dk!keld>
> To: wg14@dkuug.dk
> 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: Mailer-Daemon@home.HarvardSq.COM (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <9010131650.AA00228@home>
To: <X3J11-RELAY@nic.ddn.mil>

   ----- Transcript of session follows -----
Connected to SABER.SABER.COM:
>>> HELO home
<<< 553 home host name configuration error
554 <kendall@saber.com>... Service unavailable

   ----- Unsent message follows -----
Return-Path: <X3J11-RELAY@nic.ddn.mil>
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: <X3J11-RELAY@nic.ddn.mil>
Received: by harvard.harvard.edu (5.54/a0.25)
	(for kendall@saber.com) 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 <keld@dkuug.dk>
Message-Id: <9010131630.AA16843@dkuug.dk>
To: rex%aussie@relay.eu.net
Subject: Re: report delivered to SC22 CHAR WG
Cc: X3J11@nic.ddn.mil
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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9010131654.AA07637@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <keld@dkuug.dk>
Message-Id: <9010131630.AA16843@dkuug.dk>
To: rex%aussie@relay.eu.net
Subject: Re: report delivered to SC22 CHAR WG
Cc: X3J11@nic.ddn.mil
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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 13-Oct-90 09:34:19

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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 <keld@dkuug.dk>
Message-Id: <9010131630.AA16843@dkuug.dk>
To: rex%aussie@relay.eu.net
Subject: Re: report delivered to SC22 CHAR WG
Cc: X3J11@NIC.DDN.MIL
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: Mailer-Daemon@home.HarvardSq.COM (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <9010140335.AA01079@home>
To: <X3J11-RELAY@nic.ddn.mil>

   ----- Transcript of session follows -----
Connected to SABER.SABER.COM:
>>> HELO home
<<< 553 home host name configuration error
554 <kendall@saber.com>... Service unavailable

   ----- Unsent message follows -----
Return-Path: <X3J11-RELAY@nic.ddn.mil>
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: <X3J11-RELAY@nic.ddn.mil>
Received: by harvard.harvard.edu (5.54/a0.25)
	(for kendall@saber.com) 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) <gwyn@brl.mil>
To: Keld J|rn Simonsen <keld@dkuug.dk>
Cc: rex%aussie@relay.eu.net, X3J11@nic.ddn.mil
Subject:  Re:  report delivered to SC22 CHAR WG
Message-Id:  <9010132249.aa04770@VGR.BRL.MIL>

"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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 13-Oct-90 19:56:43

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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) <gwyn@BRL.MIL>
To:       Keld J|rn Simonsen <keld@dkuug.dk>
cc:       rex%aussie@relay.eu.net, X3J11@nic.ddn.mil
Subject:  Re:  report delivered to SC22 CHAR WG
Message-ID:  <9010132249.aa04770@VGR.BRL.MIL>

"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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9010140347.AC23448@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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) <gwyn@brl.mil>
To: Keld J|rn Simonsen <keld@dkuug.dk>
Cc: rex%aussie@relay.eu.net, X3J11@nic.ddn.mil
Subject:  Re:  report delivered to SC22 CHAR WG
Message-Id:  <9010132249.aa04770@VGR.BRL.MIL>

"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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9010140646.AA01344@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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: <9010131630.AA16843@dkuug.dk>
To: rex%aussie@relay.eu.net
Subject: Re: report delivered to SC22 CHAR WG
Cc: X3J11@NIC.DDN.MIL
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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9010140751.AA23683@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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 <keld@dkuug.dk>
Cc: rex%aussie@relay.eu.net, X3J11@nic.ddn.mil
Subject:  Re:  report delivered to SC22 CHAR WG
Message-Id:  <9010132249.aa04770@VGR.BRL.MIL>

"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: Mailer-Daemon@home.HarvardSq.COM (Mail Delivery Subsystem)
Subject: Returned mail: Service unavailable
Message-Id: <9010141413.AA01381@home>
To: <X3J11-RELAY@nic.ddn.mil>

   ----- Transcript of session follows -----
Connected to SABER.SABER.COM:
>>> HELO home
<<< 553 home host name configuration error
554 <kendall@saber.com>... Service unavailable

   ----- Unsent message follows -----
Return-Path: <X3J11-RELAY@nic.ddn.mil>
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: <X3J11-RELAY@nic.ddn.mil>
Received: by harvard.harvard.edu (5.54/a0.25)
	(for kendall@saber.com) 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 <keld@dkuug.dk>
Message-Id: <9010141355.AA13576@dkuug.dk>
To: gwyn@brl.mil
Subject: Re:  report delivered to SC22 CHAR WG
Cc: X3J11@nic.ddn.mil, rex%aussie@relay.eu.net
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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 14-Oct-90 06:58:44

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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 <keld@dkuug.dk>
Message-Id: <9010141355.AA13576@dkuug.dk>
To: gwyn@BRL.MIL
Subject: Re:  report delivered to SC22 CHAR WG
Cc: X3J11@nic.ddn.mil, rex%aussie@relay.eu.net
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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9010141427.AC06592@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <keld@dkuug.dk>
Message-Id: <9010141355.AA13576@dkuug.dk>
To: gwyn@brl.mil
Subject: Re:  report delivered to SC22 CHAR WG
Cc: X3J11@nic.ddn.mil, rex%aussie@relay.eu.net
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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9010150041.AA22085@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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: <9010141355.AA13576@dkuug.dk>
To: gwyn@BRL.MIL
Subject: Re:  report delivered to SC22 CHAR WG
Cc: X3J11@nic.ddn.mil, rex%aussie@relay.eu.net
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: <amdcad!uucp@ames.arc.nasa.gov>
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: uucp@AMD.COM
Message-Id: <9010150646.AA20250@AMD.COM>
Subject: Warning From uucp
Apparently-To: X3J11-RELAY@NIC.DDN.MIL
To: NIC.DDN.MIL!X3J11-RELAY@AMD.COM

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: <9010131630.AA16843@dkuug.dk>
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: <amdcad!uucp@ames.arc.nasa.gov>
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: uucp@AMD.COM
Message-Id: <9010150646.AA20260@AMD.COM>
Subject: Warning From uucp
Apparently-To: X3J11-RELAY@NIC.DDN.MIL
To: NIC.DDN.MIL!X3J11-RELAY@AMD.COM

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:  <9010132249.aa04770@VGR.BRL.MIL>

"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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 13-Oct-90 09:34:19

Message undeliverable and dequeued after 5 days:
wells@COMPASS.COM: 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 <keld@dkuug.dk>
Message-Id: <9010131630.AA16843@dkuug.dk>
To: rex%aussie@relay.eu.net
Subject: Re: report delivered to SC22 CHAR WG
Cc: X3J11@NIC.DDN.MIL
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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA03573; Fri, 2 Nov 90 13:16:02 EST
Date: Fri, 2 Nov 90 13:16:02 EST
From: MAILER-DAEMON%endor@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9011021610.AA02113@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 2-Nov-90 07:53:10

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9011021610.AA02113@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9011021831.AA22797@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <plumhall!plum@uunet.uu.net>
Message-Id: <9011021610.AA02113@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.uu.net
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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA19570; Sat, 3 Nov 90 04:57:29 EST
Date: Sat, 3 Nov 90 04:57:29 EST
From: MAILER-DAEMON%endor@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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) <gwyn@BRL.MIL>
To: plumhall!plum@uunet.uu.net
Cc: @uunet.uu.net:X3J11@SRI-NIC.ARPA
Subject:  Re:  90-085
Message-Id:  <9011022119.aa11297@VGR.BRL.MIL>

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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 3-Nov-90 00:44:11

Message failed for the following:
tam@CRAY.COM: 550 <tam@CRAY.COM>... User unknown
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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) <gwyn@BRL.MIL>
To: plumhall!plum@uunet.uu.net
Cc: SRI-NIC.ARPA!X3J11@uunet.uu.net
Subject:  Re:  90-085
Message-Id:  <9011022119.aa11297@VGR.BRL.MIL>

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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9011031015.AC20421@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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) <gwyn@brl.mil>
To: plumhall!plum@uunet.uu.net
Cc: SRI-NIC.ARPA!X3J11@uunet.uu.net
Subject:  Re:  90-085
Message-Id:  <9011022119.aa11297@VGR.BRL.MIL>

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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9011031218.AA22309@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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: X3J11@SRI-NIC.ARPA
Subject:  Re:  90-085
Message-Id:  <9011022119.aa11297@VGR.BRL.MIL>

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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9011031218.AA22366@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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: <9011021610.AA02113@plumhall.UUCP>
To: X3J11@SRI-NIC.ARPA
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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Waiting mail  (msg.aa05260)
To:       X3J11-RELAY@NIC.DDN.MIL

    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:rns@se-sd.sandiego.ncr.com (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) <gwyn@BRL.MIL>
To: plumhall!plum@uunet.uu.net
Cc: SRI-NIC.ARPA!X3J11@uunet.uu.net
Subject:  Re:  90-085
Message-Id:  <9011022119.aa11297@VGR.BRL.MIL>

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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Failed mail  (msg.aa05260)
To:       X3J11-RELAY@NIC.DDN.MIL

    After 7 days (147 hours), your message could not be
fully delivered.

    It failed to be received by the following address(es):

	@ncr.com:rns@se-sd.sandiego.ncr.com (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) <gwyn@BRL.MIL>
To: plumhall!plum@uunet.uu.net
Cc: SRI-NIC.ARPA!X3J11@uunet.uu.net
Subject:  Re:  90-085
Message-Id:  <9011022119.aa11297@VGR.BRL.MIL>

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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA04511; Mon, 19 Nov 90 00:43:57 EST
Date: Mon, 19 Nov 90 00:43:57 EST
From: MAILER-DAEMON%das@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: rex@aussie.COM (Rex Jaeschke)
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#5077@aussie.COM>
To: X3J11@NIC.DDN.MIL, wg14@dkuug.dk

Please note I now have a domain-style e-mail address. It's

	rex@aussie.COM

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
rex@aussie.COM   |     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: <MAILER-DAEMON@decwrl.dec.com>
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: MAILER-DAEMON@decwrl.dec.com (Mail Delivery Subsystem)
Subject: Returned mail: User unknown
Message-Id: <9011190547.AA06777@decpa.pa.dec.com>
To: X3J11-RELAY@NIC.DDN.MIL

   ----- 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 <rmeyers@TLE.ENET.DEC.COM>... 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 <bjork@TLE.ENET.DEC.COM>... User unknown

   ----- Recipients of this delivery -----
<rmeyers@TLE.ENET.DEC.COM> (bounced)
<bjork@TLE.ENET.DEC.COM> (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: rex@aussie.COM (Rex Jaeschke)
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#5077@aussie.COM>
To: X3J11@NIC.DDN.MIL, wg14@dkuug.dk

Please note I now have a domain-style e-mail address. It's

	rex@aussie.COM

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
rex@aussie.COM   |     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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 18-Nov-90 21:34:44

Message failed for the following:
rasbold@LLL-LCC.LLNL.GOV.#Internet: 550 <rasbold@LLL-LCC.LLNL.GOV>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... 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: rex@aussie.COM (Rex Jaeschke)
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#5077@aussie.COM>
To: X3J11@NIC.DDN.MIL, wg14@dkuug.dk

Please note I now have a domain-style e-mail address. It's

	rex@aussie.COM

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
rex@aussie.COM   |     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%tektronix.tek.com@RELAY.CS.NET>
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%tektronix.tek.com@RELAY.CS.NET>
Subject: Returned mail: User unknown
Message-Id: <9011190553.AB17922@zephyr.ENS.TEK.COM>
To: @RELAY.CS.NET:X3J11-RELAY@NIC.DDN.MIL
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:<sutton@tektronix.TEK.COM>
<<< 550 <sutton@tektronix.TEK.COM>... User unknown
550 <sutton@tektronix.tek.com>... 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 <rex@aussie.COM>
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#5077@aussie.COM>
To: X3J11@nic.ddn.mil, wg14@dkuug.dk

Please note I now have a domain-style e-mail address. It's

	rex@aussie.COM

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
rex@aussie.COM   |     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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 18-Nov-90 21:34:44

Message failed for the following:
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... 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: rex@aussie.COM (Rex Jaeschke)
Subject: New domain address
Message-Id: <9011181451.0.UUL1.3#5077@aussie.COM>
To: X3J11@NIC.DDN.MIL, wg14@dkuug.dk

Please note I now have a domain-style e-mail address. It's

	rex@aussie.COM

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
rex@aussie.COM   |     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: <convex!MAILER-DAEMON@uunet.UU.NET>
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: <9011192220.AA12458@uunet.uu.net>
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: convex!MAILER-DAEMON@uunet.UU.NET (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: uunet!NIC.DDN.MIL!X3J11-RELAY@uunet.UU.NET

   ----- 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#5077@aussie.COM>
To: X3J11@NIC.DDN.MIL, wg14@dkuug.dk

Please note I now have a domain-style e-mail address. It's

	rex@aussie.COM

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
rex@aussie.COM   |     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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA08338; Wed, 12 Dec 90 18:53:02 EST
Date: Wed, 12 Dec 90 18:53:02 EST
From: MAILER-DAEMON%das@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: rex@aussie.COM (Rex Jaeschke)
Subject: Proposed Digraphs
Message-Id: <9012112205.2.UUL1.3#5077@aussie.COM>
To: bs@research.att.com, wg14@dkuug.dk, X3J11@NIC.DDN.MIL,
        x3j16-all@redbone.att.com

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
rex@aussie.COM   |     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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 12-Dec-90 02:11:26

Message failed for the following:
rasbold@LLL-LCC.LLNL.GOV: 550 <rasbold@LLL-LCC.LLNL.GOV>... User unknown
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... User unknown
sutton@TEKTRONIX.TEK.COM: 550 <sutton@TEKTRONIX.TEK.COM>... 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: rex@aussie.COM (Rex Jaeschke)
Subject: Proposed Digraphs
Message-Id: <9012112205.2.UUL1.3#5077@aussie.COM>
To: bs@research.att.com, wg14@dkuug.dk, X3J11@NIC.DDN.MIL,
        x3j16-all@redbone.att.com

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
rex@aussie.COM   |     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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA21988; Thu, 13 Dec 90 01:06:31 EST
Date: Thu, 13 Dec 90 01:06:31 EST
From: MAILER-DAEMON%das@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: rex@aussie.COM (Rex Jaeschke)
Subject: NIST Validation status
Message-Id: <9012122203.0.UUL1.3#5077@aussie.COM>
To: X3J11@NIC.DDN.MIL, wg14@dkuug.dk, bsiqa!neil@aussie.COM

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
uunet!miles@ecf.ncsl.nist.gov


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
rex@aussie.COM   |     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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 12-Dec-90 21:00:06

Message failed for the following:
rasbold@LLL-LCC.LLNL.GOV: 550 <rasbold@LLL-LCC.LLNL.GOV>... User unknown
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... User unknown
sutton@TEKTRONIX.TEK.COM: 550 <sutton@TEKTRONIX.TEK.COM>... 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: rex@aussie.COM (Rex Jaeschke)
Subject: NIST Validation status
Message-Id: <9012122203.0.UUL1.3#5077@aussie.COM>
To: X3J11@NIC.DDN.MIL, wg14@dkuug.dk, bsiqa!neil@aussie.COM

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
uunet!miles@ecf.ncsl.nist.gov


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
rex@aussie.COM   |     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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA00641; Tue, 18 Dec 90 20:33:54 EST
Date: Tue, 18 Dec 90 20:33:54 EST
From: MAILER-DAEMON%das@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: <frankel@Think.COM>
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: frankel@Think.COM
Message-Id: <9012181904.AA26485@wotan.think.com>
To: X3J11@NIC.DDN.MIL
Subject: Thinking Machines reception during the next NCEG & X3J11 meeting

Date: Thu, 18 Oct 90 14:44:28 EDT
From: frankel@Think.COM

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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 18-Dec-90 11:04:49

Message failed for the following:
rasbold@LLL-LCC.LLNL.GOV: 550 <rasbold@LLL-LCC.LLNL.GOV>... User unknown
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... User unknown
sutton@TEKTRONIX.TEK.COM: 550 <sutton@TEKTRONIX.TEK.COM>... User unknown
	    ------------
Received: from mail.think.com by NIC.DDN.MIL with TCP; Tue, 18 Dec 90 11:04:40 PST
Return-Path: <frankel@Think.COM>
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: frankel@Think.COM
Message-Id: <9012181904.AA26485@wotan.think.com>
To: X3J11@NIC.DDN.MIL
Subject: Thinking Machines reception during the next NCEG & X3J11 meeting

Date: Thu, 18 Oct 90 14:44:28 EDT
From: frankel@Think.COM

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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA26905; Fri, 21 Dec 90 02:30:49 EST
Date: Fri, 21 Dec 90 02:30:49 EST
From: MAILER-DAEMON%das@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00212@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012190010.AA08236@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 4

Date:     1990 December 18
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 20-Dec-90 14:57:29

Message failed for the following:
rasbold@LLL-LCC.LLNL.GOV: 550 <rasbold@LLL-LCC.LLNL.GOV>... User unknown
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... User unknown
sutton@TEKTRONIX.TEK.COM: 550 <sutton@TEKTRONIX.TEK.COM>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00212@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012190010.AA08236@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 4

Date:     1990 December 18
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA26982; Fri, 21 Dec 90 02:38:57 EST
Date: Fri, 21 Dec 90 02:38:57 EST
From: MAILER-DAEMON%das@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00182@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012182142.AA05325@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 1

Date:     1990 December 18
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA27015; Fri, 21 Dec 90 02:45:37 EST
Date: Fri, 21 Dec 90 02:45:37 EST
From: MAILER-DAEMON%das@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00192@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012182244.AA06602@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 2

Date:     1990 December 18
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 20-Dec-90 14:57:43

Message failed for the following:
rasbold@LLL-LCC.LLNL.GOV: 550 <rasbold@LLL-LCC.LLNL.GOV>... User unknown
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... User unknown
sutton@TEKTRONIX.TEK.COM: 550 <sutton@TEKTRONIX.TEK.COM>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00182@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012182142.AA05325@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 1

Date:     1990 December 18
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 20-Dec-90 14:57:54

Message failed for the following:
rasbold@LLL-LCC.LLNL.GOV: 550 <rasbold@LLL-LCC.LLNL.GOV>... User unknown
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... User unknown
sutton@TEKTRONIX.TEK.COM: 550 <sutton@TEKTRONIX.TEK.COM>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00192@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012182244.AA06602@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 2

Date:     1990 December 18
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA27171; Fri, 21 Dec 90 02:55:02 EST
Date: Fri, 21 Dec 90 02:55:02 EST
From: MAILER-DAEMON%das@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00202@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012182320.AA07381@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 3

Date:     1990 December 18
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 20-Dec-90 14:58:06

Message failed for the following:
rasbold@LLL-LCC.LLNL.GOV: 550 <rasbold@LLL-LCC.LLNL.GOV>... User unknown
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... User unknown
sutton@TEKTRONIX.TEK.COM: 550 <sutton@TEKTRONIX.TEK.COM>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00202@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012182320.AA07381@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 3

Date:     1990 December 18
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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: <MAILER-DAEMON@das.harvard.edu>
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 X3J11-RELAY@NIC.DDN.MIL) id AA27475; Fri, 21 Dec 90 03:10:07 EST
Date: Fri, 21 Dec 90 03:10:07 EST
From: MAILER-DAEMON%das@das.harvard.edu (Mail Delivery Subsystem)
Subject: Returned mail: Host unknown
To: <X3J11-RELAY@NIC.DDN.MIL>

   ----- Transcript of session follows -----
550 <kendall%saber@HARVARD.HARVARD.EDU>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00222@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012192338.AA22257@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 5

Date:     1990 December 19
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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 <Mailer@NIC.DDN.MIL>
To: X3J11-RELAY@NIC.DDN.MIL
Subject: Message of 20-Dec-90 14:58:28

Message failed for the following:
rasbold@LLL-LCC.LLNL.GOV: 550 <rasbold@LLL-LCC.LLNL.GOV>... User unknown
fieland@PRIMERD.PRIME.COM: 550 <fieland@PRIMERD.PRIME.COM>... User unknown
alanf@SUN.COM: 550 <alanf@SUN.COM>... User unknown
sutton@TEKTRONIX.TEK.COM: 550 <sutton@TEKTRONIX.TEK.COM>... 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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00222@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <9012192338.AA22257@ibmpa.awdpa.ibm.com>
To: plum@plumhall.com
Subject: RFI 5

Date:     1990 December 19
To:       ANSI C committee via Thomas Plum, Vice-Chair
          plum@plumhall.com
From:     Fred Tydeman, IBM's NCEG representative
          Mail Stop 35A
          1510 Page Mill Road
          Palo Alto, California 94304
          Internet: tydeman@ibmpa.awdpa.ibm.com
          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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Waiting mail  (msg.ac02788)
To:       X3J11-RELAY@NIC.DDN.MIL

    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:rns@se-sd.sandiego.ncr.com (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: <frankel@Think.COM>
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: frankel@Think.COM
Message-Id: <9012181904.AA26485@wotan.think.com>
To: X3J11@NIC.DDN.MIL
Subject: Thinking Machines reception during the next NCEG & X3J11 meeting

Date: Thu, 18 Oct 90 14:44:28 EDT
From: frankel@Think.COM
...
25-Dec-90 04:21:38-PST,1634;000000000000
Return-Path: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Waiting mail  (msg.aa05158)
To:       X3J11-RELAY@NIC.DDN.MIL

    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:rns@se-sd.sandiego.ncr.com (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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00202@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Waiting mail  (msg.aa05080)
To:       X3J11-RELAY@NIC.DDN.MIL

    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:rns@se-sd.sandiego.ncr.com (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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00182@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Waiting mail  (msg.aa05096)
To:       X3J11-RELAY@NIC.DDN.MIL

    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:rns@se-sd.sandiego.ncr.com (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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00192@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Waiting mail  (msg.aa05043)
To:       X3J11-RELAY@NIC.DDN.MIL

    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:rns@se-sd.sandiego.ncr.com (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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00212@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Failed mail  (msg.ac02788)
To:       X3J11-RELAY@NIC.DDN.MIL

    After 7 days (154 hours), your message could not be
fully delivered.

    It failed to be received by the following address(es):

	@ncr.com:rns@se-sd.sandiego.ncr.com (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: <frankel@Think.COM>
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: frankel@Think.COM
Message-Id: <9012181904.AA26485@wotan.think.com>
To: X3J11@NIC.DDN.MIL
Subject: Thinking Machines reception during the next NCEG & X3J11 meeting

Date: Thu, 18 Oct 90 14:44:28 EDT
From: frankel@Think.COM

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: <mmdf@RELAY.CS.NET>
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) <mmdf@RELAY.CS.NET>
Sender:   mmdf@RELAY.CS.NET
Subject:  Waiting mail  (msg.aa05284)
To:       X3J11-RELAY@NIC.DDN.MIL

    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:rns@se-sd.sandiego.ncr.com (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: plumhall!plum@uunet.UU.NET (Thomas Plum)
Message-Id: <9012202251.AA00222@plumhall.UUCP>
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
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: <wells@Compass.COM>
Received: from mail.think.com by NIC.DDN.MIL with TCP; Mon, 7 Jan 91 06:21:19 PST
Return-Path: <wells@Compass.COM>
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 x3j11-request@sri-nic.arpa); 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: wells@compass.com (Ian Wells)
Message-Id: <9101071340.AA15971@senduleak.compass.com>
To: x3j11-request@NIC.DDN.MIL
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: tydeman@uunet.UU.NET (Fred Tydeman)
To: sun!dgh!numeric-interest@uunet.UU.NET
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: tydeman@ibmpa.awdpa.ibm.com
          UUCP: uunet!ibmsupt!tydeman
          (415) 855-4430