On 23 Mar 2002 at 15:35, Frank Heckenbach wrote:
[...]
No, why? For BP compatibility, it should be enough to treat `String' as `String[255]'
It isn't enough.
Yes, it is. As I said, GPC currently does *not* do so in all contexts yet.
Maybe this is just a question of words and meanings - but I think you just said that it is not enough ;-). I guess it all depends then on what one means by "enough".
In GPC, it prints '16', '16'. In BP, it prints '256', '256'. Similarly with TMT Pascal. With compilers that have AnsiStrings (Delphi, Virtual Pascal) it prints '256', '256', unless you compile with {$H+} (i.e., in "AnsiString" or "Long String" mode), in which case it prints '4', '4' (AnsiStrings are internally pointers).
So you can see that GPC, on this issue, is entirely in a class of its own (i.e., not compatible with any other Pascal compiler in any respect - and certainly not with BP).
Come on, please! First of all, comparing `SizeOf' is not a good idea because it depends too much on the internal structure.
Of course. It is simply to illustrate that BP (and compatible compilers) treat a string literal passed as a parameter as a 255 character string. The best comparison would be 'Capacity' and not 'Sizeof' - but of course 'Capacity' does not exist on BP or Delphi.
Secondly, what exactly do you mean with "any other Pascal compiler"?
The ones I just referred to.
AFAICS, you only compared GPC's standard conformant behaviour to three nonstandard compilers (which are all modelled after each other, so the fact that they behave the same doesn't tell much about whether that's a good behaviour). Any EP conformant compiler will behave like GPC does (except that `SizeOf' is nonstandard itself, but one can see it, e.g., testing the Capacity).
We were talking about BP string compatibility.
(which GPC currently does only in contexts where an undiscriminated `String' normally makes no sense, but I think we
already discussed a switch) ...
We did. Maybe it's time to consider implementing it?
If you like to do it, just go ahead. :-)
If I knew how to, I would have done it long ago ;). Unfortunately, very few people actually know how to hack the GPC compiler. If I tried to hack it, what you would get would not be worthy of the title "compiler" (that is, even it it managed to compile in the first place).
Perhaps we could accept "{$H-}" and something like "--short-strings" or "--BP-strings" to treat undiscriminated strings - function results, variables, record/object fields, and string literals, as BP strings, and without any warnings too. The default could be "{$H+}" or "--long-strings", which, at present would simply mean exactly what we have now (i.e., warnings, etc.) - or we (more controversially) could even treat undiscriminated strings in {$H+} mode as errors and refuse them at compile time.
You mean variables (not parameters), I assume, i.e. turning the current warnings into errors.
Yes.
Yes, this might be reasonable then.
We are agreed on one thing then! :-)
Best regards, The Chief -------- Prof. Abimbola A. Olowofoyeku (The African Chief) web: http://www.bigfoot.com/~African_Chief email: African_Chief@bigfoot.com