From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30930 invoked by alias); 15 Oct 2007 02:10:11 -0000 Received: (qmail 30890 invoked by uid 22791); 15 Oct 2007 02:10:09 -0000 X-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 15 Oct 2007 02:10:02 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.13.8/8.13.1) with ESMTP id l9F2A0iI014552 for ; Sun, 14 Oct 2007 22:10:00 -0400 Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [10.11.255.20]) by int-mx1.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9F2A0ON018890 for ; Sun, 14 Oct 2007 22:10:00 -0400 Received: from [172.16.57.153] (multics.rdu.redhat.com [172.16.57.153]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9F29xpa030316 for ; Sun, 14 Oct 2007 22:09:59 -0400 Subject: Re: generating type tests From: Stan Cox To: Frysk List In-Reply-To: <470FFAC8.1050909@redhat.com> References: <1192223570.2947.145.camel@multics.rdu.redhat.com> <470FFAC8.1050909@redhat.com> Content-Type: text/plain Date: Mon, 15 Oct 2007 02:10:00 -0000 Message-Id: <1192413836.2947.150.camel@multics.rdu.redhat.com> Mime-Version: 1.0 X-Mailer: Evolution 2.10.3 (2.10.3-2.fc7) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact frysk-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: frysk-owner@sourceware.org X-SW-Source: 2007-q4/txt/msg00050.txt.bz2 < simultaneously acting as both filter and generator. For instance: > -> structs is created from a brute force table > -> scalars is generated using a for loop One advantage of the brute force approach is that it ensures that any combination, that is programmed into the tool of course, will be tested without having to explicitly list them. > would it be better to separate these steps out, perhaps also having a > separate data file, then this can be implemented as one or more filters. So it seems to me that an implicit brute force tester is useful perhaps in addition to an explicit tester. I like the idea of a generator though. My initial thought was an input file that used cdecl syntax. For example cdecl allows 'declare x as array of array of int' but doesn't support any struct syntax so scratch that. > As things advance, will the types that need to be tested become too > complex for this scripting technique? For instance: > struct foo { int i; } f = { 1 }; > ... > I wonder if letting the user describe the types in C, and output in > comments, and then filter that to generate the tests is better? Vis: (BTW, I can test these now, e.g. source.add("struct foo {\\n int i;\\n}", "f", "","{1}")) It would certainly be possible to read in declarations from a file and produce the equivalent C and java support code. I'm not sure I am following what the advantage of using the filers is though, as opposed to producing the C and java directly from the input file. > is going to be easier to work on. Similarly, chosing simple values may > make it easier. Reminds me of the Einstein aphorism, make things as simple as possible but no simpler!