This is the mail archive of the frysk@sourceware.org mailing list for the frysk project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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!






Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]