From owner-freebsd-hackers Sun Mar 3 11:16:49 2002 Delivered-To: freebsd-hackers@freebsd.org Received: from mail4.nc.rr.com (fe4.southeast.rr.com [24.93.67.51]) by hub.freebsd.org (Postfix) with ESMTP id 4674E37B400 for ; Sun, 3 Mar 2002 11:16:44 -0800 (PST) Received: from i8k.babbleon.org ([66.57.85.154]) by mail4.nc.rr.com with Microsoft SMTPSVC(5.5.1877.687.68); Sun, 3 Mar 2002 11:11:23 -0500 Received: by i8k.babbleon.org (Postfix, from userid 111) id 6D87EBA03; Sun, 3 Mar 2002 11:05:01 -0500 (EST) Content-Type: text/plain; charset="iso-8859-1" From: Brian T.Schellenberger To: conrads@cox.net, freebsd-hackers@FreeBSD.ORG Subject: Re: A few questions about a few includes Date: Sun, 3 Mar 2002 11:05:00 -0500 X-Mailer: KMail [version 1.3] References: In-Reply-To: MIME-Version: 1.0 Content-Transfer-Encoding: 8bit Message-Id: <20020303160501.6D87EBA03@i8k.babbleon.org> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sunday 03 March 2002 10:19 am, Conrad Sabatier wrote: > Am I just completely stupid, or do we have a few things that could use a > little cleaning up in /usr/include as well as in the man page for kvm_*? > > System: FreeBSD 4.5-STABLE > > 2) If compiling with the -pedantic switch, one might see something like > this: > > In file included from main.c:151: > /usr/include/sys/proc.h:108: warning: ANSI C forbids zero-size array > `ar_args' > > In : > > /* > * pargs, used to hold a copy of the command line, if it had a sane > * length > */ > struct pargs { > u_int ar_ref; /* Reference count */ > u_int ar_length; /* Length */ > u_char ar_args[0]; /* Arguments */ > }; > > This does indeed seem to make little or no sense. Could someone explain > this? Is ar_args supposed to be a pointer or what? I can explain this one; it's a moderately-common C programming technique. This strucuture will be allocated dynamically. I could be declared like struct pargs { ... u_char *ar_args; } and allocated like pargs = malloc(sizeof(struct pargs)); pargs->ar_args = malloc(args_size); but it's a lot more efficient to declare it as above and allocate it as pargs = malloc(sizeof(struct pargs) + args_+size); since pointers & arrays are equivalent, except that array data is at the location of the name rather than having a pointer to the data at that location, a [0] array has exactly the right semantics for this. You can declare a [1] array for this to make ANSI happy, but then you have to subtract in the allocation and besides that the [0] is "self-documenting" for those who are familir with the technique--after all, there isn't anything *else* you can do with a [0]-sized array. > 3) Furthermore, on including , one then sees this: > > In file included from /usr/include/sys/user.h:40, > from main.c:153: > /usr/include/machine/pcb.h:90: warning: struct has no members > > In : > > /* > * The pcb is augmented with machine-dependent additional data for > * core dumps. For the i386: ??? > */ > struct md_coredump { > }; > > Nowhere under /usr/include is a more complete definition of md_coredump to > be found. This looks awfully "kludgy" to me. A little guesswork here, but this seems pretty self-explanatory to me, too. The md_coredump{} is a structure that includes the *extra* information (beyond what's already in the portable structure) for coredumps on a given architecture. In the case of the 386, there is no useful extra information, so the structure is empty, but since there's a structure someplace that has an instance of struct md_coredump, it must be declared. Since there's no useful content, it is declared as being empty. Seems pretty elegant to me. If I'm off-base here, somebody please jump in! > > I do hope someone can shed some light here. Thanks. [Your point #1 seems valid to me, though.] -- Brian T. Schellenberger . . . . . . . bts@wnt.sas.com (work) Brian, the man from Babble-On . . . . bts@babbleon.org (personal) ME --> http://www.babbleon.org http://www.eff.org <-- GOOD GUYS --> http://www.programming-freedom.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message