The Unix Heritage Society mailing list
 help / color / mirror / Atom feed
From: norman@oclsc.org (Norman Wilson)
Subject: [TUHS] long lived programs
Date: Thu, 05 Apr 2018 17:03:02 -0400	[thread overview]
Message-ID: <1522962186.9871.for-standards-violators@oclsc.org> (raw)

Steve Johnson:

  But in this case, part of the requirement was to pass some standard
  simulation tests (in FORTRAN, of course).  He was complaining that
  these programs had bugs and didn't give the right answer.

====

This reminds me of an episode during my time at Bell Labs.

The System V folks wanted to make pipes that were streams;
our experience in Research showed that that was useful.  We'd
done it just by making pipe(2) create a stream.  This caused
some subtle differences in semantics (pipes became full-duplex;
writing to a pipe put a delimiter in the stream, so that a
corresponding read on the other end would stop at the delimiter;
write(pipefd, "", 0) therefore generated something that would
make read(pipeotherfd, buf, len) return 0).  We'd been running
all our systems that way for a while, and had uncovered no
serious problems.

But the System V folks were very nervous about it anyway, and
wrote a planning document in which they proposed to create a
new, different system call to make stream pipes.  pipe(2) would
make an old-fashioned pipe; spipe(2) (or whatever it was called,
I forget the name) had to be called to get a stream.  The document
didn't really explain the justification for this.  To us in
Research it just sounded crazy.

Someone else was going to attend a meeting with the developers,
but at the last minute he had a conflict, so he drafted me to
go.  Although I can be pretty blunt in writing, I try not to be
so much so in person when dealing with people I don't know; so
rather than asking how they could be so crazy as to add a new
kind of pipe, I asked why they really thought it necessary.

It took a little probing, but the answer turned out to be that
their management insisted that everything pass an official
verification suite to prove compliance with the System V,
Consider It Standard; and said verification suite didn't just
check that the first file descriptor returned by pipe(2) could
be read and the second written, it insisted that the first could
not be written and the second not read.  Full-duplex pipes didn't
meet the standard, it was claimed.

I asked what exactly is the standard?  The SVID, I was told.

What does the SVID really say, I wondered?  We got a copy and
looked up pipe(2).  According to the official standard, the
first file descriptor must be readable and the second writeable,
but there was no statement that it couldn't work the other way too.
Full-duplex pipes did in fact meet the standard; it was the
verification suite that, in an excess of zeal, didn't conform.

The developers were absolutely delighted with this.  They too
thought it was stupid to have two different kinds of pipes,
particularly given our experience that full-duplex delimited
pipes didn't break anything.  They were very happy to have
Research not just yell at them for doing things differently
from us, but help them figure out how to justify doing things
right.

I don't know just how they took this further with management,
but as it came out in SVr4, pipe(2) returned a full-duplex
stream.  This is still true even unto Solaris 10, where I just
tested it.

I made friends that day.  That developer group kept in touch
with me as they did further work on pipes, the terminal driver,
pseudo-ttys, and other things.  I didn't agree with everything
they did, but we were able to discuss it all cordially.

Sometimes the verification program just needs to be fixed.
And sometimes the developers that seem set on doing the wrong
thing really want help in subverting whatever is forcing that
on them, because they really do know what the right thing is.

Norman Wilson
Toronto ON


             reply	other threads:[~2018-04-05 21:03 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-05 21:03 Norman Wilson [this message]
2018-04-05 21:23 ` Clem Cole
2018-04-05 21:38   ` Bakul Shah
2018-04-06  2:03     ` Random832
2018-04-06  4:27       ` Warner Losh
2018-04-06  4:31         ` Jon Steinhart
2018-04-06  4:58         ` Steve Nickolas
2018-04-06  5:02           ` Jon Steinhart
2018-04-06  4:29       ` Steve Johnson
2018-04-06  5:57       ` Bakul Shah
2018-04-06 21:52         ` Peter Jeremy
2018-04-05 22:46   ` Arthur Krewat
2018-04-05 23:23   ` Paul Winalski
2018-04-05 23:33     ` Arthur Krewat
2018-04-06  0:05       ` Toby Thain
2018-04-06  4:51 ` Dave Horsfall
2018-04-06 15:00 ` Tony Finch
2018-04-07 20:41 ` Paul Winalski
  -- strict thread matches above, loose matches on Subject: below --
2018-04-06 22:33 Doug McIlroy
2018-04-07  1:01 ` Paul Winalski
2018-04-07  1:09   ` Larry McVoy
2018-03-23 18:27 [TUHS] long lived programs (was Re: RIP John Backus Bakul Shah
2018-03-23 20:50 ` [TUHS] long lived programs Steve Johnson
2018-03-23 21:07   ` Clem Cole
2018-03-23 15:51 Ron Natalie
2018-03-23 15:57 ` Clem Cole
2018-03-23 16:25   ` Lars Brinkhoff
2018-03-23 16:59     ` Lawrence Stewart
2018-03-23 17:31       ` Steve Nickolas
2018-03-23 16:32   ` Ron Natalie

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1522962186.9871.for-standards-violators@oclsc.org \
    --to=norman@oclsc.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).