Mail #13763

Back to main page of archive

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

From: Frank Heckenbach
Subject: Problem with --enable-keyword and
Date: 6 Aug 2006, 01:37:33

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

Previous mail   Next mail   Unformatted/full headers
Overview  10 days   Subject   Date   Thread   Author  

Replies

In reply to

Back to main page of archive

Note: This page contains information that does not originate from the owner of this web site, but from the authors of the mails archived. The owner of this web site is not responsible for the content of such information. Any use of that infomation requires the consent of the respective author.

Where WWW addresses (URLs) in the mails archived are marked as hyperlinks, this is only for the comfort of the reader. The content of the web pages linked to like this does not necessarily reflect the opinion of the owner of this web site or of the authors of the mails archived. The owner of this web site is not responsible for the content of such web pages. Those pages are explicitly not to be considered as part of the content of this page, but merely as references.

This page was created by Crystal 0.999 (Linux 2.4.27/i686).