Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site ecsvax.UUCP
Path: utzoo!watmath!clyde!burl!ulysses!gamma!epsilon!zeta!sabre!petrus!bellcore!decvax!mcnc!ecsvax!bet
From: bet@ecsvax.UUCP (Bennett E. Todd III)
Newsgroups: net.unix
Subject: Re: Sys V IPC: My final word
Message-ID: <1190@ecsvax.UUCP>
Date: Thu, 13-Feb-86 12:44:32 EST
Article-I.D.: ecsvax.1190
Posted: Thu Feb 13 12:44:32 1986
Date-Received: Sat, 15-Feb-86 04:40:36 EST
References: <2666@gatech.CSNET>
Reply-To: duccpc!bet@ecsvax.UUCP (Bennett E. Todd III)
Distribution: net
Organization: Duke University Computation Center
Lines: 54
Keywords: ipc, msg


In article <2666@gatech.CSNET> hope@gatech.CSNET (Theodore Hope) writes:
> [...]
>The man pages for msgop(2) describe the msgbuf struct as containing
>
>	long mtype;     /* message type */
>	char mtext [];  /* message text */
>
> [...] The .h file defines
>
>	struct msgbuf {
>	   long mtype;
>	   char mtext [1];	<- Notice: it says [1]
>	}
> [...]

You should follow net.lang.c; this has popped up there. What you are
seeing is a C hack to permit variable-length structs. What you want to
say is

	struct msgbuf {
		long mtype;	/* message type */
		char mtext [];	/* variable length, NULL-terminated */
	}

but the C compiler croaks on that, so you use an array dimension of 1.
Note that the only member of a struct that can get away with being
varying length is the last member, and that only works because C doesn't
do array bounds checking. So anyway, how do you use it? Like so. Say,
perhaps, I am building messages in my own private array

	char textbuff[MAXMTEXT];

then when I want to pass one in I roll up an empty struct msgbuf as
follows:
	struct msgbuf *tmp_ptr;
	char *malloc();
	...
	tmp_ptr = (struct msgbuf *) malloc(sizeof(struct msgbuf) +
						strlen(textbuff));
	if (tmp_ptr == NULL)
		perror(...);
	strcpy(tmp_ptr.mtext, textbuff);

I kind of like the technique; it allows you to use as much space as
needed and no more, without too much overhead or nuisance. Last I
recall, the consensus was that the technique should be reasonably
portable to any but the most rabidly pathological machine architectures.

-Bennett
-- 

Bennett Todd -- Duke Computation Center, Durham, NC 27706-7756; (919) 684-3695
UUCP: ...{decvax,seismo,philabs,ihnp4,akgua}!mcnc!ecsvax!duccpc!bet