Trailing-Edge
-
PDP-10 Archives
-
SRI_NIC_PERM_FS_1_19910112
-
c/x3j11/x3j11.mail
There are no other files named x3j11.mail in the archive.
17-Nov-88 15:24:55-PST,3279;000000000001
Mail-From: KLH created at 17-Nov-88 15:19:22
Date: Thu, 17 Nov 88 15:18:38 PST
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: X3J11 mailing list
To: x3j11@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12447376021.25.KLH@SRI-NIC.ARPA>
I think I've received just about all the responses I'm going to get, so
here's the setup:
To send a message to everyone, mail to: X3J11@SRI-NIC.ARPA.
To request changes etc, use the usual: X3J11-REQUEST@SRI-NIC.ARPA.
I'm enclosing the current distribution list below, so you can see
who's on and who's not. You will probably find the format a bit odd,
but understandable (it's meant for direct reading by our TOPS-20
mailer). I've used domain name addresses whenever possible, which is why
many of them go through UUNET. If you know of a better address, or
have more people to add, please send your updates to X3J11-REQUEST.
I'm also keeping a log file of the messages, but it's not publicly
readable since I wasn't sure whether people wanted their discussions
open or not; SRI-NIC is a highly visible site. I'm also initially
assuming that this list is restricted to X3J11 members only, until
said members decide otherwise.
OK, have at it!
----------------------------
!---------- Valid addresses (sorted by domain name) -----------!
! Dave Prosser ! dfp@ATTUNIX.ATT.COM,-
! Douglas A. Gwyn ! Gwyn@BRL.MIL,-
! Jim Williams ! williams@CSS.NRL.NAVY.MIL,-
! Lu Anne Van de Pas ! vandepas@DEC-DECWET.DEC.COM,-
! Randy Meyers ! rmeyers@DEC-TLE.DEC.COM,-
! Art Bjork ! bjork@DEC-TLE.DEC.COM,-
! Andy Johnson ! andyj@ENX.PRIME.COM,-
! Mike Bennett ! mbennett@gould.UU.NET,-
! Walter Murray ! Walter@HPDA.HP.COM,-
! Shawn Elliott ! elliott@IBM.COM,-
! Mark Schisler (temporarily sharing Elliott's addr) ! elliott@IBM.COM,-
! Randy Hudson ! rgh@INMET.INMET.COM,-
! Clark Nelson ! clark@LANGLAB1.HF.INTEL.COM,-
! Chuck Rasbold (also at rasbold@ssi.uu.net) ! rasbold@LLL-LCC.LLNL.GOV,-
! Linda Stanberry ! linda@LLL-LCC.LLNL.GOV,-
! Dave Weil ! davewe@MICROSOFT.UU.NET,-
! Steve Davies ! srd@PEORA.CCUR.COM,-
! Zona Walcott ! zona@PYRPS5.PYRAMID.COM,-
! Ken Harrenstien ! KLH@SRI-NIC.ARPA,-
! Alan Fargusson ! alanf@SUN.COM,-
! Courtney Meissen ! cmeissen@SUN.COM,-
! Michael Eager ! eager@SUN.COM,-
! Carl Sutton ! sutton@TEKTRONIX.TEK.COM,-
! Steve Adamczyk ! jsa@EDG1.UU.NET,-
! Tom Plum ! plum@PLUMHALL.UU.NET,-
! Larry Jones ! scjones@SDRC.UU.NET,-
! Neal Weidenhofer ! nw@UTS.AMDAHL.COM,-
!-------------- Addresses not in domain format ----------------!
! Tom MacDonald ! "tundra!hall!tam"@SUN.COM,-
! (should be tam@tmacd.cray.com when CRAY.COM gets its act together) !
! Pete Darnell ! "stellar!pete"@UCBVAX.BERKELEY.EDU,-
! (trying pete@STELLAR.UU.NET) !
!------------- No answer, but may work -----------------------!
! Steve Adamski ! kordonov@ATTUNIX.ATT.COM,-
! Larry Breed ! "ibmpa!lmb"@UCBVAX.BERKELEY.EDU,-
!-------------- Unreachable, need path ------------------------!
! Craig Bordelon ! ! "pyuxe!!cjb3" !
! (UCB & SUN bounced; no response from UUNET) !
! Michael Meissner ! ! "mcnc!!rti!!xyzzy!!meissner" !
! (UCB & SUN bounced, no response from UUNET) !
! (note MCNC.ORG and RTI.RTI.ORG exist) !
-------
22-Dec-88 15:52:26-PST,3423;000000000000
Received: from research.att.com by SRI-NIC.ARPA with TCP; Thu, 22 Dec 88 15:47:41 PST
From: dfp@attunix.att.com
Date: Thu, 22 Dec 88 18:41 EST
To: attunix!sri-nic.arpa!x3j11
Subject: ANSI C draft reprinted just before being sent to X3
At essentially the last minute, a problem was found regarding
CLK_TCK when the ANSI C draft and POSIX are combined and the
pair are then matched against X/OPEN and SVID. Keeping the
story short, ANSI + (X/OPEN, SVID) => CLK_TCK == 1000000, but
(POSIX, /usr/group) + (X/OPEN, SVID) => CLK_TCK ~= 50 or 60 or 100.
In order to work around this minor problem (which appears that
it would have required a March meeting if it had not been fixed
now), the name CLK_TCK was changed to CLOCKS_PER_SEC in the ANSI C
draft. A new draft (dated December 7) was printed with a few
editorial changes, all approved unanimously by the draft review
subcommittee.
The new draft has two document numbers: 88-158 (without diffmarks)
and 88-159 (with diffmarks). The following is the list of changes
with October 31, 1988 references and approximate May 13, 1988
references:
Summary of changes since October 31st draft
Oct. 31 refs May 13 refs
Page Line(s) Page Line(s)
3 6-7 3 5-6 Definition of character changed to two
sentences. "Character -- a bit representation
that fits in a byte. The representation of
each member of the basic character set in both
the source and execution environments shall
fit in a byte."
25 19 24 ~17 Added a footnote (18) noting that array and
functions behave differently when qualified.
"See \(sc3.5.3 regarding qualified array and
function types."
35 21,28,30 34 20,27,29 "When an integer" -> "When a value with
integral type" (Note that line 20 was "When
an unsigned integer...".)
50 24 48 2 "other is a" -> "other is a pointer to a"
131 11 127 9-10 "mode instead may" -> "mode may instead"
(Full version of last sentence in paragraph:
"Opening (or creating) a text file with
update mode may instead open (or create) a
binary stream in some implementations.")
133 24 129 18 "A" -> "As noted above, a"
133 24 129 18 Delete " instead of a digit string"
(And delete " *" in the May draft.)
133 30 129 24 "Otherwise, it" -> "(It"
133 31 129 24 "-justified." -> "-justified if this flag is
not specified.)"
(Full version of the new sentence: "(It will
be right-justified if this flag is not
specified.)")
133 33 129 25 "Otherwise, it" -> "(It"
133 33 129 25 "converted." -> "converted if this flag is
not specified.)"
(Full version of the new sentence: "(It will
begin with a sign only when a negative value
is converted if this flag is not specified.)")
171 10 166 10 "CLK_TCK" -> "CLOCKS_PER_SEC"
172 5 167 5 "CLK_TCK" -> "CLOCKS_PER_SEC"
175 41,44 170 40,43 "year (" -> "year (the first "
194 27 189 27 "CLK_TCK" -> "CLOCKS_PER_SEC"
200 28.5 195 27.5 Add "\(bu A structure or union is defined as
containing only unnamed members (\(sc3.5.2.1)."
211 6 205 33 "CLK_TCK" -> "CLOCKS_PER_SEC"
217 41 212 38 "4.1.2" -> "4.1.2.1"
You should be receiving your copy of the draft and rationale within a
week or so.
Dave (your friendly Redactor) Prosser
30-Jan-89 11:06:32-PST,2421;000000000000
Received: from uunet.UU.NET by SRI-NIC.ARPA with TCP; Mon, 30 Jan 89 10:37:12 PST
Received: from plumhall.UUCP by uunet.UU.NET (5.61/1.14) with UUCP
id AA02333; Mon, 30 Jan 89 13:37:15 -0500
From: plumhall!root@uunet.UU.NET
Message-Id: <8901301837.AA02333@uunet.UU.NET>
To: X3J11@SRI-NIC.ARPA
Date: Mon Jan 30 08:47:51 1989
X3J11/89-008
January 25, 1989
****************************
* IMPORTANT !!!!! *
* MEETING CHANGE NOTICE *
****************************
Dear X3J11 Members,
This is the official notice that we will NOT be having our
tentatively scheduled March 6-7, 1989 X3J11 meeting in
Seattle, Washington.
The primary reason for cancelling the March meeting is that
the X3 ballot on our draft will not close until March 3rd.
(There were various delays in the handling of the documents
by the X3 Secretariat.) If, as we all hope, there are no
negative X3 ballots, we would have lost the primary reason
for the meeting. However, at that point, it would be too
late to cancel the meeting.
The meeting is being tentatively resceduled for April 10-11,
1989. Microsoft continues to show great patience with our
dynamic scheduling and has agreed to host the April meeting
in Seattle. Hotel information will be coming in a later
mailing.
We are not certain that we will have the April meeting. It
depends on how the X3 ballot goes and what other business we
may need to deal with at that time. For example, there are
still some problems in the International arena. We
may also want to plan our approach to the maintenance phase
which we, hopefully, will soon be entering.
I will pass on the results of the balloting as soon as they
become available. I will pass on definite meeting plans as
soon as possible after that.
The new meeting date is the same as our original meeting
schedule so I hope that it will not cause too many conflicts
with your plans. I apologize for any inconvenience that
this may cause you.
Thanks for your continued patience and support.
Sincerely,
Jim Brodie
X3J11 Chair
6-Feb-89 11:36:30-PST,3356;000000000000
Received: from BCO-MULTICS.HBI.HONEYWELL.COM by SRI-NIC.ARPA with TCP; Mon, 6 Feb 89 11:29:10 PST
Date: Mon, 6 Feb 89 14:04 EST
From: Warren Johnson <WJohnson@BCO-MULTICS.HBI.HONEYWELL.COM>
Subject: interpretation request
To: x3j11@SRI-NIC.ARPA
Message-ID: <890206190424.714126@BCO-MULTICS.HBI.HONEYWELL.COM>
X3J11/89-010
Tuesday, January 31, 1989
Thomas Plum
Vice Chair ANSI X3-J11
Plum Hall
1 Spruce Ave
Cardiff, NJ 08232
Dear Mr Plum:
A syntactic ambiguity exists in the dpANS C standard for which
there appears to be no semantic disambiguation. A sequence of
examples should explain the ambiguity. This matter needs
interpretation by the ANSI X3-J11 committee.
For these examples, let T be declaration specifiers which contain
at least one type specifier, to satisfy the semantics from 3.5.6:
"If the identifier is redeclared in an inner scope ..., the type
specifiers shall not be omitted in the inner declaration."
Let U be an identifier which is a typedef name at outer scope and
has not (yet) been redeclared at current scope. A caret indicates
the position of each abstract declarator. Consider this declaration:
declaration-specifiers direct-declarator (T (U));
^
Here U is the type of the single parameter to a function
returning type T, due to a constraint from 3.5.4.2:
"In a parameter declaration, a single typedef name in parentheses is
taken to be an abstract declarator that specifies a function with a
single parameter, not as redundant parentheses around the identifier
for a declarator."
Consider this declaration:
declaration-specifiers direct-declarator (T (U (parameter-type-list)));
^ ^
In this example, U could be the type returned by a function which
takes parameter-type-list. This in turn would be the single
parameter to a function returning type T.
Alternatively, U could be a redundantly parenthesized name of a
function which takes parameter-type-list and returns type T.
Given the spirit of the constraint from 3.5.4.2, the former
interpretation seems to be that intended by ANSI. If so, the
constraint may be changed to something similar to:
"In a parameter declaration, a direct declarator which redeclares a
typedef name shall not be redundantly parenthesized."
Of course, parentheses must not be disallowed entirely. Consider
this unambiguous redeclaration of typedef name U:
declaration-specifiers direct-declarator (T (* U)(parameter-type-list));
If you require more information or discussion on this matter,
please contact me, at (508) 671-4156, or by mail at the indicated
address, M/S 826A. Your prompt consideration of this matter is
greatly appreciated.
Sincerely,
Bruce Blodgett
Senior Software Engineer
Compiler Development
Bull HN Information Systems Inc.
300 Concord Road
Billerica, MA 01821
6-Apr-89 05:16:32-PDT,562;000000000000
Mail-From: KLH created at 6-Apr-89 05:10:26
Date: Thu, 6 Apr 89 05:10:21 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Seattle meeting
To: x3j11@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12483954523.17.KLH@SRI-NIC.ARPA>
Just out of curiousity, I'm wondering how many people are planning to
attend this meeting (April 10-11) and whether there will actually be
anything to vote on. Unfortunately I have too many conflicts to go
myself and don't have an alternate, but perhaps it doesn't matter as
much as it used to?
--Ken
-------
25-Apr-89 14:44:36-PDT,909;000000000000
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Tue, 25 Apr 89 14:33:41 PDT
Received: from sdrc.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA06531; Tue, 25 Apr 89 16:03:48 -0400
From: sdrc!scjones@uunet.UU.NET (Larry Jones)
Message-Id: <8904252003.AA06531@uunet.uu.net>
Received: by sdrc; Tue, 25 Apr 89 15:56:17 edt
Date: Tue, 25 Apr 89 15:56:17 edt
To: uunet!SRI-NIC.ARPA!X3J11@uunet.UU.NET
Subject: C Binding for GKS-3D
I have just received the current draft of the proposed C Language
Binding for GKS-3D. If anyone is interested in reviewing it, let
me know and I'll be glad to send you a copy.
----
Larry Jones UUCP: uunet!sdrc!scjones
SDRC scjones@sdrc.UU.NET
2000 Eastman Dr. BIX: ltl
Milford, OH 45150 AT&T: (513) 576-2070
"When all else fails, read the directions."
23-May-89 10:34:22-PDT,372;000000000000
Mail-From: KLH created at 23-May-89 10:30:58
Date: Tue, 23 May 89 10:30:53 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: Seattle news?
To: x3j11@SRI-NIC.ARPA
cc: klh@SRI-NIC.ARPA
Message-ID: <12496333643.18.KLH@SRI-NIC.ARPA>
Could one or more of the people who attended the Seattle meeting say
something about what transpired there? Thanks...
-------
24-May-89 15:06:33-PDT,2694;000000000000
Mail-From: KLH created at 24-May-89 14:45:16
Return-Path: <dfp@attunix.att.com>
Received: from arpa.att.com by SRI-NIC.ARPA with TCP; Wed, 24 May 89 07:09:15 PDT
From: dfp@attunix.att.com
Date: Wed, 24 May 89 09:39 EDT
To: attunix!arpa!SRI-NIC.ARPA!KLH
Subject: Re: Seattle news?
ReSent-Date: Wed, 24 May 89 14:45:10 PDT
ReSent-From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
ReSent-To: x3j11@SRI-NIC.ARPA
ReSent-Message-ID: <12496642079.18.KLH@SRI-NIC.ARPA>
The meeting was held in conjunction with WG14 (the ISO C standardization
committee). There were two concerns raised:
UK: not happy with the "behavior is undefined if we say nothing" blanket.
They wanted the draft to wait for their completed list of (possibly)
unconsidered items for its folding into the draft. A compromise was
agreed to that the X3J11 interpretations group would look over the
resulting list and issue a "technical bulletin" through ANSI
containing the points with which they agreed.
Danes: want a more readable supplement to trigraphs. They even lost their
WG14 support for such a change in this meeting, and no change was made
on these lines in the draft.
A surprise for X3J11 was a lost 2nd round public review letter from Russell
Hansberry. As Russell lives in the Seattle area, he attended the meeting
and spent time with a large subgroup that looked over the 20 points in the
letter. The subgroup recommended making no changes in the draft. But,
since Mr. Hansberry chose "his day in court", another X3 level review is
necessary--but only based on our "no"s to this letter. We hoped to be able
to use an expedited 20-day review, but I have just found out that such did
not occur, and the draft is still in the X3 committee....
The final major item from the meeting was the issue of C++ standardization
and how it relates to X3J11. X3J11 had received three requests regarding
C++ standardization: H-P asking X3J11 to do the job; ISO and X3 asking X3J11
whether it's time for C++ to be standardized. H-P's proposal was defeated
12/22, but on whether C++ should start standardization, an informal poll of
the room produced 40 "yes"/12 "don't care"/3 "no", but a committee vote on
the next day produced 12 "yes"/12 "no"/13 "abstain".
Administrative items:
Bill Plauger cannot continue as international representative. There were
no volunteers for the job.
The next meeting is Sept. 21-22 in Salt Lake City (DECUS)
A tentative subsequent meeting was set for March 5-6, 1990 in NYC.
Apple will do mailing. Deadline ~August 19th to Plum.
Dave Prosser
P.S. If you so desire, you can forward this meeting summary.
31-May-89 12:44:43-PDT,11609;000000000000
Mail-From: KLH created at 31-May-89 12:38:34
Date: Wed, 31 May 89 12:38:31 PDT
From: Ken Harrenstien <KLH@SRI-NIC.ARPA>
Subject: [zona@pyrps5.pyramid.com (Zona Walcott - lang group): Re: Seattle news?]
To: x3j11@SRI-NIC.ARPA
Message-ID: <12498454029.49.KLH@SRI-NIC.ARPA>
Forwarding with permission, since I assume other people will be interested.
--Ken
---------------
Return-Path: <pyramid!pyrps5.pyramid.com!zona@uunet.UU.NET>
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Wed, 24 May 89 18:41:28 PDT
Received: from pyramid.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA02181; Wed, 24 May 89 21:41:42 -0400
Received: from pyrps5 by pyramid.pyramid.com (5.61/OSx4.4c-890312)
id AA12232; Wed, 24 May 89 16:56:29 -0700
Received: by pyrps5.pyramid.com (5.61/OSx5.0-890116)
id AA19074; Wed, 24 May 89 16:56:25 -0700
Date: Wed, 24 May 89 16:56:25 -0700
From: zona@pyrps5.pyramid.com (Zona Walcott - lang group)
Message-Id: <8905242356.AA19074@pyrps5.pyramid.com>
To: uunet!SRI-NIC.ARPA!KLH@uunet.UU.NET
Subject: Re: Seattle news?
ok, I'm sending you a copy of my trip report for my company, Pyramid
Technology. This should at least cover a good deal of what went on there.
Zona Walcott
zona@pyramid.pyramid.com
--------------------------------------------------------------
X3J11 MEETING - April 10-11 1989, Seattle
--------------------------------------------
--------------------------------------------
The purpose of the meeting was 3-fold:
1. Discuss and resolve any International issues remaining.
2. Formally respond to a letter from Russell Hansberry.
3. Make plans for future directions for X3J11 and plans for the
interpretation phase.
The Standard has been delayed from going up to ANSI due to a "lost"
public response from Russell Hansberry. X3 rules dictated that the
Committee respond formally to the Hansberry paper since it had been
sent prior to the cut off date for public response. The Committee did
respond to the paper (and to Hansberry who was at the meeting) at this
meeting. (More will follow on his complaints.) As a result of this
delay, the draft has to go back to X3 for a vote prior to going to
ANSI. The expectation is that the X3 vote will take about a month to
a month and a half. There may be problems with this vote since
Hansberry will be recommending a NO vote to several X3 board members.
The International community is also rather unhappy with portions of
the draft and the Committee addressed some of those concerns but
voted to not change the draft. This action prompted at least one
other person, a X3J11 member, to say that he will do what he can
to influence X3 members to vote NO vote on the Standard.
Content of the meeting
----------------------
I. INTERNATIONAL ISSUES:
British issues:
-------------
The British representative felt that their complaints were
not addressed. They want all locations where undefined
behavior exists to be explicitly stated. As they say it, they
want all holes filled in.
X3J11 seems to thinks the British were too vague as to their
complaints all along. The position it has held on undefined
issues is that there are so many places where things are not
defined, it is best to just have the policy that anything that
is not specified, is undefined.
BSI has pulled away from influencing ANSI and pushed for
acceptance of addendum that fills in holes as to what is
undefined. X3J11 voted to accept an addendum, when completed,
to the Standard that will outline all places the behavior is
undefined. BSI members will probably be doing all the work
in this regard.
Danish issues:
-------------
The Danish have proposed several changes from the beginning and
it seems with no luck or positive response from the Committee.
They have proposed the following.
Additions to the trigraph syntax:
They want to allow a digraph representation for a few of them.
i.e. :( for {
:) for }
The issue here is primarily one of "how beautiful" something
looks on paper (something I'm for!).
However it was felt by the Committee (X3J11) that this
could cause potential problems in scanning and parsing,
and require addition of new tokens to the language. Also it
was felt that the character set should remain constant.
Readability was seen as a problem in any representation here
and promoting one way over the other was not necessarily better.
This change was seen as substantive and was voted down.
Additional array representation:
They would like to add infix operators for array
representation:
for example:
a[b] => a!b and
a[] => a!
The Committee felt that this could cause possible
ambiguities and voted against it.
New header file containing defines for operators:
<ISO646.h> containing
#define CAND &&
#define COR ||
#define AND &
#define OR |
#define COMPL ~
#define XOR ^
The Committee voted this down primarily on the basis that
this would just necessarily add new reserved words that
are frequently added by users and really doesn't add
anything useful.
The Danish are VERY unhappy about the outcome of this and will
recommend the ISO go their own direction. They had wanted the
same standard as ANSI but cannot accept as now exists.
General International Issues
----------------------------
WG14 (the ISO corollary of X3J11) voted to accept the Standard
(or to recommend acceptance of the Standard) by ISO.
The Danish representative voted against that acceptance.
For a while I though the British representative wasn't going
to vote positively either until the Committee voted
to accept an addendum to the Standard outlining the undefined
places. The International community does want to see the same
standard and ANSI and is willing to bend to some degree to get
it. The main problem now is with the Danish. It remains to be seen
what ISO does.
II. HANSBERRY PAPER:
After considerable discussion, the Committee formally voted
against all his proposals. Hansberry says he is not happy
with the outcomes and will do what he can to get a negative
vote at the X3 level.
In specific, among other things, these are the issues brought
to the entire committee by a subgroup of X3J11 reviewing the
entire paper:
1). Operator precedence.
He wants bitwise operators to have higher precedence than
relational. As it is now, when using bitwise and relational
operators in the same expression, parentheses are required
around the "bitwise" expression and are sometimes forgotten.
The Committee felt this would break too many existing programs
and while it is a good idea, it's too late to do it for C. Even
if this paper was received early on in the standardization
process, they probably would have voted it down.
2). Interrupts
Hansberry wants a standardized way to specify interrupts and
save the current environment during them.
The Committee felt this was not a C- language issue and was better
handled elsewhere (such as the systems level).
3). Register Storage Class.
He wants programmer ordering of register storage class
specification to dictate priority.
The Committee felt that with new techniques for optimization,
it's best to leave such matters to the optimizer. Also,
such order is frequently thrown out in the processing of
such declarations. There was a certain amount of support
for this idea but it didn't win out.
III. NUMERICS SUBCOMMITTEE FORMATION:
Persons interested in Numerical C Extensions will be holding a
meeting May 10-11 (Wed. and Thurs.) in Minneapolis. This is
an initial "get-together" meeting to see how much interest there
actually is in such a group and to work out the important issues
and a plan of attack. The group is currently an informal group but
if there is enough interest will probably become a subcommittee of
X3J11. X3J11 is interested in having a numerical extensions subgroup
if there are interested people wanting to work on it.
Pyramid should probably send someone with interest and expertise
in numerical issues.
IV. DISCUSSION OF C++ ISSUES:
Basic content of the discussion centered on the following
arguments.
There is a dichotomy between those seeing C++ as a separate
language from C and as extension of the C- mentality.
The consensus is that there IS a need for an OO-based language
though members of the Committee didn't feel qualified in that
area.
Some felt that there hasn't been enough experience yet
with C++ and its environment and it would be too premature
to start a standardization effort.
C++ is still changing. Stroustrup is adding more things to
the language, particularly parameterized types and exception
handling and we do not have enough experience with what works
yet to have a standard. The language is still in flux and not
yet fully defined by use.
There was a feeling among many in the Committee that a
standardization effort should exist for C++ but X3J11 was
not the place to do it.
The Committee voted to not take it on and to not even recommend
that an effort begin (by 'someone') to work on standardization of
C++ since members felt that they didn't have enough experience
in C++ to recommend in any way.
V. INTERPRETATION PHASE FOR X3J11:
The interpretation phase of the ANSI - C standard begins now
(assuming it is accepted this time by X3).
Requests for information or interpretation of the Standard will
be sent to X3J11. Tom Plum and Jim Brodie will coordinate them
and the responses.
Copies of each request will be sent out to several members of the
Committee (hopefully to those who live in the same area) to review
and write a response to. Persons in the same area with the same
queries can get together to formulate a response to them. Responses
will be returned to Plum or Brodie for collation.
The Committee as a whole will review the responses at its meetings
(every 6 months) and accept them amend them as needed. Every six
months, following the meeting, X3J11 will publish the responses and
any corrections to the draft generated as a result of the query.
I will be participating in this phase.
VI. FUTURE MEETINGS OF X3J11:
September 21-22 in Salt Lake City hosted by DECUS.
March 5-6, 1990 New York City area. hosted in part by AT&T
As of now, the Committee hopes to meet every six months for a day
and a half to work on the interpretations phase.
-------
5-Jun-89 15:27:48-PDT,1376;000000000000
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
6-Jun-89 07:12:03-PDT,1920;000000000000
Received: from arpa.att.com by SRI-NIC.ARPA with TCP; Tue, 6 Jun 89 06:36:05 PDT
From: dfp@attunix.att.com
Date: Tue, 6 Jun 89 09:07 EDT
To: attunix!arpa!stellar.COM!pete attunix!uunet.uu.net!ucbcad!SRI-NIC.ARPA!KLH
Subject: Re: ANSI request for clarification.
Cc: attunix!SRI-NIC.ARPA!x3j11
> 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.
This is why Larry (Rosler) and I were so strongly against the whole
"Miranda Rule" approach for the description of a function call. The
implication is strong (given such a description) that there is some
distinguishable lifetime for the prototype...much like there is for
a call to a function through a previously undefined identifier.
> 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.
In actuality, there is no construction required nor implied. The
only reason for adopting this sort of approach is that it guarantees
that if the prototype pair match (one from the definition and one
constructed for the call), then the call is well-behaved. Instead,
the pANS describes what function definitions match what function calls,
both with or without prototypes; the main rule of thumb being that
regular calls and definitions of both styles should be interchangeable,
if reasonable.
>
> Thanks,
> Pete Darnell
Hope this helps for you and Larry.
Dave
7-Jun-89 12:37:57-PDT,2202;000000000000
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.
8-Jun-89 08:45:06-PDT,2853;000000000000
Received: from uunet.uu.net by SRI-NIC.ARPA with TCP; Thu, 8 Jun 89 08:41:25 PDT
Received: from plumhall.UUCP by uunet.uu.net (5.61/1.14) with UUCP
id AA13210; Thu, 8 Jun 89 11:03:25 -0400
From: plumhall!root@uunet.UU.NET
Message-Id: <8906081503.AA13210@uunet.uu.net>
To: X3J11@SRI-NIC.ARPA
Subject: 89-051.nr
Date: Thu Jun 8 03:33:06 1989
INFORMATION PROCESSING SYSTEMS Doc No: X3J11/89-051
American National Standards Committee Date: 06 Jun 89
Operating under the procedures of the Project: 381-D
American National Standards Institute Ref Doc:
Reply to: Thomas Plum
Administrative notices
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.
Very briefly, everything is still in the X3 office in Washington.
Our understanding is that Mr Hansberry has asked for a full for-
mal appeal process. We will send further information as it
becomes available.
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.
Potentially helpful things for the next stages:
o If you have not already done so, please try to obtain access
to an e-mail facility that can be reached through Usenet.
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 .
o If you have a new or changed net-address to report, please
send email to Ken Harrenstien, klh@SRI-NIC.ARPA .
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.
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.
Our thanks to everyone who has worked so long and hard on this
project. We will keep you posted.
__________
X3 Secretariat: Computer and Business Equipment Manufacturers Association
311 First Street NW, Suite 500, Washington DC 20001 202/737-8888
- 1 -
10-Jun-89 18:59:53-PDT,8287;000000000000
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
10-Jun-89 20:18:58-PDT,391;000000000000
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!
12-Jun-89 10:17:49-PDT,1000;000000000000
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
12-Jun-89 13:22:50-PDT,381;000000000000
Mail-From: KLH created at 12-Jun-89 12:27:28
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.
-------
16-Jun-89 14:29:58-PDT,2801;000000000000
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 -
4-Jul-89 19:13:23-PDT,2575;000000000000
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 19:15:11-PDT,3094;000000000000
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 13:31:20-PDT,1411;000000000000
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:22:05-PDT,2027;000000000000
Mail-From: KLH created at 13-Jul-89 00:11:20
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)
----------------------------------------------------------------------------
-------
13-Jul-89 01:08:41-PDT,613;000000000000
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.
13-Jul-89 06:55:07-PDT,1478;000000000000
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
13-Jul-89 14:12:43-PDT,1138;000000000000
Mail-From: KLH created at 13-Jul-89 14:03:28
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
-------
14-Jul-89 21:37:19-PDT,879;000000000000
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.
17-Jul-89 07:34:25-PDT,1583;000000000000
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
1-Aug-89 10:44:02-PDT,4354;000000000000
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 17:58:30-PDT,1515;000000000000
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.
28-Aug-89 16:34:39-PDT,1217;000000000000
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
13-Oct-89 08:31:23-PDT,1602;000000000000
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
30-Oct-89 15:38:28-PST,1392;000000000000
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)
----------------------------------------------------------------------------
22-Dec-89 22:11:40-PST,1243;000000000000
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
18-Jan-90 17:21:19-PST,1207;000000000000
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
2-Feb-90 19:26:48-PST,3976;000000000000
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:22:42-PST,2617;000000000011
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 07:22:54-PST,1024;000000000000
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
17-Feb-90 08:26:31-PST,1453;000000000000
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)
----------------------------------------------------------------------------
25-May-90 11:46:37-PDT,1959;000000000000
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@sri-nic.arpa
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 15:12:59-PDT,2144;000000000000
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 ++++++++++++
1-Jun-90 06:20:39-PDT,1653;000000000000
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
6-Jun-90 14:02:10-PDT,681;000000000000
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: ibmsupt!ibmpa!tydeman@uunet.UU.NET (Fred Tydeman)
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 18:04:01-PDT,10229;000000000000
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 20:42:45-PDT,539;000000000000
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.
19-Jul-90 08:19:36-PDT,1743;000000000000
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)
----------------------------------------------------------------------------
19-Jul-90 08:20:00-PDT,2468;000000000000
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)
----------------------------------------------------------------------------
29-Aug-90 12:03:23-PDT,1333;000000000000
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 ++++++++++++
1-Sep-90 13:58:54-PDT,6345;000000000000
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)
----------------------------------------------------------------------------
7-Sep-90 17:52:00-PDT,930;000000000000
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?
10-Sep-90 17:19:15-PDT,803;000000000000
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 17:27:24-PDT,1533;000000000000
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?
18-Sep-90 14:09:38-PDT,736;000000000000
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
19-Sep-90 02:51:32-PDT,1084;000000000000
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 14:01:51-PDT,3393;000000000000
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 ++++++++++++
30-Sep-90 16:17:42-PDT,2440;000000000000
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)
----------------------------------------------------------------------------
2-Oct-90 02:10:40-PDT,1602;000000000000
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)
----------------------------------------------------------------------------
10-Oct-90 09:44:32-PDT,4360;000000000000
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)
----------------------------------------------------------------------------
13-Oct-90 09:42:54-PDT,812;000000000000
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:04:50-PDT,573;000000000000
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.
14-Oct-90 07:06:06-PDT,804;000000000000
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
2-Nov-90 08:01:10-PST,2940;000000000000
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 -
3-Nov-90 00:44:53-PST,549;000000000000
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:37:25-PST,1204;000000000000
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)
----------------------------------------------------------------------------
12-Dec-90 02:18:41-PST,2525;000000000000
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 21:04:24-PST,4588;000000000000
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 11:48:44-PST,1120;000000000000
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 15:14:02-PST,1995;000000000000
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 15:16:09-PST,1912;000000000000
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 15:18:04-PST,3306;000000000000
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 15:19:51-PST,3162;000000000000
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.
20-Dec-90 15:21:49-PST,12731;000000000000
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?