jsh@usenix.org (Jeffrey S. Haemer) (10/21/89)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
September 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.5: Ada-language Binding Update
Ted Baker <tbaker@ajpo.sei.cmu.edu> reports on the July 10-14, 1989
meeting in San Jose, California:
The Ada-language binding for 1003.1 is progressing steadily, though
behind schedule. The group agreed to try to prepare a document for
the October meeting in Brussels that is ready for mock ballot. Those
at the meeting will decide whether the document has achieved this
goal. If not, we will try again at the January meeting in New Orleans.
The slow progress is mainly due to the long time between meetings and
the limited workforce available to do the writing. The members, all
volunteers, must steal time for POSIX from their "real" (i.e. paying)
jobs. Attending quarterly meetings already puts most members near the
limit of time they can spare.
Most significant technical issues seem to be resolved; the remaining
controversies center on almost-religious issues, such as the exact
grouping of interface declarations into Ada packages, naming,
capitalization conventions, and where to strike the balance between
providing full functionality and idiot-proofing the interface.
Each chapter has been assigned to a person for review and editing,
based on decisions made at the San Jose meeting. Quite a lot of
writing still needs to be done. Chapter 7 ("Device- and Class-
Specific Functions" --i.e. terminal interfaces) is still empty, and
some others are still mostly just Ada code, with no discussion. Most
of the rationale remains to be written. Mitch Gart has agreed to
coordinate this, including a chapter on "meta-issues" -- design
decisions affecting the entire interface. David Emery will combine
the chapters to produce the next draft.
Interaction with 1003.4 (Real-Time Extensions) has heated up, with
1003.4's consideration of support for multi-threaded processes. Ada
language implementations must support multiple tasks (i.e. threads)
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
September 1989 Standards Update IEEE 1003.5: Ada-language Binding
- 2 -
within a POSIX process, to comply with the Ada language standard.
Neither the 1003.1 standard nor the 1003.4 draft that just completed
mock balloting supports multithreaded processes, so the Ada
implementor is currently forced to hack out some sort of internal
concurrency scheme, with its own layer of dispatching, for each Ada
process. This tends to run aground when one Ada task makes a blocking
system call, since the whole process is forced to wait. Naturally,
Ada implementors and users would be pleased if the POSIX interface
provided for concurrency within a process.
The Ada group is very interested in the threads proposal, and most
members would like to see some support for threads in the 1003.4
standard that goes to formal ballot. Some members are a little bit
concerned that those working on the proposal may not understand Ada
tasking well enough to insure that the proposed threads will be
adequate to implement Ada tasking semantics. This has been very
frustrating for members of the Ada group, since the discussions of the
threads proposal were all in parallel with meetings of 1003.5. The
best the Ada group was able to do was to keep one observer present (on
rotation) at the review of the threads proposal. It is not clear
whether this was adequate.
[Editor's note: What's going on here, and in the second paragraph, is
that some groups are much larger than others. 1003.5 is among the
smallest. The 1003.4 session I saw had about forty, overworked
attendees. The 1003.5 sessions I saw had five to ten.
1003.5 could use a lot more participation from the Ada community.
Unfortunately, this may be a case of "once burned, twice shy". For
years, there's been a lot of talk about "Ada environments", all of
which seem, from a UNIX perspective, like enormous, cumbersome
projects that might actually come into widespread use in, if not our
children's lifetimes, perhaps their children's.
Make no mistake about it: the Ada community is huge. And easy
availability of machines with implemented, Ada-language bindings to
POSIX-conformant operating systems would be immensely useful to that
community. The ability to buy a box, off-the-shelf, with a portable
environment for running Ada programs in the next couple of years,
would make Ada programmers' lives immensely easier and even be a big
aid in implementing the richer and more complex environments mentioned
in the previous paragraph.
Still, you can guess what the average, UNIX-naive, Ada programmer must
think: "Whoopie, another standard/environment. I'll have to take a
look at it in a few years to see how it's coming along." If the IEEE
could make some non-vanishing fraction of the Ada community understand
that POSIX is on the verge of being here, now, dot 5 might get a lot
more help.
This seems to us (that's the editorial "we", folks) like a
September 1989 Standards Update IEEE 1003.5: Ada-language Binding
- 3 -
quintessential marketing problem. If 1003.5 could enlist the help of
1003.0 in this matter, they might be able to make some real headway
here. ]
The 1003.5 group is also very interested in the progress of the
language-independent versions of the POSIX standard. Much of the
labor of the Ada binding group has been devoted to separating the
essential semantics of the 1003.1 interface from the details of its
expression in the C language (for example, setjmp()/longjmp(), and
signal handlers). This labor may be of use to those working on the
language-independent version of 1003.1, but the Ada group does wish
that new standards, such as 1003.4, would start out with a language-
independent document, rather than adding to the language-bias problem.
There was one change in the leadership of the 1003.5 working group.
Stowe Boyd, of Meridian, had been vice-chair but is no longer able to
spare time from his job to work on this project. Steve Deller, of
Verdix, has agreed to replace him. This is a very important job,
since the vice-chair of the 1003.5 group takes direct responsibility
for setting the technical agenda and running meetings.
September 1989 Standards Update IEEE 1003.5: Ada-language Binding
Volume-Number: Volume 17, Number 41jsh@usenix.org (Jeffrey S. Haemer) (01/05/90)
From: Jeffrey S. Haemer <jsh@usenix.org>
An Update on UNIX* and C Standards Activities
December 1989
USENIX Standards Watchdog Committee
Jeffrey S. Haemer, Report Editor
IEEE 1003.5: Ada-language Binding Update
Ted Baker <tbaker@ajpo.sei.cmu.edu> reports on the October 16-20, 1989
meeting in Brussels, Belgium:
The P1003.5 group is producing an Ada-language binding for 1003.1.
The Brussels meeting had two objectives: to reach consensus on a draft
document to be distributed for mock ballot, and to solicit input from
the European community. We achieved the first but not the second;
only one of the ten attendees was European (Olle Wikstrom, from
Ericsson).
The technical editor (David Emery) and the chapter authors had worked
very hard between meetings to produce version 3.2 of the document, and
Dave brought copies to the meeting. The working group reviewed it to
try to correct any serious errors or omissions before mock ballot.
There was a lengthy discussion about schedule and logistics for the
mock ballot. The present plan is to send out copies of the next
draft, in ISO format, to both the ISO and the entire 1003.5 mock-
ballot mailing list. [Editor's note: All committees are re-formatting
their documents in ISO format to smooth the way for ISO acceptance
(see Dominic Dunlop's report on WG15 for more details), and an IEEE
copy editor appeared on the scene in Brussels to give P1003.5 guidance
and help in this.] Since there is no way that enough input can be
received before the next POSIX meeting, in January, the group has
scheduled a special meeting for mock ballot resolution, between the
January and April POSIX meetings, to be held in Tallahassee. The
objective will be to produce a proposed standard to be reviewed at the
April meeting.
Most technical issues discussed were minor, compared with previous
meetings. The most significant, and complicated, was the treatment of
system configuration limits. Here are three problem areas:
__________
* UNIX is a registered trademark of AT&T in the U.S. and other
countries.
December 1989 Standards Update IEEE 1003.5: Ada-language Binding
- 2 -
1. Tri-state configuration parameters (true, false, undefined) in
the POSIX C binding need to be treated differently in the Ada
binding, because Ada prohibits references to undefined symbols.
(I.e., Ada lacks an "#ifdef" facility.)
2. For the same reason, it isn't clear how an Ada binding can
accommodate future POSIX extensions. Suppose, for example, a
future extension adds a new configuration constant. How does
one write an Ada program that takes advantage of the new feature
on implementations where it's available without preventing the
same program from compiling on older implementations, where it's
not?
3. Because Ada compilers can do optimizations, such as dead code
elimination, based on static expressions (the nearest analog to
some C preprocessor capabilities), it is important to provide
compile-time constants, where safe. At the same time, to
support "bubble pack" software that is usable on different
system configurations, programs should also be able to defer
binding such values until run time.
The group did achieve consensus on a treatment of configuration limits
for the mock ballot. It includes a combination of functions, to allow
software to defer resolution of system limits and characteristics
until runtime, and implementation-defined constants and numeric
ranges, to allow optimizers to take advantage of information available
at compile time. This does not fully solve all the problems mentioned
above. Perhaps the mock ballot process will turn up some suggestions
for improvements.
The treatment of process arguments and environment variables, which
must be provided as parameters when starting a new process or calling
Exec produced another controversy.
Unlike C, Ada does not allow pointers to stack or statically allocated
objects. An Ada POSIX interface implemented over a C-language binding
must bridge this gap somehow. For example, an implementation might
use a C-compatible data structure and hide the non-Ada details, or use
an Ada data structure and translate between the two forms. Everyone
agreed that the interface should avoid constraining the
implementation, but the first interface solutions appeared to rule out
desirable implementations. The present solution permits an
application to insure that if the Ada POSIX interface machinery
allocates any "heap" storage this storage is be recovered, while
allowing an implementation to impose restrictions that would permit
stack allocation. A price paid for this compromise is that writing
portable applications takes more care: an application that works OK
with one implementation may lose storage or exceed size limits with
another.
At the previous two meetings, we had substantial interaction both with
December 1989 Standards Update IEEE 1003.5: Ada-language Binding
- 3 -
other groups working on language-independence and with P1003.4 (real-
time). There was much less this time, partly because the group was
concentrating so hard on getting ready for mock ballot, partly because
meetings were spread over several buildings, and partly because
P1003.4 mostly skipped Brussels.
On the administrative side, Steve Deller was promoted from Vice
Chairman to Chairman (in charge of external affairs and running
meetings) and Jim Lonjers was chosen as Vice Chairman (in charge of
administering ballot resolution). This change was required because
the ex-Chairman (Maj. Terry Fong) has been unable to participate
regularly in the working group recently, owing to conflicts with his
professional duties.
Another issue that came up was whether working group members are at
liberty to publish papers or present talks on the 1003.5 work. The
answer is, "Yes." Until now, some members have been exercising self-
censorship, based on an earlier agreement designed to discourage
anyone (e.g., defense department personnel) from making commitments
(e.g., requiring use of the POSIX Ada binding in contracts) based on
erroneous (e.g., overly optimistic) progress reports. It did not take
much discussion to agree that such censorship is now
counterproductive, and may never have been wise. At this point,
P1003.5 certainly wants public exposure of its draft document, and
hopes that such exposure will generate more reviewers and active
working group members.
December 1989 Standards Update IEEE 1003.5: Ada-language Binding
Volume-Number: Volume 18, Number 2