Browse Prior Art Database

Context Adaptive C Language Header Files Disclosure Number: IPCOM000098042D
Original Publication Date: 2005-Mar-07
Included in the Prior Art Database: 2005-Mar-07
Document File: 5 page(s) / 79K

Publishing Venue



C language header files are used to share information between separate notional elements within a program. This implies a supplier/user relationship between the subject program elements, where the supplier defines the interface via the content of its header file. The user must utilize the supplier's header file to obtain the needed information to use the interface. At times, the supplier header file is dependant on content in the domain of the user program. A method is described whereby each interface supplier need only provide a single header file that is usable in all user contexts, with minimal responsibility placed on the user programs to resolve user content needed by the supplier. This method depends on users providing a single private header file which characterizes the user program. These work in conjunction with a common header file that provides generic macros used by both suppliers and users. The ANSI C (ISO9899-1990) language preprocesser facilities establish unique and proper bindings in each case.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 31% of the total text.

Page 1 of 5

Context Adaptive C Language Header Files

Background and Overview - C language header files are used to share information between separate notional elements within a program. This implies two kinds of program element:

Supplier - Defines the content of the supplier header file, communicating its public interface to users.

User - Employs the information supplied in the supplier header file so it can utilize the supplier's interface.

In some cases, a supplier header file may be dependent upon names and declarations that are in the domain of the user program, and whose nature cannot be known in advance by the supplier, nor can they be presumed to be consistently declared across all such users. A mechanism is needed which allows the resolution of such declarations while placing minimal responsibility upon the user program, and without making such an interface more complex (at a source programming level). An example of this would be the case where the supplier's interface header file references a data area whose execution time address must be obtained and maintained by the user program. There are a number of possible solutions to the problem, all of which are unsatisfactory from a software development perspective.

The supplier provides a unique header file for each user. This approach is open-ended and cannot be effectively implemented for an unpredictable set of users.

The user is required to supply the missing information as a parameter to whatever services the header provides. This places a specific responsibility upon the programmer, increasing the likelihood of error, obscures the overall programming model, and makes the function unusable in an environment where transparency is a requirement.

All users are required to provide information in a fixed known location. This restricts the programming models available to the user. The information must somehow be determined at runtime. This approach, where feasible, incurs unsatisfactory runtime costs impacting the overall performance of the program. The complexity is further compounded if a single user program expects to exploit several interfaces provided by a number of supplier programs, where each of these interfaces has a similar dependency upon names maintained in the user's space. There are cases where it is necessary to establish an environment where different components (suppliers that are separately loadable executable objects) can be located and used without specific knowledge of the supplier interface on the part of the user program. Indeed, in some cases the user program is expected to be existing code which is required to be executed without modification to its source definition. Embodiment - This method describes a mechanism that can satisfy all of the requirements of declaring such supplier/user interfaces while avoiding most of the problems described for the existing mechanisms. Using the mechanism described here, each interface supplying program need only provide a single...