Path: csiph.com!news.swapon.de!eternal-september.org!feeder.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail From: Ben Bacarisse Newsgroups: comp.lang.c Subject: Re: Help on this typedef Date: Thu, 18 May 2017 20:02:14 +0100 Organization: A noiseless patient Spider Lines: 83 Message-ID: <87fug2yond.fsf@bsb.me.uk> References:

<8ad1e08b-bdf9-4baa-a8b4-63bf48fb3e3d@googlegroups.com>

<7828b0dd-de46-40a2-9636-81117d1f17f6@googlegroups.com> <799899ab-ccf3-49a4-a928-d405dc142fff@googlegroups.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: mx02.eternal-september.org; posting-host="06c1f1f23e3a6793fde9e570d88f1cf9"; logging-data="10258"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/rWg2ZXnaL93gaYDgGcUm30l5i/HO3F50=" Cancel-Lock: sha1:2oGqPgqemIuVFPfujV3hR1wTiz0= sha1:YP8qD5NxAffF+W9Gj6vPY7kKs1Q= X-BSB-Auth: 1.59add6844b91d724fe18.20170518200214BST.87fug2yond.fsf@bsb.me.uk Xref: csiph.com comp.lang.c:110324 joel.rees@gmail.com writes: > On Monday, May 15, 2017 at 11:23:23 PM UTC+9, Tim Rentsch wrote: >> joel.rees@somewhere writes: >> >> > On Sunday, May 14, 2017 at 6:25:48 AM UTC+9, Tim Rentsch wrote: >> >> joel.rees@somewhere writes: >> [...] >> >>> An indefinite array type has more limitations than a type of an >> >>> array with one element. >> >> >> >> In some ways it has more, in other ways it has fewer. >> >> >> >>> Both, of course, can refer to an array of more than one element >> >>> when instantiated. >> >> >> >> What do you mean? AFAIK there is no way to "instantiate" an >> >> indefinite array type. >> > >> > Bad phrasing, I guess. "... when in use." probably would have been >> > more accurate. >> >> Ah. In that case I must demur regarding part of your later >> statement. An access through an array type of extent 1 is >> not definedly allowed to access elements after the element >> at index 0. > > typedef string_header_s struct > { short length; /* limited length */ > char text[ 1 ]; > } string_header_t; > > And before you C++ types came around, we just left the array size > out: char text[]. No, the old idiom as an array length 1 as above. The form sanctioned by the newer C standards (C99 and up) is to leave the size out, provided this is the last member of a struct. (I don't know what C++ has to do with it -- I took "you C++ types" to refer to people, but I don't know who.) > But that was declared in all cases to be equivalent > to char *, so it means something else, now. And if that's what you > mean in such a header, you say char *, instead. No. char x[] and char *x mean the same thing in a parameter declaration but not elsewhere, and definitely not in a struct! > typedef struct string_header_s > { short length; > char string[ 1 ]; > } string_header_t; > > char bigblock[ 100000 ]; > char * here = bigblock; > > string_header_t * string_allocate( long length ) > { char * place = here;; > if ( ( place = here + length + sizeof (string_header_t) ) >= bigblock + 100000 ) This test is, technically, wrong. Most people would not worry about it, but once you know what C guarantees and what it does not guarantee it's hard to go back[1]. I'd just keep a counter of the bytes used to avoid a potentially undefined pointer construction and test. > { return NULL; > } > here = place; > ( (string_header_t *) place )->length = length; > return (string_header_t *) place; > } You also have potential alignment problems. [1] You can only generate pointers that point into, or just past, an array, and pointer can only be compared with <, <=, > and >= if they point into the same object (or just past). -- Ben.