Ballista OS Robustness Test Suite Datatype Problems
Generally problems with Ballista datatypes occur in 2 areas:
The POSIX standard does not completely specify some of the datatypes involved in POSIX calls. This ambiguity introduces the possibility of a mismatch between the ballista test definitions and your specific OS implementation.
A good example of this mismatch is the datatype fpos_t which is used in the POSIX fgetpos function. fpos_t is defined in both Solaris and Digital Unix to be a long. However, fpos_t is defined under Linux to be a structure. Using the ballista type that references fields in the Linux fpos_t structure would cause compile errors when testing Solaris.
b_ptr_fpos_t.cpp: In method `void * b_ptr_fpos_t::access(char (*))':
b_ptr_fpos_t.cpp:241: request for member `__pos' in `temp_fpos_t', which is of non-aggregate type `long int'
b_ptr_fpos_t.cpp:242: request for member `__state' in `temp_fpos_t', which is of non-aggregate type `long int'
b_ptr_fpos_t.cpp:249: request for member `__pos' in `temp_fpos_t', which is of non-aggregate type `long int'
b_ptr_fpos_t.cpp:250: request for member `__state' in `temp_fpos_t', which is of non-aggregate type `long int'
make: *** [b_ptr_fpos_t.o] Error 1
Another problem occurs when constants used in the ballista test definitions are not defined on a system or are defined in different include files.
For example the testing of unsigned long integers relies on the constant ULONG_MAX. In Digitial Unix this constant is defined in the machlimits.h include file. However, in Solaris and Linux the constant is defined in limits.h. When the limits.h is not listed in the include section of the unsigned long integer template file (b_unsigned_long.tpl) the follow compile occured on the Solarius system:
b_unsigned_long.cpp: In method `void * b_unsigned_long::access(char (*))':
b_unsigned_long.cpp:318: `ULONG_MAX' undeclared (first use this function)
b_unsigned_long.cpp:318: (Each undeclared identifier is reported only once
b_unsigned_long.cpp:318: for each function it appears in.)
make: *** [b_ptr_buf.o] Error 1
Both of these problems can be fixed. The solution requires some knowledge about how ballista defines datatypes and tests.
Ballista datatypes are defined in "template" files. You will find template files in the ..ballista/templates directory. The templates files must have the .tpl suffix. Template files are parsed, and therefore must remain in the specified format. The .cpp and .h files associated with the ballista datatype are generated and should not be modified directly. Additionally, the bug report code generated after the OS tests are run relies on the template file.
From the compiler's error messages you should be able to determine which datatype file has the problem. In case you can only determine which function has a problem the POSIX functions are matched with the appropriate ballista datatypes through the file ../ballista/callTable.all. This file has a strict format which is detailed at the top of the file. From this file you can determine which datatypes are used when testing a particular function. Generally you will not need to change this file.
A note of warning, template files support inheritance. Therefore determining the actual template file with the problem may require some heirarchy traversal when the using the function specification versus the compile errors. For example if you are testing fgetpos then the problem may not be with the template b_ptr_fpos_t.tpl but rather its parent file b_ptr_long.tpl or b_ptr_void.tpl.
Details on template file definition
Likely templates changes:
One warning, for the targeted OS platforms the OS test suite does support different versions of the templates files where required. The alternate versions have the OS system name added to the datatype name. For example b_ptr_fpos_t.tpl is the default template and b_ptr_fpos_tLINUX.tpl is the alternate template.