shmat() system call?

[BURNS,JIM]

in article <9763 at discus.technion.ac.il>, devil at techunix.BITNET (Gil Tene) says:
[I write:]
>>I don't see why not. The shmget(2) routine specifies the memory block
>>size. All the shmat(2) routine does is return a pointer to the beginning
>>of that block (by default). The same block is returned to different
>>processes if they use the same shmid returned by shmget(2). Adapted from
>>the HP 9000/800 HP-UX Real Time Programmers Manual:

> HP-UX DOES NOT map to the same address, and this software had
> shared POINTERS. This was easy to fix, as most pointers can be
> replaced with offsets, and workarounds can be done for anything else.

Perhaps I didn't make myself clear: While shmat() may or may not return
the same address to each process, it should be irrelevant. The purpose of
shmat() is to let the system provide you the base address so you don't
have to hardcode/guess/calculate the base yourself. I agree with the
numerous posters who say share offsets from this base, not the base
itself.

Probably the easiest way to do this is do typedef a structure, then assign
the return value of shmat() to a pointer to this structure. Then you can
use ptr->fieldname for everything of relevance, and #include these
definitions in each program. (Naturally, use the same compiler for each
program to avoid alignment problems with the structure. When the compiler
&/or the OS change, the alignment may change, but the relative offset
BETWEEN programs does not, so a program that writes to that field will
write to the same location as a program that reads that field. If this
didn't work, FORTRAN programmers wouldn't be able to put COMMON blocks in
shared memory, which I do.)
-- 
BURNS,JIM
Georgia Institute of Technology, Box 30178, Atlanta Georgia, 30332
uucp:	  ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt0178a
Internet: gt0178a at prism.gatech.edu