Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.1 6/24/83; site mordor.UUCP
Path: utzoo!watmath!clyde!burl!mgnetp!ihnp4!houxm!houxz!vax135!cornell!uw-beaver!tektronix!hplabs!hao!seismo!ut-sally!mordor!jdb
From: jdb@mordor.UUCP (John Bruner)
Newsgroups: net.lang.c
Subject: Re: Variable-length string at end of structure
Message-ID: <4077@mordor.UUCP>
Date: Sat, 23-Jun-84 16:24:41 EDT
Article-I.D.: mordor.4077
Posted: Sat Jun 23 16:24:41 1984
Date-Received: Thu, 28-Jun-84 00:42:39 EDT
References: <483@wjh12.UUCP>
Organization: S-1 Project, LLNL
Lines: 38

I've used this trick in a number of programs, usually for symbol
tables and the like.  The last element of my structures is
always a one-element character array.

Several years ago, when I was first maintaining APL\11 at Purdue/EE,
I had to transport it from V6 PDP-11's running the photo7 C
compiler to a VAX running 32/V.  The program had compiled without
a hitch on Ritchie's compiler, but the pcc-derived VAX compiler
produced roughly 800 error messages.  One of them related to the
"item" structure that APL was using.  The structure was defined as:

	struct item
	{
		char	rank;
		char	type;
		int	size;
		int	index;
		data	*datap;
		int	dim[0];
	};

(This structure appears at the beginning of each data item.  Space is
allocated for the structure, "rank" elements of the array "dim", and
"size" double-precision floating-point numbers which specify the data.)

Ritchie's compiler accepted this (and perhaps still does today), but
"pcc" complained about the zero-element array "dim".  I had to recode
it so that "dim" was declared with a non-zero number of dimensions
and then fudge the allocation so that the same amount of space was
allocated.
--
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor.ARPA [jdb@s1-c]	(415) 422-0758
  UUCP: ...!ucbvax!dual!mordor!jdb 	...!decvax!decwrl!mordor!jdb
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  MILNET: jdb@mordor.ARPA [jdb@s1-c]	(415) 422-0758
  UUCP: ...!ucbvax!dual!mordor!jdb 	...!decvax!decwrl!mordor!jdb