Many thanks for all that background to the origins of void pointers.
Now for applying that to the early sockets API.
In the first (1981) and second (4.1a, April 1982) revision of that API, socket addresses were passed as a fixed 16-byte structure, essentially the same as the current struct sockaddr. By the time of the third revision (4.1c/4.2, 1983) of that API it had become a variable sized opaque object, passed around as a pointer and a size.
The 1983 4.2BSD system manual (http://www.cilinder.be/docs/bsd/4.2BSD_Unix_system_manual.pdf) describes it that way, e.g. defining connect() as:
connect(s, name, namelen);
int s; caddr_t name; int namelen;
Note the use of caddr_t in the user level signature. Yet, the actual source code for 4.1c/4.2 BSD only uses caddr_t in the kernel (as pointed out on this list), but continues to use struct sockaddr * in the user land interface. It would seem to me today that void * would have been a more logical choice and with void * having been around for about 3 years in 1983, it might have seemed logical back then as well -- after all, this use case is similar to the malloc() use case. It would have avoided the need for a longish type cast in socket api calls (without further loss of type safety, as that was already lost with the required cast from e.g. struct sockaddr_un* to struct sockaddr* anyway).
Related to this, from the "4.2bsd IPC Primer” (1983, https://www2.eecs.berkeley.edu/Pubs/TechRpts/1983/CSD-83-145.pdf , page 5), it would appear that the format of socket addresses was perhaps unfinished business:
- Apparently at some point in time simple strings were considered as unix domain addresses, i.e. not a sockaddr_un structure. Maybe it was limping on this thought that caused the prototype soackaddr structure not to have a size field — having had that would have simplified the signature of many socket API functions (interestingly, it would seem that such a size field was added in 4.3BSD some 6, 7 years later).
- The examples show no type casts. This may have been for didactical clarity, but perhaps it also suggests a signature with void* semantics.
I’d be happy for any background on this.
Also, about halfway down this page http://tech-insider.org/vms/research/1982/0111.html there is mention of CSRG technical report #4, "CSRG TR/4 (Proposals for the Enhancement of Unix on the Vax)”. I think this may be the initial discussion document from the summer of 1981 that evolved into the 4.2 system manual. Would anybody have a copy of that document?
Paul
Ok... so I got vi to work full screen in a telnet session to the DZ port in V8. BTW TERM=vt132 seems to be the best option given the existing termcap. Yay. Now I'm a happy camper with my v8 instance and I'm reading Rochkind's book and learning lots more about everything from unix error codes to system programming etc. V8 is much more familiar ground to me than earlier versions (mostly vi) at this point.
Anyway, my first question of the day is this - is vt132 the best that I can do terminalwise?
I'm not totally up to speed on terminals in ancient (or modern) unices, but I've been reading, and it seems that if I can match a termcap entry to my emulated terminal with a majority of available capabilities, that I would reach screen nirvana in my instance. Now, it also seems like my mac will emulate different terminals and defaults to something like xterm-256. I don't expect color to be supported, but I don't really know. This leads to a second question, if I take an xterm termcap entry and put it in my termcap file, will it work better than the vt entries?
Is my logic correct, or am I thinking incorrectly about this?
Sidenote: now that I'm in v8 and having used v6 and v7 - McIlroy's reader actually is much, much more interesting and handy! Thanks, Doug!
Sent from my iPhone
Sent from my iPhone
What should I set TERM to on V8 to get the best results on my Mac
Terminal. If I set it to vt52, vt100, or vt132, only 8 lines appear at
the bottom of the terminal window (of about 24 lines):
---
root::0:4:m0130,m322:/:
daemon:x:1:1:m0000,m000:/:
sys:sorry:2:1:m0130,m322:/usr/sys:no-login
bin:sorry:3:4:m0130,m322:/bin:
ken:sorry:6:1:m0130,m322:/usr/ken:
dmr:sorry:7:4:mh1092,m069:/usr/dmr:
nuucp::238:1:mh2019,m285,uucp:/usr/spool/uucppublic:/usr/lib/uucp/uucico
uucp::48:1:mh2019,m285,nowitz:/usr/lib/uucp:
"passwd" 20 lines, 770 characters
----
The 8 line window works about like I'd expect - the arrow keys move up
and down until the screen needs to scroll, then B's and A's show up. I'm
used to that on BSD. Using the j and k keys work better and when I
scroll down enough lines, the lines move up to fill the whole terminal
window and the file can be edited in the full window. Is there a better
TERM setting that will get 24 lines to show up on file open?
Thanks,
Will
--
GPG Fingerprint: 68F4 B3BD 1730 555A 4462 7D45 3EAA 5B6D A982 BAAF
As has been explained, void came from Algol 68 via Steve Bourne.
As no object could be declared void, void* was a useless
construct. A kind of variable that could point to any object
was required to state the type of useful functions like qsort.
To avoid proliferation of keywords, the useless void* was
pressed into service. I do not remember who suggested that.
Doug
> From: Clem Cole
> typing hard started to become more important in the kernel.
I can imagine! The V6 kernel had all sorts of, ah, 'unusual' typing - as I
learned to my cost when I did that hack version of 'splice()' (to allow a
process in a pipline to drop out, and join the two pipes together directly),
which I did in V6 (my familiar kernel haunt).
Since a lot of code does pointer math to generate wait 'channel' numbers,
e.g.:
sleep(ip+2, PPIPE);
when I naively (out of habit) tried to declare my pointers to be the correct
type, the math didn't work any more! ('ip', in this particular case, was
declared to be an 'int *'.)
No doubt part of this was inherited from older versions (of the system, and
C); the code was working, and there was no call to tweak it. The lack of
casts/coercion in the V6 C compiler may have been an issue, too - I had to do
some equally odd things to make my splice() code work!
Noel
This caught my attention. Did early C really have min and max? Were they used for anything? In those days I was a BCPL user, which IIRC, did not have such things.
-Larry
> Begin forwarded message:
>
> From: Leo Broukhis <leob(a)mailcom.com>
> Subject: [Simh] An abandoned piece of K&R C
> Date: 2017, November 3 at 1:14:42 AM EDT
> To: "simh(a)trailing-edge.com" <simh(a)trailing-edge.com>
>
> https://retrocomputing.stackexchange.com/q/4965/4025 <https://retrocomputing.stackexchange.com/q/4965/4025>
>
> In the UNIX V7 version of the C language, there were the /\ (min) and the \/ (max) operators. In the source of the scanner part of the compiler,
>
> case BSLASH:
> if (subseq('/', 0, 1))
> return(MAX);
> goto unkn;
>
> case DIVIDE:
> if (subseq('\\', 0, 1))
> return(MIN);
> ...
>
> However, attempting to use them reveals that the corresponding part in the code generator is missing. Trying to compile
>
> foo(a, b) { return a \/ b; }
>
> results in
>
> 1: No code table for op: \/
>
> The scanner piece survived in the copies of the compiler for various systems for several years. I tried to look for copies of the code generator table which would contain an implementation, but failed. Has anyone ever seen a working MIN/MAX operator in K&R C?
>
> Thanks,Leo
>
> _______________________________________________
> Simh mailing list
> Simh(a)trailing-edge.com
> http://mailman.trailing-edge.com/mailman/listinfo/simh
Am I the only one having trouble? I mirror the site, and I'm now seeing:
aneurin# tuhs
+ rsync -avz minnie.tuhs.org::UA_Root .
rsync: failed to connect to minnie.tuhs.org (45.79.103.53): Operation timed out (60)
rsync error: error in socket IO (code 10) at clientserver.c(125) [Receiver=3.1.2]
+ rsync -avz minnie.tuhs.org::UA_Applications Applications
rsync: failed to connect to minnie.tuhs.org (45.79.103.53): Operation timed out (60)
rsync error: error in socket IO (code 10) at clientserver.c(125) [Receiver=3.1.2]
Etc.
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
UNIX was half a billion (500000000) seconds old on Tue Nov 5 00:53:20
1985 GMT (measuring since the time(2) epoch) -- Andy Tannenbaum.
(Yeah, an American billion, not the old British one.)
--
Dave Horsfall DTM (VK2KFU) "Those who don't understand security will suffer."
Date: Tue, 10 Oct 89 13:37 CDT
From: Chris Garrigues <7thSon(a)slcs.slb.com>
Subject: A quote from Interop '89
To: unix-haters(a)ai.ai.mit.edu
Cc: 7thSon(a)slcs.slb.com
"We all know that the Internet is Unix. We proved that last
November."
- David Mills, October 2, 1989
