J
Mir ist auch keine Betriebssystem-unabhängige Version bekannt, würde mich ggf. aber auch brennend interessieren.
Eine Idee ist z.B. auch: Mittels Ausprobieren durch Aufruf von shmget() mit sukzessiver Verdopplung der Größe. Igendwann wird dann wohl ein Fehler auftreten, wenn die Grenze erreicht ist. Das Vorgehen kann man direkt zur Laufzeit machen oder, falls es ein größeres Programmpaket mit Installations-Script ist, mittels eines separaten Programms, das man in einem Makefile anwirft und dann das Ergebnis in eine include-Datei überträgt, die dann anschließend beim Compile-Lauf des eigentlichen Programms benutzt wird. Dann natürlich daran denken, dass die vielen angelegten Test-shm's mittels shmctl(..,ICP_RMID,..) schön wieder gelöscht werden.
Ich habe selbst ein großes Programmpaket entwickelt, was auf diversen Unix-Systemen läuft (z.B. Linux FC3, RedHat8, Solaris 9, NetBSD, Reliant Unix) und intensiv mit Shared Memories arbeitet, insgesamt je nach Konfiguration zwischen 200-1000 Bereichen. Allerdings nicht mit immens großen. Deswegen der Tipp, falls Du den shm-Bereich über Semaphoren absichern willst (und das Betriebssystem-unabhängig): Bei Sun/Solaris wird beim semctl() Aufruf eine Union "semun" benutzt, während bei anderen Betriebssystemen nur ein integer-Wert benutzt wird...
Mich würde aber schon mal so grob interessieren, was in das shm eigentlich rein soll. So richtig kann ich mir keine Anwendung vorstellen, die einen so riesigen shm-Bereich nutzen sollte (es sei denn, man will eine ganze Datenbank darin unterbringen).