Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!uflorida!novavax!twwells!bill From: bill@twwells.com (T. William Wells) Newsgroups: comp.lang.c Subject: Re: Zero Length Arrays Allowed in C Standard? Message-ID: <1989Dec7.125544.7795@twwells.com> Date: 7 Dec 89 12:55:44 GMT References: <2298@jato.Jpl.Nasa.Gov> <11715@smoke.BRL.MIL> <480@codonics.COM> <1989Dec2.210042.12668@twwells.com> <8129@cg-atla.UUCP> <1989Dec5.112553.24087@twwells.com> <4733@solo11.cs.vu.nl> Organization: None, Ft. Lauderdale, FL Lines: 43 In article <4733@solo11.cs.vu.nl> maart@cs.vu.nl (Maarten Litmaath) writes: : In article <1989Dec5.112553.24087@twwells.com> : bill@twwells.com (T. William Wells) writes: : \... : \Consider a symbol table that is used to store strings. You could : \declare a member of it as: : \ : \ typedef struct SYMTAB { : \ struct SYMTAB *sym_next; : \ int sym_type; : \ char *sym_text; : \ } SYMTAB; : \ : \This has the drawback that one needs two allocates for the : \structure [...] : : symtabptr = (SYMTAB *) malloc(sizeof(SYMTAB) + strlen(text) + 1); : symtabptr->sym_text = (char *) symtabptr + sizeof(SYMTAB); : strcpy(symtabptr->sym_text, text); I suppose so. A strict reading of the standard does not permit this; it says that the result of malloc can be cast to *an* object. I can imagine a debugging interpreter that says that, once the result of malloc is cast, that's it. That could make maintaining type information much easier and maybe eliminate certain kinds of bugs. Another possibility is a capability machine might do something esoteric. On the other hand, the following code would work, even in those environments: char *dummyp; dummyp = (char *)malloc(sizeof(SYMTAB) + strlen(text) + 1); symtabptr = (SYMTAB *)dummyp; symtabptr->sym_text = dummyp + sizeof(SYMTAB); strcpy(symtabptr->sym_text, text); But there is still that pointer going to waste. --- Bill { uunet | novavax | ankh | sunvice } !twwells!bill bill@twwells.com