Re: generating type tests

[Stan Cox <scox@redhat.com>]

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