"J. David Bryan" wrote:
On 17 Dec 2002 at 20:41, Waldek Hebisch wrote:
I do not think that "explicitely sized" types really solve the problem. Namely, the types are chosen to have needed properties, for example a type must be big enough to allow indexing any array and must be efficiently passed to procedures.
For interfaces to third-party routines, the types have already been chosen by the implementer. In defining the interface and calling such a routine, I must choose types that match the implementation exactly. I have no choice here; if the implementation chose to represent numbers from 0 to 255 in one byte, then I must pass a one-byte variable. If two bytes were chosen, I must pass a two-byte variable, even if 0..255 would fit into a one-byte variable on my system, or even if my system's "natural size" for such ranges is four bytes.
Therefore, to use the implementation, I must have a guarantee from my compiler that the parameters to the external routines are of certain specified sizes. According to the GPC manual, "Integer" (for example) does not give me that guarantee, whereas "Integer (32)" does.
Wrong problem, IMHO. You already know how to generate items of various size in a particular installation (and all this is inherently non-portable). Generating such a thing may even be an array[1..count] of char. Your problem is to generate such an entity containing the particular information you want to transmit (or receive).
You have further problems to do with "who removes the parameters". Note that you can generate and call with one single large block, which you treat as one parameter, and the destination treats as a collection of items. Treatment of returned values is another whole area.