ronald@robobar.co.uk (Ronald S H Khoo) (10/30/90)
I probably wouldn't be seen dead using the shm* sem* and msg* functions in perl (hurried disclaimer :-) but seeing as they *are* there, is it simply perversity that ftok() is left out? :-) Just a question :-) -- ronald@robobar.co.uk +44 81 991 1142 (O) +44 71 229 7741 (H)
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/31/90)
In article <1990Oct30.123536.12798@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes:
: I probably wouldn't be seen dead using the shm* sem* and msg* functions
: in perl (hurried disclaimer :-) but seeing as they *are* there, is it
: simply perversity that ftok() is left out? :-)
:
: Just a question :-)
I don't know if it's perversity--more like nobody thought about it. From
the man page, though, it looks as though it does little more than encode
the device and inode of the file along with the id character you pass.
I bet it's a one line perl subroutine.
Larrylwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/31/90)
I wrote: : In article <1990Oct30.123536.12798@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: : : I probably wouldn't be seen dead using the shm* sem* and msg* functions : : in perl (hurried disclaimer :-) but seeing as they *are* there, is it : : simply perversity that ftok() is left out? :-) : : : : Just a question :-) : : I don't know if it's perversity--more like nobody thought about it. From : the man page, though, it looks as though it does little more than encode : the device and inode of the file along with the id character you pass. : I bet it's a one line perl subroutine. Here is an approximation that seems to work on a big-endian machine (sun4): sub ftok { -e shift ? unpack("L",pack('ccs',shift,(stat _)[0,1])) : -1; } I don't have a little endian machine to test on, but the byte order might need reversing. The following probably works anywhere that ftok returns a long: sub ftok { if (-e $_[0]) { local($dev, $ino) = stat _; ($_[1] << 24) + (($dev & 0xff) << 16) + ($ino & 0xffff); } else { -1; } } Larry
chip@tct.uucp (Chip Salzenberg) (11/01/90)
According to ronald@robobar.co.uk (Ronald S H Khoo):
>Is it simply perversity that ftok() is left out? :-)
I did the SysV IPC code, so...
A long time ago, when I had nothing better to do, I read the entire
programmer's reference manual for SCO Xenix 2.2. When I came upon
ftok(), I read it carefully, theorized that it simply combined device
and inode, determined that I would never need it, and promptly forgot
that it existed. Sorry about that.
Incidentally, I consider the whole notion of IPC keys (as opposed to
filenames) to be a horrible committee-spawned botch. To me, ftok()
appears to be a bone for the IPC-as-file proponents. I'm not biting.
--
Chip Salzenberg at Teltronics/TCT <chip@tct.uucp>, <uunet!pdn!tct!chip>
"I've been cranky ever since my comp.unix.wizards was removed
by that evil Chip Salzenberg." -- John F. Haugh IIallbery@NCoast.ORG (Brandon S. Allbery KB8JRR) (11/03/90)
As quoted from <10178@jpl-devvax.JPL.NASA.GOV> by lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall): +--------------- | In article <1990Oct30.123536.12798@robobar.co.uk> ronald@robobar.co.uk (Ronald S H Khoo) writes: | : simply perversity that ftok() is left out? :-) | | I don't know if it's perversity--more like nobody thought about it. From | the man page, though, it looks as though it does little more than encode | the device and inode of the file along with the id character you pass. | I bet it's a one line perl subroutine. +--------------- As long as you use the same algorithm as the real ftok(), at least. I have programs that expect to "accept connections" on certain "well-known" shared memory objects, e.g. ftok(ttyname(1), 'c') to view and alter csl and cslmsp configuration. ++Brandon -- Me: Brandon S. Allbery VHF/UHF: KB8JRR on 220, 2m, 440 Internet: allbery@NCoast.ORG Packet: KB8JRR @ WA8BXN America OnLine: KB8JRR AMPR: KB8JRR.AmPR.ORG [44.70.4.88] uunet!usenet.ins.cwru.edu!ncoast!allbery Delphi: ALLBERY