CBFalconer wrote:
I acknowledge that it is helpful to have foreign (e.g., C) semantics for interfacing. But is there any need for a general Boolean size, or only for "Boolean (8)", "Boolean (16)", etc.? If so, then the latter might be predefined, and the general mechanism dropped.
The standard way to create an array of 1 bit booleans is with 'packed'. i.e. "packed array [0..31] of boolean" could occupy one 32 bit word. No need for C bitfields. A boolean is already a two valued enumeration.
Indeed, and that works with GPC. A problem would be if someone used a field of more than 1 bit for a Boolean in C, but I can't imagine why anyone would do so (and this ever happens, one could still translate it as an integer range in Pascal).
Another issue is when a C function has, e.g., an `int' parameter with Boolean semantics. In this case, a Pascal program can (and should) translate it as `WordBool', not as `Boolean (n)', anyway.
"Prof. A Olowofoyeku (The African Chief)" wrote:
... snip ...
I must confess that I still cannot understand why any of this is a "better" solution than leaving things the way they are. How does the above advance the situation over a simple "type foo=Integer (n)"?
Because, I believe, "type foo = minval .. maxval;" is absolutely pure standard Pascal. In general the standards allow the attribute PACKED to be added to any type (this is hazy) so I believe "type foo = packed minval .. maxval;" remains completely legal anywhere. The compiler is always free to ignore the packed attribute.
The preparatory step is to accept the 'packed' reserved word in such statements, and discard it.
Maybe this wasn't clear in previous messages, but GPC allows and respects it for subranges already.
However, I fear it's non-standard. EP, 6.4.3.1:
newÂstructuredÂtype = [ `packed' ] unpackedÂstructuredÂtype . unpackedÂstructuredÂtype = arrayÂtype | recordÂtype | setÂtype | fileÂtype .
At some time in the future it would also be possible to implement offset non-symettric ranges with this syntax. E.G. "packed -64 .. 191;" could indicate a one byte quantity, whose zero value is actually represented by 0x40 (in C nomenclature). Such a mechanism can also handle unsigned ranges. This is pure blue-skying.
This should be possible. I'm not sure if the effort (internally subtracting/adding 64 before/after each operation) is worth it. But if someone wants to try it ...
Frank