Maurice Lombardi wrote:
To summarize, the correct translation, with a test program would be
[...]
You may check that it is strictly equivalent to
Since the C header is #included, the defines apply to the including program as well. A 100% translator would have to do the same (i.e., translate it to a Pascal include file, not a unit/module), though in this case, some Pascal type definitions will do for most cases (but not for `DWORD (8)' in an importer -- but this might be changed with a new syntax) ...
#define WORD unsigned short
That's not the same as `Word' in GPC. You'd need
type WORD = ShortCard;
#define BYTE char
`char' can be signed or unsigned in C. Not specifying this is either a bug in the C header, or it means that it doesn't matter, so both `Byte' or `ByteInt' would be OK in GPC.
Only the record with the bitfields should be packed.
Records that contain both bitfields and other fields might be a problem in the translation (doesn't occur here). One might need an articifial sub-record ...
I know no C equivalent to with in Pascal ...
There is none. You can only set a pointer to the record at the point of `with' and dereference it explicitly where necessary. This would be semantically equivalent (i.e., the record access is only evaluated once at the point of `with'), but not syntactically.
With respect to my first idea, besides the confusions between types and variables corrected by Franck, it adds no extra type identifier (which would be very problematic with generic identifiers like Bytes, Bits etc).
I don't see why. And in general, you do need additional type identifiers. C can use structured types etc. in parameter lists where Pascal requires a type identifier.
There can in fact be anonymous types in C which cannot be anonymous in Pascal, so the translator will have to make up a name ...
It can be fully automated, because it is systematic: union -> case integer of ... struct -> packed record ... Type -> C_Type: it is the only case here where some kind of prefixing is mandatory. There is inly a finite (small) list of these.
But it's possible that a future GPC version will add new keywords. Even if only for some dialects, the translator should avoid them which means that its output may change at any time. Not a good idea IMHO.
Another thing is that in C structs, unions, enums and "plain" identifiers can have the same name (because it's always used iwth `struct' etc. prefixed). And then there's the problem of case-sensitivity ...
So the translator has to do some identifier renaming, and if so, I'd prefer to make the rules as simple as possible (e.g., not dependent on the list of Pascal keywords).
BTW, the renaming might also be a good thing; e.g. if `FooBar' is a C function working on CStrings etc., in Pascal you might want to have the name `FooBar' for the corresponding Pascal function (which will call the C function internally, so the latter should have a different name).
The only problem I see is the restriction by pascal to only one case variant in a record. I suppose C has no restriction on the number of union inside a struct. This can be solved only by some extra types.
Must be in fact, since unions are syntactically more like sub-records, i.e. they have a field name of their own. You translated this correctly above. If you put the variants into the main record instead, this would have been possible in this case (because the union was last), but the access would have looked differently (omitting the `HighWord').
So I think one can say, a C union corresponds to a Pascal variant record with no fields before the variant, so their translation should pose no special problems.
Frank