Date: Mon, 4 Mar 2002 11:41:58 +0100 From: Erik Trulsson <ertr1013@student.uu.se> To: Harti Brandt <brandt@fokus.gmd.de> Cc: Ian <freebsd@damnhippie.dyndns.org>, freebsd-hackers <freebsd-hackers@FreeBSD.ORG> Subject: Re: A few questions about a few includes Message-ID: <20020304104158.GB63341@student.uu.se> In-Reply-To: <20020304102750.O74223-100000@beagle.fokus.gmd.de> References: <20020303180029.GA56041@student.uu.se> <20020304102750.O74223-100000@beagle.fokus.gmd.de>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 04, 2002 at 10:29:18AM +0100, Harti Brandt wrote:
> On Sun, 3 Mar 2002, Erik Trulsson wrote:
>
> ET>On Sun, Mar 03, 2002 at 10:27:17AM -0700, Ian wrote:
> ET>> >
> ET>> > In <sys/proc.h>:
> ET>> >
> ET>> > /*
> ET>> > * pargs, used to hold a copy of the command line, if it had a sane
> ET>> > * length
> ET>> > */
> ET>> > struct pargs {
> ET>> > u_int ar_ref; /* Reference count */
> ET>> > u_int ar_length; /* Length */
> ET>> > u_char ar_args[0]; /* Arguments */
> ET>> > };
> ET>> >
> ET>> > This does indeed seem to make little or no sense. Could someone explain
> ET>> > this? Is ar_args supposed to be a pointer or what?
> ET>>
> ET>> This is a common technique for defining a structure which is some
> ET>> descriptive information about an array of objects is followed by an
> ET>> open-ended array of those objects. (In this case the "objects" are
> ET>> characters.) The ar_args member of the structure gives a name to that
> ET>> location in the structure without reserving any space (and thus when the
> ET>> technique is used, there can only ever be one [0] member and it must be at
> ET>> the end of the structure). You access the open-ended array of objects just
> ET>> as you would any other array embedded within a structure, E.G.
> ET>> instance->ar_args[n].
> ET>>
> ET>> Not all compilers support defining zero-length arrays like this. And that's
> ET>> a pity; it's an incredibly useful technique, and the alternatives to it are
> ET>> not nearly as elegant and generally involve ugly recasting of pointers.
> ET>
> ET>For those compilers that don't support zero-length arrays one can still
> ET>use the same trick but with a one-element array at the end of the
> ET>struct. One just has to remember to that element into account when
> ET>allocating memory for the structure. Slightly uglier, but not much.
> ET>
> ET>It might be worth mentioning that this trick is not actually allowed
> ET>according to the C standard and in principle invokes undefined
> ET>behaviour. OTOH, AFAIK the trick does work on all existing compilers,
> ET>so while it is not standard-conforming it is quite portable.
>
> My ISO-C draft copy allows in section 6.7.2.1 paragraph 2 the last member
> of a structure to be an incomplete array type and paragraph 16 shows an
> example. Was this removed from the final standard?
I think it is still there (and my draft copy says the same thing).
I was thinking about the original C89 standard which does not allow it
(and does not allow incomplete array types in structs). Guess I should
have said which standard I was referring to.
>
> harti
> --
> harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
> brandt@fokus.fhg.de
>
--
<Insert your favourite quote here.>
Erik Trulsson
ertr1013@student.uu.se
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020304104158.GB63341>