(I was out of town for some weeks, still catching up with the mails ...)

Waldek Hebisch wrote:

To be more precise: "{$enable-keyword asm}" just causes `asm' to be recognized as the keyword. Other checks are unaffected by "enable-keyword". Apparently, for `pow' no more checks is used,

Yes. As a (rough) rule of thumb from a user's point of view, things that could be implemented in (some dialect of) Pascal, except for their built-in identifier/keyword status, require no more checks, since they are actually implemented just this way internally. This includes "pow" (an operator as can be defined and overloaded according to OOE extensions that GPC supports) and of course all types such as "Cardinal".

Whereas most built-in routines are a bit different (often only in that they allow different parameter types, even if only, say, LongInt for maximum range and Integer for better performance when sufficient; so when GPC will allow overloaded routines, this may then apply to some built-in ones as well).

I am tempted to say that the exact effect of enabling a keyword which otherwise would be disabled by dialect settings is explicitly undocumented.

I agree.

...

There are two alternate ways I can accomplish this:

1. Choose the GP dialect and either program around the semantic changes ("if s = 'GPC ' then") or use compiler directives to restore EP semantics ("{$no-exact-compare-strings}").

If you need this for a lot of source code, I'd probably recommend this. 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 ;-).

...

2. Choose the EP dialect and bracket each extension with "{$gnu-pascal}" and "{$extended-pascal}".

But if I could choose EP and selectively enable the extensions, it would be simpler, and it would document at the start of the source file exactly what extensions were used.

OTOH, if you need the extensions only for some routines (or can be encapsulated in a few), I'd probably go for that. Even if these routines are used in many programs later, you could put them in a module, and compile this module only (or even parts of it) with "{$gnu-pascal}".

Frank

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

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.

2. 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

J. David Bryan wrote:

On 6 Aug 2006 at 1:37, Frank Heckenbach wrote:

...

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 learned Pascal on several HP computer systems, and all of them had the extension that unequal-length strings were blank-padded for comparisons. So EP seems quite normal to me.

I think it only makes sense for backward-compatibility with CP (which didn't have strings with a length field, except hand-made ones, and blank-padding was used instead, which I'd call a kludge already). When you often parse input lines or construct output lines from strings and want to control the spacing yourself instead of relying on default widths, trailing spaces make quite a difference. Anyway.

...

These are the ones I see:

[...]

I'm less worried about behavior that would be invalid or undefined in EP than about behavior changes that occur when a valid EP program with valid EP input is compiled in GP mode.

I think I mentioned only such.

I expect GP mode to give me an enhanced version of Pascal, so allowing undefined case values, e.g., would not be surprising.

Depends. If the EP program relied on aborting on an unmatched case value as it may validly do in EP since it's a dynamic-violation, not only an error (such an abort may not look to nice, but perhaps acceptable for a batch-style program), GPC's default behaviour would lead to unintended (and perhaps wildly wrong) behaviour.

leading me at first to wonder how the file position got so far out of bounds. :-) Certainly this should not produce a warning in the compiler, but it would be helpful to have the manual detail somewhere the changes that occur when switching modes that might affect a valid program with valid inputs.

OK. So far we have this thread. You might want to start collecting the relevant information, perhaps changing the formulations to fit manual style, and suggest where to insert it in the manual. And if you or someone else finds more such issues, please point them out.

If all of the mode changes are made through option switches,

No, not all. (That would mean adding another couple of dozen option switches ...)-:

then perhaps a table could be put in the "GPC Command Line Options" section, with options in rows and dialects in columns, to show which options are default for which dialects (essentially describing the settings in gpc-options.h). That would be easier, in my view, than trying to decipher the various "default in xxx" statements that now accompany most -- though not all -- of the option descriptions.

From gpc-options.h we could probably generate such a table

automatically with some effort, but as I said, it wouldn't capture all dialect differences ...

Frank

I wrote:

I wrote:

...

...

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.

Just a little correction to the messages.

I think my previous patch is too noisy. Comparisons of two string constants shouldn't be warned (at least not by default). E.g., in my own code, I sometimes do things like that:

{ Configuration file }

const LogFileName = ''; { optional }

{ Main code }

if LogFileName <> '' then { ... }

This would warn whenever LogFileName is set because of the different lengths of the empty and a nonempty string. I think that's overkill.

So the following patch disables the warning for this case (and does another small internal cleanup).

Frank