Re: generating type tests

[Andrew Cagney <cagney@redhat.com>]

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!
>
>
>
>
>