This is the mail archive of the
frysk@sourceware.org
mailing list for the frysk project.
Re: generating type tests
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!