Minutes from May Meeting II
Linda Stanberry
uunet!ocfmail.ocf.llnl.gov!linda
Fri May 29 13:49:38 PDT 1992
X3J11.1 92-039
Minutes of X3J11.1 Meeting #3
(NCEG Meeting #8)
11-12 May 1992
Radisson Hotel
2177 West North Temple
Salt Lake City, Utah
Attendees
Alpern, Becker, Boney, Farance, Frankel, Hashemi, Hatcher, Hough, Ives,
Jaeschke (Chair), Jervis, Keaton, Kwan, Leary, MacDonald (Vice Chair),
Meissner, Meyers, Molenda, Papagiannakopoulos, Prosser, Sabot,
Stanberry (Meeting Secretary), Terrazas, Thomas, Torkelson, Tydeman
Legend
The following symbols in the left margin of these minutes have the
indicated meaning:
A General approval
SV Straw vote
MSP Formal vote (Moved, Seconded)
* Action item
The activities reported here are grouped by subject, and do not
necessarily follow the exact sequence of presentation during the
meeting.
1. Opening activities (Jaeschke)
1.1 Opening Comments, Goals and Purpose of the Meeting
The meeting was convened at 9:00 a.m. on Monday, 11 May 1992, by
Chairman Rex Jaeschke. Tom MacDonald served as Vice Chairman.
Linda Stanberry served as meeting secretary.
Jaeschke announced that the goals of the meeting were to (1) process
the results of our letter ballot, (2) work towards final ballots on the
complex and the compound literals and initializers proposals, and (3)
work towards closure in other subgroups. Jaeschke also indicated
that we would have to be more focused for this meeting since it was
only two days.
Jaeschke reported that the estimated time for publishing a technical
report had been revised from end of '92 to end of '94.
1.2 Host Facilities
Mike Terrazas informed the committee that DECUS could provide
photocopying and fax services.
Jaeschke announced an estimated cost for the meeting and asked for
volunteers to help finance the cost, to be determined at the close of
the meeting.
1.3 Approval of previous minutes [X3J11.1 92-005]
The minutes of Meeting #2 (Plano, TX, January 1992) were amended as
follows:
(MacDonald) Under item 11, page 14, correction of comment in
addressing example to use baseof(x) instead of baseof(a):
x[i][j]--; /* address is baseof(x) + i * m + j */
(Prosser) Under Item 5, Initializations, the following SV taken at the
Plano meeting was omitted:
SV Should we adopt "last one wins" (left to right) for multiple
initializers for the same subobject?
9 yes. 4 no. 5 undecided.
1.4 Status of Action Items from Previous Minutes [X3J11.1 92-005]
Jaeschke will ask Jim Brodie (X3J11 Chairman) about the availability
of the rationale. Available in LaTeX.
Jaeschke will distribute WG14 proposal [on alternate digraphs] to NCEG.
Done, distributed via e-mail.
Meyers will continue to write or coerce others to write papers
addressing these [extended integer] issues. Done.
MacDonald will include the revised agenda in the next mailing. Is
available, but was not distributed with the mailing.
Jaeschke will invite ISO members to attend the next NCEG meeting as
well as the X3J11 meeting so that concerns about overlap can be
addressed. Done.
Curley will distribute X3H5 project proposal to NCEG. Status unknown,
Bill Torkelson will check on this.
Prosser will produce revised [Initializations] paper with these changes.
Done.
Prosser will investigate including "repetition" in revised document.
Done, but nothing new included.
Boney will inform NCEG by email when industry-wide [SPARC] meeting
will be held to consider adopting a standard. Done.
Farance will notify all persons with ASX proposals of these [subgroup]
procedures. Done.
MacDonald will collect [ASX] critiques and provide for mailing. Done
(no critiques received).
Jaeschke will handle letter ballot documents and mailings, in conjunc-
tion with MacDonald. Done.
Prosser will discuss initialization proposal with Ritchie to check if
any updates; should reissue with first mailing. Done.
Prosser will investigate revised VLA proposal with automatic VLA's
for next meeting. Done.
MacDonald will produce revised aliasing document for first mailing.
Done.
Thomas will produce revised FP/IEEE document for first mailing. Done.
* Jervis will be the technical editor for the ASX document. Ongoing.
Knaak will send ASX subgroup plans for the immediate future to X3H5.
Done.
* Jervis will assume responsibility to notify X3H5 for ongoing ASX plans.
Ongoing.
1.5 Approval of the Agenda (Jaeschke)
Jaeschke asked about whether time would be needed separately for
"generic generic functions." This will be covered under FP/IEEE agenda
time. David Hough indicated he had nothing new to present for exceptions,
and would release his agenda time. Hough did request some time be added
to discuss Stallman's "no pragma" proposal. There was rearrangement of
the agenda to accomodate these changes.
Jamie Frankel announced a second ASX evening meeting for Tuesday be
added also.
1.6 Introduction of participants
Attendees introduced themselves and subgroup focal points were
identified. An attendance list was circulated (attached to these
minutes).
1.7 Distribution of New Documents (MacDonald)
New papers were assigned numbers and available documents were
distributed.
92-027 "Arrays of Variable Length (Revision 7)," MacDonald, distributed.
92-028 "Issues concerning the use of C* as the base for the ASX
document," Farance, distributed.
92-029 "Results of FP and Aliasing Letter Ballot," Jaeschke,
distributed.
92-030 "Progress on Defining 64-bit C Data Types," Boney, distributed.
92-031 "Complex Extension to C (Revision 8)," Knaak, distributed.
92-032 "Using Iterators to Express Parallel Operations in C (Revision
2)," Becker, distributed.
92-033 "Distributing Data Using the "block" Qualifier in C (Revision 2),"
distributed.
92-034 "Designated Initializers and Compound Literals," Prosser,
distributed.
92-035 "Providing Automatic Variable Length Arrays," Prosser,
distributed.
92-036 "C Scalar Data Types for 64-bit Architectures," Khan,
distributed.
92-037 "Comments on Aliasing Proposal by Cray Research, Inc.," MacDonald.
92-038 "Rationale for 64-bit C Type Sizes," Sundarrajan, distributed.
92-039 "Minutes of X3J11.1 Meeting #3," Stanberry, this document.
92-040 "Floating-Point C Extensions," Thomas.
92-041 "Elemental Execution," Hatcher, distributed.
92-042 "More Recommended Changes to X3J11.1/92-014," Thomas.
92-043 "Suggested agenda for evening meetings 1992-05-11, 1992-05-12,"
Farance, distributed.
92-044 "Left Indexing vs. Right Indexing," Farance, distributed.
92-045 ASX Ten Commandments, Farance.
There was some discussion of whether the cover letters for the
aliasing and FP/IEEE proposals needed separate document numbers.
Will use separate number for now, and noted that distribution by
other standards groups will undoubtedly attach their own number as
well.
Jim Thomas indicated that he will revise 92-019, the cover letter for
the FP/IEEE proposal, but will reuse the same document number.
1.8 Identification of voting members (Jaeschke)
Jaeschke reviewed voting and membership rules, noting that he had
new insight into the X3 workings after having attended their officer
training. You can't vote if (1) not a paid member, (2) this is your first
meeting, or (3) you have observer status. You can vote if (1) paid, and
(2) have attended 2 of last 3 meetings.
* Jaeschke will notify potentially delinquent members, in danger of
losing voting rights for non-attendance.
All changes of membership must be sent to CBEMA, the X3 Secretariat.
Dan Arnold
X3 Secretariat
1250 Eye Street, NW, Suite 200
Washington, DC 20005
Phone: (202) 737-8888
Fax: (202) 638-4922 and 628-2829
Jaeschke noted that this is a new address since CBEMA has just moved
their offices.
Jaeschke detailed other relevant operational rules. A quorum for a
meeting is 1/3 of the voting members or at least 4 members. If you
miss two meetings in a row, you have to attend two meetings in a row
to reestablish voting rights (which will be effective on the second
meeting). You can also lose your voting rights by not responding on
two consecutive letter ballots.
After reviewing the attendance list, it was determined that there
were 18 eligible voting members present, and 8 non-voting members,
3 of whom were alternates for member companies.
2. Liaison Reports
2.1 X3J11/WG14 (Jaeschke)
Nothing new to report as there haven't been any meetings since the
last NCEG meeting.
Dave Prosser raised one issue that had been discussed at the last WG14
meeting, regarding the ISO/MSE proposal which requires additions to
the string handling functions for wide strings. The question is
whether these extensions should also be applied to the FP/IEEE functions.
Tom Plum had expressed his belief that the extensions should only be
applied to exisiting C functions, not new ones. Still this is an open
issue that should be resolved.
2.2 X3J16/WG21 (Swan-not present)
It was noted that the token spelling, <>, is still an open issue.
Jaeschke noted he had received first mailings on ISO C++ library, which
is expected to completely subsume the ISO C library.
Prosser noted there are open issues with C++ functions vs. C functions
such as type checking with strchr.
2.3 X3H5 (Curley-not present)
Frankel noted that Thinking Machines has observer status only with X3H5,
but they were aware of two letter ballots that had been taken on language
bindings for Fortran and C.
2.4 X3T2/LCAS (Jaeschke)
Jaeschke attended an ad hoc meeting in Washington on what to do about
cross-language standards. With whom does burden lie on enforcement
of language standards?
Fred Tydeman reported that LCAS proposal is being renamed and reworked.
2.5 POSIX
Prosser reported Posix.4A (Pthread stuff) may impact our parallel
execution stuff, going out for letter ballot later this year perhaps.
John Kwan voiced concern about potential impact on errno in library.
2.6 DSP
Kevin Leary reported they have moved their implementation onto GNU
C which will allow broader distribution of DSP.
2.7 X/Open
Tydeman reported that X/Open is beginning to adopt math functions from
FP/IEEE for library.
Prosser reported release of new interface specificaton XPG4 for Unix
may have some impact on NCEG.
3. Letter Ballot Results (Jaeschke)
Jaeschke reported that both ballots (aliasing and FP/IEEE) passed with
required 2/3 majority. The forwarding and review process to be used
was discussed next. "Group" action items were noted:
* Need to identify to which standards or other groups to send each
proposal.
* Need to get proposals to WG14/X3J11 within 4 weeks to be sure they
get in the first mailing for those groups.
Frankel asked if they have to be sent "as voted" or if revisions were
still allowed. Determined that revisions would be allowed with a
formal vote at this meeting.
The review period for each proposal will be 90 days. This will allow
us to get responses/input collated in time for distribution prior to
our 12/92 meeting.
Jaeschke reminded us that this is not a public review yet, just a review
by other standards and ad hoc groups. We are under no obligation to
respond formally to individual comments.
Frankel asked if comments included with letter ballots will be part of
the cover letters for each proposal. Yes, they can be included.
Thomas asked who will be responsible for sending the proposals to the
designated groups. Jaeschke indicated it would be up to the subgroup
to send.
4. Array Syntax [X3J11.1 92-004, 92-021, 92-026, 92-028, 92-032, 92-033,
92-041, 92-043, 92-044, 92-045]
Bob Jervis reviewed goals of language direction as detailed in 92-004.
Jervis summarized the 3/92 subgroup meeting in Boston (92-021).
(1) Decided to produce a single proposal. (2) Base document starting
point, but will be same format in final form as other subgroups.
(3) There were two active proposals, C* and CRI's iterator/block.
(4) Voted (5Y-3N-1A) to adopt C* reference manual as base document,
and spent time discussing no votes. (5) Monday night's ASX subgroup
meeting will address any changes; encouraged attendance to discuss
and condense issues for presentation to whole committee on Tuesday.
Jervis gave a summary of the Monday evening ASX subgroup meeting.
(1) Voted (7Y-4N-3A) again on C* reference manual as the base document.
(2) Becker had presented 92-033 to the subgroup. (3) Discussion of
general direction of the subgroup. This acknowledged the beginnings
of the subgroup as a desire for improved array syntax, but focus had
shifted to DMA and parallel architecture issues. The outcome of the
discussion was to identify the primary focus of the subgroup is "to
design a set of C language extensions for high performance computers."
In addition to this focus were the caveats that such design could not
ignore DMA's, but that addressing DMA's was not sufficient.
Boney and Thomas asked if this was the focus understood by X3J11.1.
There was considerable discussion (Frankel, Farance, Molenda, Jervis,
Stanberry). Stanberry suggested that the adoption of the C* manual as
the base document appeared to be divisive in the subgroup membership,
and that it might be more productive to create the base document from
pieces, even if they end up with essentially the C* features; appealed
for an end to the infighting so that the subgroup could focus on their
common goals rather than their differences, and make progress towards
closure.
Becker presented CRI proposals for an array syntax extension (iterators,
92-032) and a data distribution model (blocks, 92-033). An iterator is
a new integral type specifying an integer range, which when used as an
array subscript denotes implicit parallel operations on the array object
for the specified range. Iterators also have implicit synchronization
properties. The CRI proposal also adds explicit iterator statements (all)
and explicit synchronization statements (guard, sync, and order). Becker
itemized the following advantages to the iterator approach to an array
syntax extension: (1) few syntactic changes to the language; (2) the
parallelism is expressed clearly; (3) independent of architecture; (4)
independent of data distribution model; (5) closely matches subscript;
(6) expresses nested parallelism; (7) requires no shape conformability
or dope vectors.
Discussion of iterators followed (Prosser, Frankel, Torkelson). It was
noted that this appeared to be in the domain of X3H5. Frankel stated
that this was a parallel control approach.
Becker continued presentation with a brief overview of the block and
scale qualifiers which allow user to express desired data distribution.
Block qualifiers describe distribution across processors, and scale
qualifiers describe access distance or reference patterns. Scale is
more general than block, and lets the compiler choose distribution.
Prosser and Frankel suggested that just the scale proposal be used
since it is more general. Frankel noted that this proposal could be
used with C* as well.
Farance presented the "Ten Commandments" of the ASX subgroup, which are
the major items or issues of discussion for the group.
(1) The primary focus of the ASX subgroup is to develop C language
extensions for high performance computers
(2) Providing parallel operations on arrays or ALO's
(3) A method of synchronization (expression, statement, block, etc.)
(4) Communication visibility/invisibility resolved
(5) ALO's are first class objects
(6) Compatability with Fortran 90 model, and interoperability
(7) Selection mechanism to choose subsets of arrays (e.g., array
slicing or masking)
(8) An iteration method; array walking (support pointers?)
(9) Local vs. global programming model dichotomy exists
(10) Data layout method for distributed data
These are technical issues that need to be pursued orthogonally.
Frankel presented a summary of what's in the base document (C* reference
manual, 92-010) with the objective to identify parts of the C* language
recognized as basis for ASX group. The basic elements and use include:
- shapes, which embody rank, dimension, layout, and context
- objects of the same shape are conformant; can perform elemental
operations in parallel where the level of atomicity is at the
operator
- left indexing is used to identify cost of (potentially higher)
addressing, across PE's (virtual processors) instead of in (local)
memory dimension
- operators are overloaded C operators with elemental meanings,
with a few special new operators: <? (minimum), >? (maximum),
<?=, >?=, %% (true mod operator)
- reduction operators (such as summing entire array, +=)
- contextualization (where statements); based on set theory; nice
debugging model
- parallel left indexing denotes communication between PE's
Frankel also tried to summarize what items had already been identified
as needing change or additions to the ASX base document. These included
action items from the Boston meeting; replacing left indexing with right
indexing; removing the boolean data type; removing "with" since the
compiler can determine shape; adding parallel controlling expressions
in control flow constructs as needed; adding some form of parallel
pointer handles; adding elemental functions with appropriate constraints;
removing %%, overloading, min/max, and assertion grammar; adding a forall/
iterator construct.
Farance indicated "coming attractions" included a Tuesday evening ASX
subgroup meeting, and another meeting in September.
5. Aliasing [X3J11.1 92-003, 92-008, 92-029, 92-037]
MacDonald reviewed results and comments from aliasing letter ballot
from 92-029:
12 yes
3 yes with comment
1 no with comment
4 did not vote
MacDonald then presented proposed cover letter, 92-037.
The question was raised if it was appropriate to include Bill Homer's
responses to letter ballot comments. Prosser suggested that it was
proper for the "subgroup" to reply, and that it should be identified as
such.
It was suggested that the cover letter needs to detail to whom to
reply, and to provide mail and e-mail addresses. The cover letter
should also note that the proposal will be a technical report (TR) for
both X3J11 and X3J11.1.
Jaeschke noted that each subgroup should provide response mail address
and will be responsible for collating responses and presenting them to
this committee.
Prosser asked about the obligation to respond to comments. Jaeschke
indicated that the responses will be folded into revised proposals.
MacDonald and Thomas will note that in their cover letters.
David Keaton asked about Fortran 90 compatability with respect to
behavior of overlapping arrays. MacDonald believes there is no conflict.
Prosser asked if any further response needed to Paul Kohlmiller's
comment which references the Ritchie-Prosser proposal on aliasing.
Frankel suggested that Prosser could provide his own response, if
desired, if approved by the subgroup.
Prosser asked about the effect of iterators on aliasing: does it beg
the question of algorithmic solutions? MacDonald noted that CRI
wanted separate, independent solutions for these two issues, and that
they also wanted a portable solution. Jervis noted that it is easy to
annotate with restrict and stay portable, but use of iterators requires
rewrite of algorithm. There was more discussion (Frankel, Thomas).
MacDonald noted that there was positive feedback from CRI customers
on use of restricted pointers, including C++ customers who also get the
benefit of restrict. Joel Boney and Mike Meissner noted that comments
on prior art are generally positive, and asked if mention of CRI's
implementation should be included in the cover letter.
SV Is there opposition to MacDonald including words about CRI's aliasing
experience in the cover letter?
None.
Frankel asked if cover letter should include company affiliation? No,
should only identify X3J11.1. However it is ok to provide affiliation
for author in indicating address for responses. Boney suggested that
the font for X3J11.1 be increased on the proposal. There was some
discussion on whether the author's name should only appear in the
cover letter, and not on the proposal itself. Consensus was that the
author's name should appear on the proposal.
Prosser stated that he would like us to give CRI latitude to update
forwarded document after results of pending X3J11 interpretation are
known. MacDonald agreed to add some words to that effect in the cover
letter.
* MacDonald will produce revised cover letter for the aliasing proposal.
6. Initializers [X3J11.1 92-034]
Prosser presented the revised paper, 92-035, which will be edited to
comply with TR format. This is a combination of the two separate
initializer and compound literal papers, with the voted changes from
the last meeting folded in.
Prosser clarified that compound literals create temporary, addressable
objects, although anonymous unless assigned to a named object or
function object. Also, compound literals can introduce side effects
with no specified order; however, initializers do specify evaluation
order of initializers within list.
MacDonald asked for clarification of compound literal object which can
be operand of & operator: does this conflict with restriction that &
cannot be applied before cast? No. Only looks like a cast operation, but
is in a different part of the grammar. The open { indicates that it is
not a cast. Prosser agreed to include an example to clarify this. Randy
Meyers asked for an example with a string literal initializer to show
that you can now get a modifiable string literal. An example for a
const qualified object that is therefore read only would be good too.
There was some discussion about whether the cast-like notation could
be eliminated as an abbreviation, but it was believed this could lead to
ambiguity. Frankel asked for a footnote to clarify that the compound
literal syntax is not a cast, even though it looks like one, and
volunteered to help craft words for the footnote.
Stanberry asked for the addition of some words that explicitly state
that all other rules for initializers are inherited, except where noted.
Meyers asked for rationale of allowing multiple initializers of the same
subobject; follows from desire for eventual repetition and C's rule to
initialize to 0's, where every non-zero overwrites 0's. Jaeschke asked
for clarification that all designator subscript expressions must be
constants. Yes.
Prosser agreed to amend the proposal with examples and words as
suggested.
SV How will you vote on the amended initializers/compound literals
proposal?
17 yes
1 yes with comment*
0 no with comment
(*Frankel would like to see proposal with repetition.)
Prosser presented the following proposed changes to 92-034.
Add as a footnote to section 2.1, page 1, line 32:
*Note that this differs from a cast expression. For example,
a cast specifies a conversion to scalar types only, and the
result of a cast is not an object with an address.
Change section 2.1, page 2, lines 8-10 to:
Except that the initializers need not be constant expressions
(when the unnamed object has automatic storage duration),
all the semantics rules and constraints for initializer lists
(section 3.5.7 or subclause 6.5.7) are applicable to compound
literals.* The order in which any side effects occur within
the initializer list is unspecified.**
*For example, subobjects without explicit initializers are
initialized to zero.
** [existing footnote 2].
Add to section 2.1, page 2, line 30:
Or if instead drawline expected pointers:
drawline(&(struct point){.x=1, .y=1},
&(struct point){.x=3, .y=4});
Finally, a read-only compound literal can be specified through
constructions like:
(const float []){1e0, 1e1, 1e2, 1e3}
while the equivalent to a modifiable string literal can be
written as:
(char []){"/tmp/fileXXXXXX"}
(The C standard permits regular string literals to be placed
into read-only memory and even to be shared.)
Discussion followed (Jervis, Meyers, MacDonald, Jaeschke) on the string
literal example. It was recommended that Prosser add more words to
further explain "modifiability" of the string literal, which Prosser
agreed to do.
7. Extended Integer Range [X3J11.1 92-030]
Boney reviewed outcome of the ad hoc committee meeting to gather
input for SPARC on 64-bit data types. The turnout of interested
companies was much greater than anticipated, and another meeting
will be held the first part of June, exact date to be announced via
e-mail. To get added to the e-mail list, send e-mail to:
c-data-types-requestapolitical.Eng.Sun.COM
Boney reported that the ad hoc committee felt that X3J11.1 couldn't
decide the issue fast enough. Prosser asked just what is it that we
are supposed to decide? Boney noted that the ad hoc committee will
decide bindings to number of bits of integral types. They want int type
to always be the most efficient size. There needs to be a standard way
to specify standard types with standard sizes; need syntax to do this.
Frank Farance stated that we need to look beyond "...just give me a 64-
bit int" which will look short-sighted in 10 years. Meyers noted that
different applications have different needs for declaring int sizes.
Jervis pointed out that exact size int, such as 32 or 64-bit, isn't
portable to 36, 48, or 60-bit architectures; feature missing is the
ability to ask for an int "at least n bits" since we can get exact bit
sizes through bit fields. There was further discussion on whether or
not we should develop an exact size syntax.
Boney requested that a subgroup actively address this issue since the
committee as a whole did not seem enthusiastic about resolving. He
repeated that the ad hoc committee is determined to establish a
standard soon, and hash out differences later. He also presented the
current proposals from which the ad hoc committee will probably
choose a standard.
Prosser reminded us that we have previously given advice through our
straw votes to the ad hoc committee and others on these issues.
Kwan had also attended the ad hoc committee meeting and expressed
his concern that X3J11.1 needed to address this issue.
Meyers asked if it was still the opinion of this committee that we
need to address two issues (as decided at the Cupertino meeting):
how to specify a range and "at least n bits." He also reminded us of the
"deliverables" that were agreed to at that meeting.
Farance pointed out that we also need to optimize for either speed or
space. There was much discussion (Frankel, Hough, MacDonald,
Meissner).
Jervis suggested that we need to stop focusing on mapping of the basic
int types, and start focusing on proposal to get syntax to specify minimum
size.
SV Should we abandon deliverable of providing any sort of pros and cons
on mapping basic types to sizes?
12 yes. 1 no. 7 undecided.
This deliverable will be dropped.
SV Should we provide a solution with both space and execution efficient
mechanisms?
8 yes. 6 no. 6 undecided.
SV Should we specify an exact size syntax?
5 yes. 8 no. 4 undecided.
8. Variable Length Arrays [X3J11.1 92-016, 92-027, 92-035]
MacDonald presented 92-027, detailing changes with latest revision.
(1) Section 3.1.2.4 was modified to specify that storage for VLA
objects with automatic storage duration is not necessarily allocated if
the block is entered via a jump statement. Prosser asked why try to
specify, other than as undefined behavior. No objections to this change,
so will be included in next revision. (2) Example 1 no longer uses a
comma operator in the VLA size expression. (3) Section 3.5.2 was
modified to disallow static block scope pointers to VLA's as there
was no identifiable utility in allowing them. (4) Section 3.5.4 has
clarified that VLA size expressions must be positive, and that type
compatability is not dependent on evaluation at execution time. (5)
Section 3.5.4.3 was revised again to the form of "there must exist a
permutation of the parameter declarations such that a declaration is
visible for each instance of an identifier in a size expression." This
means that mutually recursive declarations such as:
void f(int a[sizeof *b], int b[sizeof *a])
would be a constraint violation. There was a further restriction added
that no parameter shall hide the declaration of an identifier used
previously in a size expression. For example:
int n;
void f(int a[n][n], int n) { ... }
would produce a diagnostic. (6) Section 3.6 on Statements was also
revised to specify that a variably qualified declarator is a sequence
point. Hence:
{ int n = 3, m = 4;
int a[n++][n++]; /* undefined */
int b[m++], c[m++]; /* defined */
}
{ int n = 3, m = 4;
int x[n++];
int y[n++]; /* also defined */
}
Frankel stated that Thinking Machines will not support a VLA proposal
without lexical ordering. He suggested that something like:
void f(int a[*][*], int n)
int a[n][n];
{ ... }
be considered.
Prosser presented 92-035, which is a revision of the Ritchie-Prosser
VLA proposal that has been modified to include automatic VLA's. The
new rules needed are as described in the CRI proposal, and became a
straight-forward addition to Ritchie's proposal.
There was some discussion by Dave Alpern and Dave Becker on issues with
allowing automatic VLA's as struct members, especially with using the
offsetof macro.
Prosser presented a comparison of VLA capabilities. All proposals
allow VLA parameters, pointers to VLA's, regular []-style indexing,
and can support AVLA's. For passing VLA's,
MacDonald/Stallman proposal
- requires separate lengths
- has interesting ordering rules or new syntax
- makes a distinction between declarations and definitions
Ritchie proposal
- allows lengths to be passed separately or implicitly
For binding times of VLA lengths, the MacDonald/Stallman proposals
always bind at declaration time, but the Ritchie proposal binds AVLA's
when declared, and pointers when assigned.
MacDonald pointed out that there are two different syntaxes for AVLA's
and the "indirect" VLA's (fat pointers) passed as parameters; users
won't like this.
Meissner asked for clarification on AVLA initialization--they are not
allowed under either proposal.
Frankel pointed out that fat pointers are not in the spirit of C. Jervis
agreed but noted that they are cleaner. MacDonald added they are
cleaner for the implementor, but not for the user. Farance stated a
preference for the CRI proposal because of its easier syntax for the
user. Meyers suggested that passing lengths as separate arguments is
more error prone. Frankel noted that Fortran 90 passes by descriptor,
and Alpern added that Fortran 90 programmers like the assumed shape
feature. Frankel also noted that the CRI proposal introduces fewer new
concepts.
Jervis asked if we might be better served to distribute both proposals
and get feedback.
SV Which lead to the following approval votes:
In favor of strict lexical ordering? 7
In favor of not hiding identifiers in VLA size expressions? 6
In favor of all bindings delayed until end of prototype? 7
In favor of an alternate prototype syntax, combining old and new
parameter declarations (as proposed by Frankel)? 6
In favor of fat pointers with AVLA's? 9
SV Preference vote between
- all bindings delayed to end of prototype: 6
- fat pointers with AVLA's: 7
- undecided: 5
SV Preference vote between
- Ritchie proposal with AVLA's (green): 9
- Keep lexical ordering with Frankel additional syntax (purple): 5
- undecided (yellow?): 4
9. FP/IEEE [X3J11.1 92-014, 92-017, 92-018, 92-019]
Thomas stated that the objective for this meeting was to get approval
from the committee to other changes to document 92-014 after the
letter ballot on this proposal. Some of the proposed changes are in
direct response to comments received on the letter ballot and other
unofficial comments, some are obvious bug fixes or clarification for
the rationale sections. There are a few simple specification changes
which have been approved unanimously by the subgroup, and reflect
the subgroup direction for change.
Thomas then presented the spec changes only from the list of proposed
changes from the subgroup, 92-018. Thomas also presented more
recommended changes that came out of the Sunday evening subgroup
meeting. These changes will be distributed as document 92-042.
SV In favor of adopting these changes to document 92-014?
16 yes. 0 no. 0 abstain.
Thomas led discussion of the draft cover letter, 92-019, and addressed
proposed changes to be made to it. These included (1) setting the
document number for FPCE to 92-040, which will be the revision of
92-014 with the vote changes folded in; (2) stating when the review
period will end; (3) words describing how review comments will be handled;
(4) inclusion of some of the ballot comments which have already been
addressed with unanimous approval; (5) acknowledging public period; and
(6) indicating the groups to whom it will be distributed.
There was some discussion of what groups should receive the forwarded
proposal, but this was postponed to Other Business (item 11 of these
minutes).
Thomas presented Stallman's proposal to replace the pragmas in the
FPCE document with macros. The fenv_access pragmas would become
macros defined in <float.h>, and the fp_contract and fp_wide pragmas
would become macros defined in <fp.h>. The proposed changes to the
FPCE document would be to replace the pragmas with macros, giving
forward references to the header files where the pragmas are now
defined.
Prosser pointed out several problems with this proposal, including:
the pragma name space is much safer than is the macro name space; it
contains numerous additions; it specifies new types; and it may lead to
file scope declarations if macros are nulled. The proposal would involve
substantial editorial changes to the existing document, which is ready
to go out for public review. He suggested that maybe comments could
be solicited for Stallman's proposal in the cover letter with FPCE.
SV In favor of replacing pragmas with macros?
8 yes. 3 no. 7 undecided.
MSP Incorporate a proposal based on 92-017 (Stallman) into the cover letter
for "Floating Point C Extensions" review document and to request feedback
regarding its suitability as a mechanism for replacing pragmas.
(Thomas, Kwan)
17 yes. 0 no. 0 abstain.
10. Complex [X3J11.1 92-031]
MacDonald presented the latest revision of this proposal, 92-032; there
are no substantive changes to the specifications.
MacDonald noted that all the rationale had been moved to the end of the
document instead of distributed throughout the document.
Thomas stated that the last changes agreed to for this document were to
be in the rationale only; also, we just received this revised document
and haven't had time to review it in order to vote it out. MacDonald
suggested that a letter ballot would be more appropriate then.
There were numerous amendments suggested (Frankel, Jaeschke, Hough,
Prosser, Tydeman, Thomas, Boney) which included: (1) correcting the
grammar for imaginary constants so that the i suffix need not appear
last; (2) clarifying keyword specification in 3.1.1 is introduced by
including <complex.h>; (3) moving 3.3.4.5 to library section; (4) adding
something on initializing complex objects, incorporating compound literal
ideas; (5) clarifying under 3.5.2 that there are 3 distinct types being
introduced; (6) merging rationale back into the document body; (7) adding
examples of all operators with complex, without suggesting implementation.
(8) replacing %% in rationale for 3.3.4.5 with some font character to
clarify that it's not specifying a particular character.
Tydeman suggested document should be compatible with the FPCE document
in defining behavior with exceptional values (NaN's, INF's). Hough and
Thomas also expressed concern about various sections of the document
and Hough suggested wording changes that will keep the complex and
FPCE documents more compatible, and reflect correct IEEE requirements.
There was discussion about eventually merging the two documents. There
was also concern that both documents handle overloading in the same
way and use one header file. Consensus was to keep these two documents
separate for now, but add some statement to the cover letter about the
intent to reconcile and merge the two later.
* Tydeman will work with Knaak to provide specifications for IEEE
exceptional values in the library functions for the complex proposal.
Prosser notes a discrepancy with standard C's <math.h> if we add IEEE
values, since the standard says these functions must have defined
behavior for representable values. Thomas and Prosser suggested that
specific domain/range mods are needed.
There was discussion about the inclusion of an imaginary type, and in
particular how to include recognition of our discussions and decisions
in the document.
Hough also objected specifically to the two next-to-last paragraphs in
section 3.1.2.5 of the rationale, which use a quotation from the IEEE
standard, as it was misleading. The intent of the quoted part of the
IEEE standard was to suggest how one might use signalling NaN's, and was
not intended to suggest a requirement for implementation of infinities
in complex. The IEEE standard does not specify anything on complex
data types.
SV Should we strike this quotation?
6 yes. 1 no. 12 undecided.
Hough volunteered to craft alternate words to replace these paragraphs
in the rationale, and MacDonald will incorporate them.
Jaeschke suggested that since a letter ballot would cause us to miss
the deadline for X3J11/WG14 mailings anyway, and Tydeman needs time to
craft additional wording, just process this proposal as normal.
Thomas asked if a subgroup to consider imaginary types could be formed.
Jaeschke stated that the complex subgroup had considered it, and could
do nothing further without a paper to champion a proposal.
11. Administration
11.1 Summary of Decisions Reached
Stanberry reviewed the votes taken during the meeting.
11.2 Action Items Committed to
Stanberry reviewed the action items from the meeting.
11.3 Future Meeting Schedule
7-8 December 1992 in Herndon, VA. This will precede the X3J11/WG14 joint
meeting 9-10 December. Host will be Dec Professional (Jaeschke).
* Jaeschke will provide hotel information in the first mailing.
17-18 May 1993 in New York, NY. This will precede the X3J11 meeting to
be held 19-21 May. Farance, Inc. will be the host.
Leary (Analog Devices) and Torkelson (Convex) will check about hosting
a meeting for X3J11.1 in December '93. Jaeschke suggested that we may
or may not want to separate meeting from X3J11, depending on whether
we need more than two days to complete necessary tasks.
Farance announced there will be an ASX subgroup meeting in September
in the San Jose area, exact dates and location to be announced.
11.4 Mailings and Submission Procedures
For the first mailing, send to David Knaak (knaakacray.com) who will
be handling the mailing in MacDonald's absence.
MacDonald will be leaving 5/21 and returning 9/1, but expects to have
some e-mail contact during that period. Knaak will be the backup
person to contact for document numbers, etc., if MacDonald cannot be
reached.
Jaeschke noted that CBEMA's rules require the minutes to be distributed
by the 4th week after a meeting. Since our first mailing is usually
6 weeks after a meeting, requested that the secretary distribute the
minutes via e-mail by the 4th week, and that an amended/revised copy be
included in the first mailing, and that this be adopted as the committee
policy.
A Allow e-mail distribution of the minutes of meetings to comply with X3
rules.
The deadlines for the mailings are:
13 June - first mailing
24 November - second mailing
11.5 Next Meeting Agenda
Jaeschke suggested a deadline of end of September for receiving comments
on distributed proposals so that there would be time to collate the
results before the second mailing, and discussion time will be allocated
for these results in the next agenda. Agenda time for ASX subgroup
will be determined after their September meeting. Other agenda time
will be divided among subgroups as needed for revised proposals.
There will be evening meetings for the FP/IEEE subgroup on Sunday,
and for the ASX subgroup on Monday.
11.6 Other Business
Jaeschke asked for formal votes on forwarding revised proposals.
MSP To forward the Designated Initializers and Compound Literals document
(92-046), as modified, for wider distribution to appropriate standards
committees.
(Prosser, Jervis)
17 yes.
1 yes with comment (Frankel, Thinking Machines Corporation).
"We fully support the proposed Designated Initializers/Compound
Literals technical report. The inclusion of repetition counts
would further enhance this proposal."
0 no.
MSP To amend the Floating Point C Extensions document (92-014) by 92-018
and 92-041, and to forward for wider distribution.
(Thomas, Kwan)
15 yes.
3 yes with comment (as indicated in 92-029, to be included in revised
cover letter).
0 no.
Jaeschke led discussion on what the distribution process and length of
review should be for the forwarded proposals.
A Set deadline for comments as 11 September 1992, detail in cover letters.
This will allow 3 months review time, and adequate time to collate
results.
A The core target of distribution should be the ANSI/ISO C and C++ groups.
Additional targets per proposal were identified:
- FPCE: X/Open, ADA language group, X3T2
- Aliasing: X3H5
* Jaeschke will assist in getting addresses and contacts for these
standards groups.
CBEMA can also be contacted for addresses (202-737-8888).
Tydeman asked if we wanted to include any users groups. Will limit
distribution for now to standards groups, users will be included in
later public review.
* Individual subgroup editors are responsible for identifying and sending
their proposals to any other target groups.
A brief discussion of the <> digraph proposal was held. The FPCE proposal
could use >< instead. There is also an issue with the Denmark proposal
with the %% operator. Both issues were deferred to the US Tag meeting.
Jaeschke requested a vote to establish the policy for attendance and
voting rights.
MSP To require attendance for at least 1/2 of the days of a meeting (rounded
up for odd number of days) to maintain or establish voting rights.
(MacDonald, Jervis)
17 yes. 0 no. 0 abstain.
Jaeschke also asked for an amendment to the X3 requirement that meeting
agenda be received at least 4 weeks before meetings. Our second mailing
is 6 weeks before meetings, and may not always be received on time.
A Allow the meeting agenda to be posted via e-mail to comply with X3 rules.
Jaeschke also asked for committee policy amendement on notifying members
of delinquencies.
A Permission given to notify members in jeopardy of losing their voting
rights by e-mail, but requiring acknowledgement within specified time;
if no acknowedgement received, must notify via US mail.
Prosser asked for "format" to use for cover letter. To be provided by
e-mail from Thomas and MacDonald. Also noted that mailing dates for
ANSI C/C++ are needed.
* Kwan will determine mail deadlines for C++ and will notify Thomas,
MacDonald, and Prosser.
Jaeschke announced that he will be inaccessible 6/14-7/8/92.
Jaeschke thanked Terrazas and DECUS for duplication services, MacDonald
and CRI for handling the mailings, and the meeting secretary.
Jaeschke declared the meeting adjourned at 5:45 PM, 12 May.
More information about the Numeric-interest
mailing list