> From: Rob Pike
> Convenient though the shorthand may be, it always bothered me as
> inconsistent and misleading.
As someone who made very extensive use of procedure pointers (most notably in
upcalls, which never caught on, alas), I couldn't agree more.
Two very different things are happenging, but with the shorthand notation,
they share an identical representation. And for what? To save three characters?
Noel
> From: Derek Fawcus
> I think he means something like:
> (*((*((*((*f)()->g))()->h))()->i))()
So I've been confused by this thread, and I'm hoping someone can deconfuse me
- but I think I may have figured it out.
What's confusing me is that in C, the -> operator is followed by "an
identifier [which] designates a member of a structure or union object" (I
checked the spec to make sure my memory hadn't dropped any bits) - but g, h
above are arguments; so I couldn't figure out what was going on.
I think what may have happened is that initially the discussion was about C
("Pretty sure it was not in v7 C"), but then it switched to C++ - with which
I'm not familiar, hence my confusion - without explicitly indicating that
change (although the reference to Bjarne Stroustrup should been a clue). (And
that's why I thought "f()->g()->h()->i()" was ad hoc notation for "calls f(),
then calls g()".)
Am I tracking now?
Noel
> From: Rob Pike
> To make chaining of calls simpler. Write
> f()->g()->h()->i()
> the other way
You mean:
(*f)((*g)((*h)((*i)())))
I dunno, it doesn't seem that much worse to me.
What I like about the explicit notation (i.e. (*f) ()) is that it forces the
programmer to recognize what's going on.
On the other hand, I guess, the whole concept of compiled languages is to get
the programmer's nose out of the low-level details, so they can focus on the
high level. So I guess one could see allowing f() in place of (*f)() as an
instance of that.
Then again, down that road you find a lot of modern code, where a programmer
writes something that is e.g. horribly inefficient and slow, precisely because
they are so divorced from the low-level of what the code they wrote turns into...
Still, I'd be a little worried about a program doing (*f)((*g)((*h)((*i)()))),
no matter what the notation was; it would be awfully hard to recognize what
all the possible call chains are. But then again I guess a lot of e.g. AI code
does things like that...
Noel
> From: moanga
>> To make chaining of calls simpler. Write
>> f()->g()->h()->i()
Ah; I was confused by his notation; I didn't realize he meant the C operator
'->'.
Noel
>> why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication.
> My understanding is that the single file descriptor broke the open-file
> model, which had a single read/write pointer. Two-way communication via
I’m not sure I understand.
In the implementation, the read pointer is file location offset (“fp->f_offset”) and the write pointer is the file size (“ip->i_size”). The location offset on the writing end of the pipe is always zero, and on the reading end it moves between zero and PIPSIZ (but that is unobservable).
I just tried making both pipe ends readable+writeable in my “V6.5” kernel and that appears to work. It allows for bi-directional communication in a half-duplex sense (i.e communicating walky-talky style). The other benefit is using just one file descriptor, at a time when a process had just 15 to work with.
Maybe the issue was that two sides writing to a full pipe at the same time will cause deadlock?
I asked a friend who was around at the time (I think he and
Rob worked together at times). Here's what he recalls:
I'll keep it going. rc was a description that it was the worst movie
ever. And was for many years listed as the worst system ever (except
for all the others) in a mish-mash of creative naming... I have no clue
if this is true, and I'm honestly having trouble recalling his name.
It wasn't my intention.
There was a description that it was a startup script from very early
times in Unix, shortened, as Ken was wont to do, from runcom, the nearest
thing CTSS had to a shell--it could run up to six prespecified commands
in background. It wasn't a 'big name' like Evi, but I don't know if I buy
it, that plan 9 from outer space poster hanging. Plan 9 from Bell Labs
as all these themes flowed together in a mish-mash of creative naming...
With a different name, it could be the lack of information, those who
guess at reasons for naming generate volumes of apocrypha.
The real reason is usually, ``because''.* Trust me, there are even
worse movies... Someone posted some pictures of the names tell you
anything helpful. Despite the lack of televised sports getting to me
in these shelter-in-place days, but, I mean, sure, I guess I'll throw
in some bucks for a pay-per-view of a Pike/Thompson cage match. FIGHT!
Followups set.
Things are named usually because the name is "Plan 9 from outer space
poster hanging. None of the office area at Murray Hill to this list.
Plan 9 is the worst system ever (except for all the others) in a
knod to Churchill (supposedly based on his comment about Democracy).
And from there it was 25 years ago and beer was involved). It makes
a great story, but I don't think there's much doubt about it. And was
for many years listed as the worst movie ever, including the formative
years of plan 9. Yes, but is there anything besides the name? There is
a widespred anecdote that "Plan 9" name comes from the movie until the
end (what a pain!).
_-_-_-_-Mark
Norman Wilson
Toronto ON
> why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication.
My understanding is that the single file descriptor broke the open-file
model, which had a single read/write pointer. Two-way communication via
Doug
Was looking into pipes.
For the 3rd Edition TUHS does not have source, but is does have a man page. In V3, pipe returns a single file descriptor that echoes whatever is written back upon reading. The pipe buffer capacity is 504 bytes.
The surviving ‘nsys’ source for V4 does not yet include the source for pipes, but the man page for 4th edition pipes has - more or less - the well known semantics, including the 4096 byte buffer capacity.
Does anyone remember:
- why the single fd approach was abandoned? To its credit, it appears to allow for limited 2-way communication. Maybe the reason was that it becomes harder to detect broken pipes?
- whether the V3 implementation was based on an in-memory approach and not the later 'anonymous backing file’? The 504 byte buffer capacity suggests a single buffer page minus some header info.
Greetings,
So this happened: https://bsdimp.blogspot.com/2020/04/finding-kermit-4x.html
tl;dr: while obsessing over 4C(052) kermit that's in Rainbow Venix, I found
a lot of cool "lost" source code versions of Kermit... All except the one I
was looking for.
Warner
Whilst spelunking in the V8 source code I came across this dozen lines:
http://chiselapp.com/user/pnr/repository/v8unix/artifact/2782d26fa2930724?l…
It implements the /dev/stdin, /dev/stdout and /dev/stderr devices (the variable ‘file_no’ in above code snippet is the constant 40, which is the major number of these devices). It would seem that this handful of lines could have been in Unix as early as 4th Edition — but they weren’t. Maybe it was not seen as useful.
As far as I can tell this bit of code originates in 8th Edition, with no earlier precursors. It does not seem to be in its man pages.
Who added this neat little innovation?
