Sys V IPC: My final word

[Stanley Friesen]

In article <2666 at gatech.CSNET> hope at gatech.CSNET (Theodore Hope) writes:
>
>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,
>
        Well, it really isn't that obvious. The man page is *not* a
misprint, and the .h file is "correct" also. What is happening here is
a rather tricky piece of "C" coding to permit *variable* sized arrays
to be passed without allocating all the space necessary for the
maximum size, and without any real maximum size. Basically it is
taking advantage of the fact that "C" doesn't check array subscripts
and the way in which address calculation is done. Basically the
declared array in the struct is only being used as the *base* of the
array. Subscripting off that base will access succesively higher
addresses, so that a unit "array" at the end of a struct can
effectively be extended indefinately, merely by allocating space at
the end of it. The way this is intended to be used is

    struct msgbuf *msgptr;

    msgptr = (struct msgbuf *)malloc(sizeof(struct msgbuf) + sizeof(message));

This way your msgbuf exactly matches the size of your message.

Yeah, I know, a really obscure trick. I know about it because it is
also used in the game Hack.
--

                                Sarima (Stanley Friesen)

UUCP: {ttidca|ihnp4|sdcrdcf|quad1|nrcvax|bellcore|logico}!psivax!friesen
ARPA: ttidca!psivax!friesen at rand-unix.arpa