From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17969 invoked by alias); 18 Feb 2011 17:21:49 -0000 Received: (qmail 17957 invoked by uid 22791); 18 Feb 2011 17:21:47 -0000 X-SWARE-Spam-Status: No, hits=-1.3 required=5.0 tests=AWL,BAYES_00,MSGID_MULTIPLE_AT X-Spam-Check-By: sourceware.org Received: from mailhost.u-strasbg.fr (HELO mailhost.u-strasbg.fr) (130.79.200.151) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 18 Feb 2011 17:21:42 +0000 Received: from md2.u-strasbg.fr (md2.u-strasbg.fr [IPv6:2001:660:2402::187]) by mailhost.u-strasbg.fr (8.14.3/jtpda-5.5pre1) with ESMTP id p1IHLYIK028987 ; Fri, 18 Feb 2011 18:21:34 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from mailserver.u-strasbg.fr (ms4.u-strasbg.fr [130.79.204.13]) by md2.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id p1IHLYJg073160 ; Fri, 18 Feb 2011 18:21:34 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) Received: from E6510Muller (gw-ics.u-strasbg.fr [130.79.210.225]) (user=mullerp mech=LOGIN) by mailserver.u-strasbg.fr (8.14.4/jtpda-5.5pre1) with ESMTP id p1IHLXsP068766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) ; Fri, 18 Feb 2011 18:21:33 +0100 (CET) (envelope-from pierre.muller@ics-cnrs.unistra.fr) From: "Pierre Muller" To: "'Pedro Alves'" Cc: References: <00ac01cbcf5c$31f5bc00$95e13400$@muller@ics-cnrs.unistra.fr> <201102181147.52337.pedro@codesourcery.com> <00c301cbcf7b$afaa6d20$0eff4760$@muller@ics-cnrs.unistra.fr> <201102181524.45999.pedro@codesourcery.com> In-Reply-To: <201102181524.45999.pedro@codesourcery.com> Subject: RE: [RFA] Fix display of array of unspecified length inside structures Date: Fri, 18 Feb 2011 17:39:00 -0000 Message-ID: <000f01cbcf90$4b469bf0$e1d3d3d0$@muller@ics-cnrs.unistra.fr> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00478.txt.bz2 > -----Message d'origine----- > De=A0: gdb-patches-owner@sourceware.org [mailto:gdb-patches- > owner@sourceware.org] De la part de Pedro Alves > Envoy=E9=A0: vendredi 18 f=E9vrier 2011 16:25 > =C0=A0: Pierre Muller > Cc=A0: gdb-patches@sourceware.org > Objet=A0: Re: [RFA] Fix display of array of unspecified length inside > structures >=20 > On Friday 18 February 2011 14:54:03, Pierre Muller wrote: >=20 > > > On Friday 18 February 2011 11:08:38, Pierre Muller wrote: > > > > > > > PS: It could be wise to add some test in the testsuite for > > > > this, but I have no idea where I could insert this kind of test, > > > > any ideas? > > > > > > Yes, please. We have surprisingly few tests for this sort of > > > thing, AFAICS. I'm not even sure this is a regression from > > > my recent changes, I think it may well not be. > > > > I checked out gdb version 7.2 shows this regression, > > as compared to Cygwin 6.8 at least... > > Which means that the regression is not really recent. > > > > This might means that we should also merge this patch to > > the branch, no? >=20 > Sound fine to me. Tested, the problem existed on 7.2 branch and was fixed by the patch, thus I applied the patch to 7.2 branch. Pierre > > > Zero-length arrays (as poor man's flexible arrays) are supported > > > in GNU C as an extension. To be portable, you'd > > > need to use an array of length 1 (or c99's real flexible arrays), > > > but that won't trigger the bug. > > Apparently there is also the flexible array member construct > > see > > http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Zero-Length.html >=20 > That just confirms what I said. :-) The flexible array > member construst is C99 only, so it's likely that other > compilers choke on it by default. But this means that other compilers will at least accept this flexible array construct if they conform to ISO C99. =20 > > > I'd point at printcmds.exp, but I'm not sure if there are compilers > > > out there that choke on the construct... There's always a > > > new test file option... > > > > > > > PS2: It is probably impossible to make such a test without > > > > alloca or some other memory allocation function, no? > > > > Are there any system restriction for this? > > > > There is a long check at start of gdb.base/funcargs.c > > but it might just be to really check that alloca really uses > > the stack... >=20 > Irk. Just use malloc then? It's not really crutial that > the test runs on all targets/hosts. As long as it runs > on the targets must people are developing on (GNU/Linux,Windows), > it's fine, we're reasonably well covered. malloc should be OK, does it require a header? Pierre