J. David Bryan wrote:
On 2 Aug 2006 at 21:05, Frank Heckenbach wrote:
The lists of required options shouldn't be that long if you only want to avoid incompatible behaviour, and not exclude all unneeded extensions, as we try to not be incompatible to EP in GPC dialect unless EP's behaviour is ... well ... too strange (talk about string padding ;-).
Is there a list of the changes that the GP dialect option makes to defined EP behavior? Extensions are obvious, but semantic changes, such as string comparisons, are not.
Not yet, but I guess we could collect one and put it in the manual. You might want to start, perhaps right here in this thread, collecting a list of issues you already know of, then others and I can later fill in what we find ...
Another subtle issue is that a compile-time division by zero or zero modulus is an error in GPC's default mode, but must not be in EP (GPC only gives a warning there). This may extend in the future to other checks done at runtime according to EP, but at compile-time when possible by GPC.
Given:
program comp (output);
var s : packed array [1..4] of char;begin s := 'abc'; if s = 'abc' then writeln ('true') else writeln ('false') end.
...this will print "true" for EP and "false" for GP. But isn't the "if" statement always false in GP mode, regardless of the value of "s"? More generally, wouldn't every fixed-string equality comparison fail (or succeed) statically if the strings were of unequal length?
Yes.
If so, it would be helpful if GPC issued a warning in this case, e.g, "result of comparison is always false" (note that GCC does this in some cases, e.g., comparison of unsigned value >= 0).
Good idea. In fact, I made the warnings a bit more extensive (maybe overkill ...), see the test programs. Of course, they still can't catch all cases of unintentionally confusing padding and non-padding comparisons.
20060803: warn about some string comparisons that are always true or always false (dave7*.pas)
Frank