Sys V shared mem ??

[Jim Webb]

> I have a question concerning System V.2 and shared memory.  It appears
> (and I may be wrong) possible to do a shared memory attach into your
> data region (we have System V source in house and I can't find any
> checks that prevent this) . That is something like:
> 
>    int shmid, shmflg;
>    char buf[1024];
>    .
>    .
>    (get shmid, set shmflg, etc.)
>    .
>    .
>    shmat (shmid, buf, shflg);
>
>    and access the shared memory segemnt as buf[n].

First off, the implementation of shared memory is HIGHLY machine dependent,
so your (as yet unknow) machine may do shm differently.  However, the way
it is implemented on the vax, the 3b20, and 3b2 does NOT allow one to attach
a shared memory segment to an address already "in use" by the process.

In VERY simple terms, if you set addr=0, the vax attaches the segment at the
nearest page boundary "shmbrk" clicks above your data segment.  This allows
one to sbrk() a bit without running into the shared memory segment.  If you
specify the address, it must be on a page boundary not contained within your
address space.

On the 3b20, the address must be the start of segment not already in use
by the process.

On the 3b2, the address must be the start of a segment in mmu section 3.
This implementation guarantees that the address will never be in conflict,
as user processes are "confined" to mmu section 2.

>                                                     The reason for doing
> something like this is to save one indirection over the normal method
> of just letting shmat() return a pointer the shared memory segment.
> 
>    My question is: What happens to the original contents of buf and
> all the data objects declared after it ?

Why don't you try it and see???  The worst that can happen is the shmat()
will fail...
-- 
Jim Webb             "Out of phase--get help"          ...!ihnp4!hropus!jrw
		"Use the Force, Read the Source"