Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!jarthur!elroy.jpl.nasa.gov!jpl-devvax!lwall
From: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Newsgroups: comp.lang.perl
Subject: Re: ftok() ?
Message-ID: <10179@jpl-devvax.JPL.NASA.GOV>
Date: 30 Oct 90 22:56:23 GMT
References: <1990Oct30.123536.12798@robobar.co.uk> <10178@jpl-devvax.JPL.NASA.GOV>
Reply-To: lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall)
Organization: Jet Propulsion Laboratory, Pasadena, CA
Lines: 33

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