Usenet 1994 January/usenetsourcesnewsgroupsinfomagicjanuary1994.iso/sources/std_unix/volume.19/text0082.txt

Internet Message Format | 1990-05-17 | 6.8 KB

From: Doug Gwyn <uunet!smoke.brl.mil!gwyn>

In article <[e-mail]> >From: Jeffrey S. Haemer <[e-mail]>
>       Watch .1b like a hawk, though.  Any new functionality, slipped into
>       supplements and appendices, carries the same risks as riders on
>       congressional bills; ...
>       I recommend resisting any effort to add functionality for which there
>       aren't existing implementations in wide use, and about which there
>       isn't already general consensus.

It would also be nice if people didn't specify conformance to 1003.1b
just because it's there; for example, it's not clear to me that it
would need to be incorporated into any FIPS.  There were good reasons
for leaving out of 1003.1 many of the facilities that are likely to
creep in as part of 1003.1b, and therefore the additions should not
be picked up automatically.  Just because something is a standard
does not mean that it should be required, especially if it interferes
with long-term improvements in the computing environment (which is
what the USENIX Watchdog Committee is most concerned with).

>       Parenthetically, I'll admit to being mystified by the dim view some
>       folks take of the UPE.  I actually put programmer portability above
>       program portability, since, when I go looking for new jobs I can't
>       take our software with me, but do want to be sure that I can still use
>       vi.

It seems most unlikely to me that you have the option of specifying
IEEE 1003.2 conformance when you interview with a prospective employer.
I believe that the main point of these standards is to attain improved
portability for applications.

Besides, why should I have to support both "vi" and "emacs" on my systems
when we're all using "sam" instead?  It gains me NOTHING (because imported
software is not going to require these interactive facilities) and costs
me a bunch.

>       In short, we who do ports will have to keep track of how to invoke the
>       C compiler on each of our target machines; .2 will not have enhanced
>       portability in this area of our work.

Presumably, if your code follows the C standard as well as IEEE 1003.2,
you'd simply invoke "c89" without K&R1 flags.  If you insist on K&R1 C,
you're already outside the scope of standards.  I think it's true that
one won't know exactly what to expect when invoking "cc", but that is
already the case.  "c89" should (if 1003.2 gets the spec right) obtain
predictable (i.e., standard!) behavior, which will be an improvement.

>       ...  Dot three isn't always popular; one hears
>       complaints that they come up with interpretations that seem contrary
>       to the intention of the original standards committees.

The most serious problem that I've heard of in this regard is that the
NIST-supplied 1003.1 conformance test suite insists on seeing error
returns in cases where the clear intent of 1003.1 was to permit
extensions.  1003.1 specifies two categories of errors:  those that
are required to be reported WHEN THE CONDITION OCCURS, and those that
are required to be reported WHEN THE CONDITION IS DETECTED.  The
distinction is that the latter case covers such things as feeding an
invalid pointer to a function for a buffer address, a case where many
implementations cannot guarantee reliable detection of all possible
abuses (at least, not without an intolerable penalty in execution speed).
In neither case is it generally required that an error occur, if the
implementation is able to provide support for an extension.  For
example, suppose an implementation permitted cross-device hard links.
That would be a nice extension (assuming it could be done well), and
there is no reason to take 1003.1 as forbidding such extensions.

>       The threads subgroup (1003.4A) has attempted to kill the .4 ballot by
>       a block vote for rejection.  One correspondent says they are doing
>       this because .4 is no good without threads.

I'd like to hear an explanation of this assertion.  Certainly, for
years we've been developing real-time applications without support
for threads.  They seem like separable issues to me.

>       ... and a commitment to a direction ISO
>       intends to take for all its standards:  language independence.

Something is not right here, because clearly ISO standards for
programming languages themselves cannot be language-independent.
Perhaps the actual ISO position is that AVOIDABLE language dependence
should be avoided?  I'd like to take the point of view that some
languages are unsuitable for the kind of systems programming that
C was designed for, and it makes no sense to include such languages
when you're talking about systems-programming interfaces.  Does there
really have to be a BASIC binding (or at least support for one) for
1003.4, for example?  I would think not..

>      ....  Adding these new
>      functions would require that the vendor's FORTRAN compiler actu-
>      ally handle REALs.  Think about that.

Using Berkeley's term, it's a "lame" argument!  If one wants a full
Fortran compiler, he specifies conformance to the Fortran standard.
If one wants support for the POSIX system interface, he specifies
1003.1 (or 1003.9) conformance.  And so forth.  It is silly to
expect a standard to accomplish some standardization purpose for
which it was never intended.

Note that there are numerous standard C language features that are
not exercised by the 1003.1 C language binding.  In fact, specifying
1003.1 (C binding flavor) does not guarantee that you even get a C
compiler, much less one that conforms to the C standard.  (For that,
you need to also specify conformance to the C standard.)  Nobody
thought that that was a problem; why is it any different for Fortran?

>       At the last USENIX, in Washington D.C., Jim Isaak, the SEC chair,
>       explained to the well-attended standards BOF that there is really no
>       easy way to dissolve a committee.  If volunteers show up to staff the
>       working group, follow the IEEE rules, and eventually circulate a bal-
>       lot that passes, they've created an IEEE standard.

I think the important thing to recognize is that just because a
standard exists (particularly an IEEE standard, many of which have
in the past been of interest only to small special-interest groups)
does not mean that purchasers have to specify compliance with it.
In particular, it should by no means be automatic that ISO and NIST
promote any and all IEEE standards at the IS and FIPS level.  Only
when there is demonstrable long-term benefit that outweighs the
drawbacks would it be rational to do so.  I think a case could be
made for 1003.1 and 1003.1a, maybe one or two of the other
forthcoming POSIX standards, but certainly not for all of them.

Maybe the thing to do is to lean on Roger Martin, to get him to
take it easy on pushing unwanted standards as FIPS.

Volume-Number: Volume 19, Number 85