10.23.1 Foreign Types

There are two sorts of objects that Prolog may want to handle: atomic and compound. Atomic objects include numbers and atoms, and compound objects include data structures and arrays. To be more precise about it, an atomic type is defined by one of the following:

signed integer, large enough to hold a pointer.
integer_64   since release 4.3
64 bit signed integer.
32 bit signed integer.
16 bit signed integer.
8 bit signed integer.
unsigned integer, large enough to hold a pointer.
unsigned_64   since release 4.3
64 bit unsigned integer.
32 bit unsigned integer.
16 bit unsigned integer.
8 bit unsigned integer.
64 bit floating-point number.
32 bit floating-point number.
32 bit Prolog atom number. Unique for different atoms, but not consistent across Prolog sessions. The atom is made non garbage collectable. See Atoms in C.
A pointer to an encoded string. Represented as an atom in Prolog. Please note: This string must not be overwritten, as it constitutes the print name of an atom. Also, the atom and string are made non garbage collectable. See Atoms in C.
An untyped pointer. Like pointer(_), but library(structs) does no type checking for you. Represented as a Prolog integer.
Unknown type. Cannot be represented in Prolog. A pointer to an opaque object may be manipulated.

Compound types are defined by one of the following:

a pointer to a thing of type Type.
A chunk of memory holding Num (an integer) things of type Type.
A chunk of memory holding some number of things of type Type. This type does not allow bounds checking, so it should be used with great care. It is also not possible to use this sort of array as an element in an array, or in a struct or union.
A compound structure. Fields is a list of Field_name:Type pairs. Each Field_name is an atom, and each Type is any valid type.
A union as in C. Members is a list of Member_name:Type pairs. Each Member_name is an atom, and each Type is any valid type. The space allocated for one of these is the maximum of the spaces needed for each member. It is not permitted to store into a union (you must get a member of the union to store into, as in C).

C programmers will recognize that the kinds of data supported by this package were designed for the C language. They should also work for other languages, but programmers must determine the proper type declarations in those languages. The table above makes clear the storage requirements and interpretation of each type.

Note that there is one important difference between the structs package and C: the structs package permits declarations of pointers to arrays. A pointer to an array is distinguished from a pointer to a single element. For example


is probably a more appropriate declaration of a C string type than


which is the orthodox way to declare a string in C.

Send feedback on this subject.