J. David Bryan wrote:
On 3 Aug 2006 at 21:21, Frank Heckenbach wrote:
Not yet, but I guess we could collect one and put it in the manual.
It would help. I spent an hour "debugging" the string comparison behavior change in a program I recently wrote, thinking, "This comparison test _must_ work...."
I guess I spent at least as long when confronted with the EP behaviour (very surprising and unintuitive to me) for the first time ...
I only began to understand by looking at the generated assembler, seeing the call to __p_EQ, looking that up in the RTS, recalling that there were --[no-]exact-compare-strings compiler options, running tests, and deducing that --gnu-pascal was invoking the option. Not at all obvious, I'm afraid.
It's actually in the manual (Programming / Library Routines / String Operations), but I admit this section might not be hard to find when you don't know what exactly to look for ...
: `s1 = s2' : : `s1 <> s2' : : `s1 < s2' : : `s1 <= s2' : : `s1 > s2' : : `s1 >= s2' : Lexicographic comparisons of `s1' and `s2'. Returns a Boolean : result. The shorter string is blank padded to length of the longer : one, but only in `--extended-pascal' mode.
BTW, that "--gnu-pascal" implies this option can be seen in gpc-options.h. Not that I'd expect a GPC user to do this, but now we can look at this list for other potential incompatibilites (not extensions):
{ "-fgnu-pascal", 0 }, { "-fno-ignore-packed", "-fno-ignore-garbage-after-dot", "-fno-nonlocal-exit", "-fmacros", "-fno-mixed-comments", "-fdelphi-comments", "-fno-iso-gotos", "-fno-implicit-result", "-fno-case-value-checking", "-fshort-circuit", "-fread-base-specifier", "-fread-hex", "-fno-read-white-space", "-fwrite-clip-strings", "-fno-write-capital-exponent", "-fexact-compare-strings", "-fdouble-quoted-strings", "-fno-field-widths", "-fno-methods-always-virtual", "-fno-propagate-units", "-Wcast-align", "-Wobject-assignment", "-Wtyped-const", "-Wnear-far", "-Wunderscore", 0 }
These are the ones I see:
"-fmacros",
Well, GPC warns about compiler directives in EP mode, so EP comments that look like GPC compiler directives cannot define macros without warning. Macro definitions on the command-line have to be given explicitly, but if so, could change EP programs. Predefined macros should all start with an underscore, so cannot conflict with EP identifiers.
"-fno-mixed-comments",
This is, of course, incompatible:
program Foo (Output); begin Write ('This is '); { *) Write ('not '); (* } WriteLn ('EP incompatible'); end.
"-fshort-circuit",
This is sometimes thought an incompatibility, but in fact it's not. EP doesn't prescribe whether and in which order operands are evaluated, including, of course, Boolean operations. (But EP doesn't prescribe short-circuit evaluation, either, of course.)
"-fno-case-value-checking",
Though a strict extension, but at runtime, so it produces differently behaving programs. EP requires a "dynamic-violation" there, i.e. a runtime error which must be detected.
"-fread-base-specifier", "-fread-hex",
These seem similar as the previous one (increasing the set of allowed "Read" inputs at runtime), but here EP only requires an "error" for invalid input which an implementation may leave undetected, so it's not strictly incompatible.
- default field-width in write statements is 1.
This is also not actually EP-incompatible, just different from a "typical" behaviour of other EP compilers apparently (which GPC thus also does in EP mode). So if you want to write portable EP code, you cannot rely on any default width anyway.
: 6.10.3.1 WriteÂparameters : : [...] : : Write(f,e) shall be equivalent to the form write(f,e : TotalWidth), using a : default value for TotalWidth that depends on the type of e; for : integerÂtype, realÂtype, and BooleanÂtype, the default values shall be : implementationÂdefined.
Frank