Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!seismo!brl-smoke!gwyn
From: gwyn@brl-smoke.ARPA (Doug Gwyn )
Newsgroups: net.unix
Subject: Re: Sys V IPC: My final word
Message-ID: <974@brl-smoke.ARPA>
Date: Sat, 15-Feb-86 22:39:27 EST
Article-I.D.: brl-smok.974
Posted: Sat Feb 15 22:39:27 1986
Date-Received: Tue, 18-Feb-86 04:21:14 EST
References: <2666@gatech.CSNET>
Reply-To: gwyn@brl.ARPA
Organization: /usr/local/lib/news/organization
Lines: 38

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 */
>
>This kind of struc, especially in a syscall-passing sense, seems odd to me.
>It is obvious that mtext should be
>
>	char mtext [some_number];
>
>"Oh," said I.  "I'll bet that's a misprint.  Let's look at the <sys/msg.h>
>file to see what they _really_ mean."  Well, surprise.  The .h file defines
>
>	struct msgbuf {
>	   long mtype;
>	   char mtext [1];	<- Notice: it says [1]
>	}
>
>Am I overlooking something obvious?  After looking through the kernel source,
>it appeared that the msgsnd and msgrcv syscalls expect the data to start at 
>msg.mtext, so by defining my own structs as
>
>	struct Msgbuf {
>	   long mtype;
>	   char mtext [MAXMTEXT];
>	}
>
>everything is ok.

You got it right.  The C language provides no way to declare
a variable-length array in a struct, so the prototype in the
documentation and the declaration in the header file represent
the array as best they can.  From a design standpoint it would
have been preferable for the struct to have contained a
pointer to the message buffer rather than the buffer itself,
but that's not the way they designed it.