Waldek Hebisch wrote:
Frank Heckenbach wrote:
Waldek Hebisch wrote:
Frank Heckenbach wrote:
As I said, I see the main problems in C interfaces (which so far rely on `Integer = int', while most other places really should not really on exact type sizes etc.). So *if* we change it, we should only change one type, something like `Integer = "undefined" in C', and `CInteger' (or whatever) = `int', so C interfaces would only have to s/Integer/CInteger/g. (And similar for `Cardinal'/`Word', even if nonstandard, but so we keep the fact that `Integer' and `Cardinal' have the same size.)
Of course, we'd also need a transition period here -- add `CInteger' now, let everyone change their interfaces (using GPC-version conditionals to avoid breaking compatibility with older GPCs), sometime change `Integer'. Unpleasant indeed ...
Let me try to estimate impact. AFAICS candidate for change are:
m68k 16 --> 32
and 64 bit targets:
alpha, s390x, ia64, ppc64, pa64, sparc64, mips64, sh, amd64
While other targets also would be forced to change type names, since the types would remain the same the change shuild be painless for them.
I see it a bit differently. I don't like to use a "wrong" type (i.e., `Integer' for `int' when it's actually `long', just because it happens to match on most platforms). In fact, to me it means that such instances will be harder to find for people (most have no access to a 64 bit platform).
But I agree that if we change it, we should do it quickly. Some arguments for and against the change have been given, but I'm still undecided (or rather, I personally wouldn't mind either way).
If we change it, we must agree on which changes exactly -- as I said, I propose `CInteger', `CCardinal', `CWord'(?) as equivalent to `[unsigned] int', and `Integer', `Cardinal', `Word' to be equivalent to `[unsigned] long int', at least on some platforms (Waldek seems to know better, which ones). This would keep the impact on C interfaces minimal AFAICS.
I propose to make `Integer' equivalent to `PtrInt', `Cardinal' to `PtrCard', `Word' to `PtrWord' (so also `PtrCard'). And `CInteger', `CCardinal', `CWord' should be equivalent to `[unsigned] int'.
Why: `PtrInt' should be of correct size as index of any array,, so there is no need to special case (C `long' may be to big or even to small). On the other hand on most platforms `PtrInt' is of the same size as C `int', so the impact is limited (as I wrote above).
The bottom line is, is GPC going to be a Pascal, or is it going to be a C look-alike ? The traditions and the standard for Pascal are explicit: integer is supposed to be the largest size that does not carry extra cost on the target machine. Specifying smaller sizes is clearly the scope of subranges, specification of larger types (like double precision) is not covered by either the original or standardized languages (which is not the same thing as non-existent).
Pascal gives methods for specifying the exact type in an (extremely) portable way. Somewhere it became normal with many Pascals to adopt C's method instead, despite the fact that it is less portable (ie, every size has a predefined, labeled type).
Even that aside, "dragging" integer or int is a loosing strategy even in C. It puts off the inevitable change to the larger size until tomorrow, meaning that programmers have more time to entrench programs using the wrong size. Only the slow realization that the natural word width of the (by then most common) machine is being wasted counters that, and the result is programmers distrusting the int or integer type, and instead forcing more use of specifically sized types with special labels, furthering the scattering of dependencies.
Yes, I know I am being a bit preachy on the subject, but its an important one.