Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!husc6!think!ames!nrl-cmf!cmcl2!brl-adm!adm!Ed@mead.scrc.symbolics.com From: Ed@mead.scrc.symbolics.com (Ed Schwalenberg) Newsgroups: comp.unix.wizards Subject: shared memory under SysV Message-ID: <14379@brl-adm.ARPA> Date: 14 May 88 00:19:12 GMT Sender: news@brl-adm.ARPA Lines: 39 Date: Wed, 11 May 88 01:50 EST From: EE784@sscvax.mcmaster.ca 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: ... 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 questions are: 1) what is the proper return value of shmat on failure; At least in the AT&T/Intel/Interactive System V for the 386, you can only attach shared memory segments on 4Meg boundaries. NULL is on a 4Meg boundary, but -1 is not. Normally, of course, your text segment lives at 0, but perhaps you can make an executable with the text segment elsewhere, and use segment 0 for shared memory. 2) if it is -1, is it int or long (should be long, I believe). Any other insights cheerfully accepted. --mike borza