Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!sri-spam!ames!ucbcad!ucbvax!hplabs!hpcea!hpfcdc!rml
From: rml@hpfcdc.UUCP
Newsgroups: comp.unix.questions
Subject: Re: System V.2 IPC (msgop - message passing) ?
Message-ID: <5740007@hpfcdc.HP.COM>
Date: Thu, 16-Apr-87 16:42:50 EST
Article-I.D.: hpfcdc.5740007
Posted: Thu Apr 16 16:42:50 1987
Date-Received: Sun, 19-Apr-87 01:11:22 EST
References: <419@artecon.artecon.UUCP>
Organization: HP Ft. Collins, Co.
Lines: 31

> For structures allocated at run time, you can just "malloc" a block
> of memory containing "sizeof (int)" plus
> maximum-message-size-for-that-structure bytes and cast the resulting
> pointer to a pointer to a "struct msgbuf".

For maximum application portability it's probably safer to add
sizeof(struct msgbuf) than sizeof(int).  For one thing, mtype is a long,
not an int, in SVID (and implementations that I know of), so if anything
it should be sizeof(long) rather than sizeof(int); but that illustrates
a potential problem.  It's also possible that some machine would have
some strange alignment rules requiring padding between the long and the
array.  This also works for systems which choose to add extra fields to
the msgbuf structure ( such system would run into importability problems
as Guy points out, but it's safest for your code).

For the same reasons, this is safer than any of the mechanisms for
using static structures.

> So, anyone know the story??  This is not an isolated case, as both
> HP-UX (based on sys V) and even Sun's System V compatibility mode
> use this same definition (char mtext[1]).

For any vendor to do otherwise would reduce importability of code; there's
diminishing value in being N% System V compatible when N is less than 100.
There are lots of things most vendors (including AT&T) would change
about System V given freedom from compatibility issues.

		Bob Lenk
		{ihnp4, hplabs}!hpfcla!rml

Standard disclaimer: my opinions, not HP's.