shared memory under SysV

[EE784 at sscvax.mcmaster.ca]

In answering another query in this newsgroup, I got to thinking about
how I'd interpreted the original documentation for a return value from
one of the shared memory functions.  Presumably there are:
        1) others who have also thought about this question;
        2) others who know the answer.
Under uPort sysV/AT (a system V, rev. 2 port to IBM AT and clones [swapping,
not paging:-) ]) shared memory is supported for, among other things, using
the memory-mapped video RAM.  The man pages for the various shm(2) calls
give the following synopses:

        int shmid ( key, size, shmflg )
        key_t key;
        int size, shmflg;

        char *shmat ( shmid, shmaddr, shmflg )
        int shmid;
        char *shmaddr;
        int shmflg;
        [stuff about detaching deleted]

and say the following about the return value of shmat:

        Upon successful completion, the return value is as follows:
                Shmat returns the data segment start address of the
                attached shared memory segment.
                [stuff about detaching deleted]
        Otherwise, a value of -1 is returned and errno is set to
        indicate the error.

Since shared memory is available only under the large model, pointers are
32 bits.  There is no apparent reason that a pointer cannot assume the
equivalent of -1 for valid addresses (although trying to use it will
probably generate a memory exception, since I certainly don't have that
much physical memory).  My initial temptation was to assume the
documentation was wrong and that a NULL pointer should be returned if
shmat fails; however, the doc'n went out of its way to indicate that it
should be -1 (presumably -1L) on failure.  So the code that uses it
looks like:

        int gfx_id, shmget ();
        unsigned g_plane_siz = 32768U;
        char *gfx_ptr, *shmat ();
        key_t gfx_key;

        if (( gfx_id = shmget ( gfx_key, g_plane_siz, 0 )) == -1 ) {
                perror ();
                exit ( 1 );
        }
        gfx_ptr = shmat ( gfx_id, (char *)NULL, 0 );
        if ( (long)gfx_ptr == -1L ) {
                perror ();
                exit ( 1 );
        }

The original key is assigned at boot time to make the graphics memory
public, and shmflg (== 0) is effectively ignored.  So, the code works,
and there is no good reason why the attach should fail if the key is
available, but I've always been bothered about the test on gfx_ptr.
The other obvious anomaly here is that the documentation indicates
that g_plane_siz must be int, but uPort's own examples assume it is
unsigned, and this in fact works.

So, the questions are:
        1) what is the proper return value of shmat on failure;
        2) if it is -1, is it int or long (should be long, I believe).
Any other insights cheerfully accepted.

--mike borza    <EE784.SSCvax.McMaster.CA>