Prof Abimbola Olowofoyeku wrote:
or, [b] (and perhaps more controversially), treat string literals of < 255 chars as strings of 255 capacity.
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.
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. Secondly, what exactly do you mean with "any other Pascal compiler"? 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).
(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. :-)
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, this might be reasonable then.
Frank