From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10169 invoked by alias); 15 Oct 2007 16:50:55 -0000 Received: (qmail 10159 invoked by uid 22791); 15 Oct 2007 16:50:54 -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 16:50:50 +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 l9FGomP7009929 for ; Mon, 15 Oct 2007 12:50:48 -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 l9FGom5v004205 for ; Mon, 15 Oct 2007 12:50:48 -0400 Received: from [127.0.0.1] (sebastian-int.corp.redhat.com [172.16.52.221]) by pobox.corp.redhat.com (8.13.1/8.13.1) with ESMTP id l9FGokvH019820; Mon, 15 Oct 2007 12:50:46 -0400 Message-ID: <47139A01.8070404@redhat.com> Date: Mon, 15 Oct 2007 16:50:00 -0000 From: Andrew Cagney User-Agent: Thunderbird 1.5.0.12 (X11/20070530) MIME-Version: 1.0 To: Stan Cox CC: Frysk List Subject: Re: generating type tests References: <1192223570.2947.145.camel@multics.rdu.redhat.com> <470FFAC8.1050909@redhat.com> <1192413836.2947.150.camel@multics.rdu.redhat.com> In-Reply-To: <1192413836.2947.150.camel@multics.rdu.redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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/msg00052.txt.bz2 Stan Cox wrote: > < 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 }; >> The original example was a little more complex vis: struct foo { int i; } f = { 1 }; struct bar { struct foo* f; struct bar *b;}; struct bar b = { NULL, NULL } struct bar bp = { &f, &b }; while it might be possible to generate even this, I believe it is going to be much easier for future developers if they only need to read/edit a simple text (.c) file to add additional type tests. The expected results could be marked with comments: // LTYPE: struct bar { // LTYPE: struct foo *f; // LTYPE: struct bar *b; // LTYPE: } // VALUE: { 0x.*, 0x.* } // STYPE: struct bar // TEST: bp and a page of AWK could translate that into the body of a test. For the easy cases, can the generator produce a file like that; giving us the two steps: generator > simple.c filter < simple.c > Test.java breaking a large program down into a set of filters gives us smaller simpler programs with more clearly defined steps Andrew >> ... >> 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 > At present there's a chunk of code concerned with generating and assigning max values. If we choose simple values, and assume that int is at least 32-bits, that code isn't needed. >> make it easier. >> > > Reminds me of the Einstein aphorism, make things as simple as possible > but no simpler! > > > > >