Waldek Hebisch wrote:
[G5:gcc/p/test] adriaan% gpc avo10.pas
That one looks easy to correct: we just need proper error message (patch below).
OK, thanks.
G5:gcc/p/test] adriaan% gpc -v Reading specs from /Developer/Pascal/gpc343d7/lib/gcc/powerpc-apple-darwin7/3.4.3/specs Configured with: ../gcc-3.4.3/configure --enable-languages=pascal,c --enable-threads=posix --prefix=/Developer/Pascal/gpc343d7 --target=powerpc-apple-darwin7 --host=powerpc-apple-darwin7 Thread model: posix gpc version 20050217, based on gcc-3.4.3
Adding a typecast triggers another error:
G5:gcc/p/test] adriaan% cat avo11.pas program avo11; type UInt16 = cardinal attribute( size = 16); StyleItemGPC = (bold,italic,underline,outline,shadow,condense,extend); StyleParameter = UInt16; procedure TextFace(face: StyleParameter); external name 'TextFace'; begin TextFace( StyleParameter( [bold, italic])); {internal compiler error} end.
I am not sure if we should accept this program --
We should not. According to BP (the only documented reference I have about type-casts at all), there are two kinds of type-casts: Variable type-casts (which require variables, or rather "lvalues" and cast to types of the same size -- as for lvalues the size is well-defined), and value type-casts which apply to ordinal types (and pointers in MP) and which conserve ordinal values (or addresses).
Neither of them applies here. This patch gives a proper error message instead of crashing:
--- p/expressions.c.orig Sun Feb 27 06:56:51 2005 +++ p/expressions.c Mon Feb 28 16:59:30 2005 @@ -3138,6 +3138,11 @@ if (!tree_int_cst_equal (TYPE_SIZE (otype), TYPE_SIZE (type))) value = non_lvalue (value); } + else if (!lvalue_p (value)) + { + error ("invalid type cast"); + return error_mark_node; + } else { /* Variable type cast. Convert a pointer internally. */
Waldek Hebisch wrote:
Some thoughts, if you search for good way to express the intent. [...]
I don't think any of these ways is reliable. If your external routine wants a 16-bit integer, use this on the Pascal side. Then you can either work with bit masks and/or convert to/from sets in a subroutine explicitly.
Anything else would rely on the internal representation of sets in GPC which may change in the future, and which already now is not what you want AFAICS. Currently sets are composed of `MedCard' values (which are usually, if not always, larger than 16 bits). Little-endian systems might hide the problem; fortunately yours is big-endian, so you won't even get the impression that it worked. ;-)
Frank