Variable-length messages.

[Lloyd Zusman]

We have a difference of opinion at our site as to what is the most
desirable way to handle variable-length messages in C.  This is
basically a difference in philosophies.  I'm showing you folks on the
net the two opposing approaches in question here, and I would like to
find out which of these each of you prefers and why.

First of all, the problem:

I am writing a library of routines to handle message passing.  These
messages consist of, among other things, a message type, a length, and
a message body.  The message body can be of any length, depending on
the message type.  The users of this library can define their own
message types, and hence the message-passing routines cannot determine
the message length from the context of the message.

One group of us here says it's OK to handle this case as follows:

	struct message {
		int msgType;		/* msg type code */
		int msgLength;		/* length of msg body */
		char msgBody[1];	/* variable length msg body */
	};


	/* routine for sending a message */
	int
	sendMessage(fd, msg)
	int fd;				/* file descriptor of message socket */
	struct message *msg;		/* pointer to message */
	{}
		Send the message pointed to by 'msg' through the socket
		associated with file descriptor 'fd'.  The length is
		contained in the message structure.

	/* routine for receiving a message */
	int
	receiveMessage(fd, msg, length)
	int fd;				/* file descriptor of message socket */
	struct message *msg;		/* pointer to message */
	int length;			/* length of message buffer */
	{}
		Receive a message into the message buffer pointed to by
		'msg'.  The 'length' parameter is the size of this buffer
		and it must be large enough to hold the largest message that
		might be received.  The message comes through the socket
		associated with the file descriptor 'fd'.

Another group says that since the 'msgBody[1]' field really isn't one
byte long, its use is misleading and would confuse programmers and
debugging software, not to mention the fact that they feel it isn't
"pure".  Since C doesn't support this sort of variable-length
structure as part of the language, these people say we cannot do what
is outlined above, but must define our message-passing constructs as
follows:

	struct message_header {
		int msgType;			/* msg type code */
		int msgLength;			/* length of msg body */
	};


	/* routine for sending a message */
	int
	sendMessage(fd, header, body)
	int fd;				/* file descriptor of message socket */
	struct message_header *header;	/* pointer to message header */
	char *body;			/* pointer to message body */
	{}
		Send the message whose header is pointed to by 'header'
		and whose body is pointed to by 'body' through the socket
		associated with file descriptor 'fd'.  The length is
		contained in the message structure.

	/* routine for receiving a message */
	int
	receiveMessage(fd, header, body, length)
	int fd;				/* file descriptor of message socket */
	struct message_header *header;	/* pointer to message header */
	char *body;			/* pointer to message body */
	int length;			/* length of message body buffer */
	{}
		Receive a message into the message header pointed to by
		'header' and the message body pointed to by 'body'.  The
		'length' parameter is the size of the message body buffer
		and it must be large enough to hold the largest message body
		that might be received.  The message comes through the socket
		associated with the file descriptor 'fd'.

I realize that both constructs could be implemented.  I also realize that
the above examples are oversimplifications for the purpose of illustrating
these two opposing philosophies.  All I am interested in here is to find
out the preferences of the C gurus out there in netland as to which one
of the two variations they prefer.  Is there an "accepted practice" in this
area?  Is it really a no-no to use the 'msgBody[1]' construct as defined
above?

I assume this would be of general interest and could generate a
debate, so please post replies to the net.

Sincerely,

--
  Lloyd Zusman                  Internet:  ljz at fx.com
  Master Byte Software                  or ljz%fx.com at ames.arc.nasa.gov
  Los Gatos, California                 or fxgrp!ljz at ames.arc.nasa.gov
  "We take things well in hand."    uucp:  ...!ames!fxgrp!ljz
  [ our Internet connection is down: use uucp or mail to the entry above it ]