Generally problems with Ballista datatypes occur in 2 areas:

1. 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 (*)[255])':
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[1]: *** [b_ptr_fpos_t.o] Error 1


2. 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 (*)[255])':
   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[1]: *** [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:

• constants: A constant may be used that is not defined on your system.
  • First try looking for the constant in another include file. Generally this is done by grepping the include directories. If you find the constant defined then add the appropriate include.
  • Otherwise try checking for a different spelling for the constant and simply substitute your constant.
  • Finally if you cannot determine a substitute test value then you may have to remove the test case from the template. You will need to remove it from all the sections in which it appears (dials, access, commit and cleanup). This removal is a last resort!
• includes: A include may to be added, changed or deleted.
  • Simply add, change or delete the include file from the include section of the template.
• heirarchy: The inheritance of a template may need to change if the underlying datatype on your system is different than heirarchy specified in the template file.
  • Determine the underlying type of associated with the POSIX datatype. Generally this is done by looking (or grepping) the include files (/usr/include).
  • Change the child template so the ballista inheritance matches the true state. For example your inheritance may need to change from a long to an int. Within the child template file simply change the parent specification and update the includes section to reference the new parent header file.
  • It is extremely unlikely but you might need to define a new parent template file. Follow the template definition instructions, and update the child template as described.
  • Generally template changes are automatically detected and processed. The exception is when you change a parent without changing a child. If this is your situation there are two options available:
    • Reprocess all the templates. In the ballista directory type

      ./makeBallista -c 

    • Otherwise, delete the files dependent on changed template. You will be deleting all .o, .cpp, .h and .param files for templates which inherit (directly or indirectly) from the altered template.

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.

• If you are testing a targeted system watch for these versions and make your changes as appropriate. Only on targeted systems are these alternate templates copied to the standard templates when the system is run. So if you were to change b_ptr_fpos_t.tpl instead of b_ptr_fpos_tLINUX.tpl on a LINUX system your changes would be lost.
• If you are not testing a targeted system and have datatype problems these alternate templates may be appropriate to your situation. If so simply copy the alternate template to the standard name. No overwriting occurs for non targeted systems.