From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Ken Raeburn Newsgroups: gmane.emacs.devel Subject: Re: Quesition about Lisp_Vector Date: Fri, 11 Nov 2011 04:01:27 -0500 Message-ID: <553A1AC5-4002-4175-AD1F-CC596356E44C@raeburn.org> References: NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: dough.gmane.org 1321002099 24184 80.91.229.12 (11 Nov 2011 09:01:39 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Fri, 11 Nov 2011 09:01:39 +0000 (UTC) Cc: emacs-devel@gnu.org To: Qiang Guo Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Nov 11 10:01:35 2011 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ROmzP-0005xH-MT for ged-emacs-devel@m.gmane.org; Fri, 11 Nov 2011 10:01:35 +0100 Original-Received: from localhost ([::1]:42143 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROmzP-0000jC-8T for ged-emacs-devel@m.gmane.org; Fri, 11 Nov 2011 04:01:35 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:58236) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROmzM-0000it-9L for emacs-devel@gnu.org; Fri, 11 Nov 2011 04:01:33 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ROmzL-0004EB-7E for emacs-devel@gnu.org; Fri, 11 Nov 2011 04:01:32 -0500 Original-Received: from mail-vw0-f41.google.com ([209.85.212.41]:40081) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ROmzL-0004E7-4v for emacs-devel@gnu.org; Fri, 11 Nov 2011 04:01:31 -0500 Original-Received: by vws16 with SMTP id 16so3832464vws.0 for ; Fri, 11 Nov 2011 01:01:30 -0800 (PST) Original-Received: by 10.52.36.41 with SMTP id n9mr19351476vdj.41.1321002090102; Fri, 11 Nov 2011 01:01:30 -0800 (PST) Original-Received: from squish.raeburn.org (c-66-31-202-94.hsd1.ma.comcast.net. [66.31.202.94]) by mx.google.com with ESMTPS id hn2sm16226748vdb.14.2011.11.11.01.01.28 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 11 Nov 2011 01:01:29 -0800 (PST) In-Reply-To: X-Mailer: Apple Mail (2.1084) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 2) X-Received-From: 209.85.212.41 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:145983 Archived-At: On Nov 11, 2011, at 01:29, Qiang Guo wrote: > Hi, I'm new to devel aspect of Emacs. And I'm having a problem reading > Emacs source code: in the definition of Lisp_Vector > struct Lisp_Vector > { > EMACS_UINT size; > struct Lisp_Vector *next; > Lisp_Object contents[1]; > }; >=20 > why contents's size is fixed ? And later when actually allocating = space This is a common idiom for handling a structure with a variable-sized = array at the end. The latest spec for the C language has support built = in for a slightly different mechanism, but this scheme used above has = been a common way to get around the absence of variable-sized arrays in = structures in traditional C for a long time, and it works on most if not = all C compilers. >=20 > nbytes =3D sizeof *p + (len - 1) * sizeof p->contents[0]; >=20 > I don't understand how this nbytes is calculated. why only (len-1) > contents[0] ? and how can the size of an array be changed ? The "len-1" means we want an array with "len" elements in it, but the = first element is covered by "sizeof *p" because "struct Lisp_Vector" = includes one array element already. If you use an index greater than = zero, the value referenced may be stored in extra padding space at the = end of the structure, if there is any, or in the additional space we = allocated past the end of the structure. If you think about it, it = really doesn't matter which; all that matters is that for array indexes = less than "len", we've allocated at least enough extra space. If you use a compiler or interpreter designed to run C code with = extensive, very pedantic run-time checks, it *might* notice if the array = index used is greater than 0 and warn you. But under pretty much any = normal compiler this should just work without any complaint. Ken=