New Alpha

Sat, 12 Apr 1997 18:19:15 +0200 (MET DST)

Hello folks,

here is the next GPC alpha version.  It implements most of the
field-width options recently discussed, fixes some bugs, etc.

In detail:

Changes since gpc-970401:

  * Field widths still default to 0, i.e. no blank is output in front
    of Integer, Boolean, or negative Real values; one blank is
    output in front of positive Real values according to ISO.
    A new option `--field-widths=II,RR,BB' changes the default field
    widths to the numbers `II' for Integers, `RR' for Reals, and `BB'
    for Booleans.  The arguments may be omitted in whole or in part.
    Just `--field-widths' yields `--field-widths=11,23,6' which ensures
    that at least one blank is output in front of positive numbers.
    `--no-field-widths' means `--field-widths=0,0,0'.  The dialect options
    `--standard-pascal·level-0', `--standard-pascal', `--extended-pascal',
    and `--object-pascal' imply `--field-widths'.

  * A new command line option `--no-real-blank' switches the blank in
    front of positive Reals off; `--real-blank' switches it on again.
    This is useful together with compiler directives in the source
    (*$see-below *).

  * To specify default field widths, the strings written for "True" and
    "False" and similar things while compiling GPC, you can #define the
    symbols in gpc-defs.h and rts/rts.h, e.g.

        make CFLAGS="-O2 -DINT_OUT_WIDTH=8 -DFALSE_str=\"FOO\""

    A more comfortable solution is being worked on.

  * String clipping can be switched off with `--no-clip-strings' or on
    with `--clip-strings'.  The default is "on" unless `--borland-pascal'
    or `--delphi' has been specified.
 
  * The GNU compiler's global configuration file `specs' (or `specs.gpc'
    with DJGPP) now contains a line `*gpc1:' after which you can put
    your site-wide default switches, e.g.

        *gpc1:
        -fextended-pascal -ffield-widths -fno-clip-strings

    Note that `specs' does not want `--foo' but `-ffoo'.

  * All command-line `--foobar' flags now can be given as compiler
    directives.  One example:

        (*$field-widths,NO-clip-strings,SetLimit=1024, AutoMake="-g -O3"*).
 
    This is case-insensitive except inside the " ... ".

    Language dialect switches like `extended-pascal' do not enable
    or disable keywords, so they do not *exactly* mean the same
    as if they were given in the command-line.  For instance with
    (*$extended-pascal*), `uses' triggers a warning (but still works),
    whereas with `--extended-pascal' GPC does not know `uses' at all.

  * `For' control variables are checked now:  With `--standard-pascal'
    etc. GPC warns about structured variables and variables not in
    the nearest enclosing declaration scope; with `--borland-pascal' etc.
    structured variables and global variables are okay, but local variables
    must still be declared in the nearest scope.  Without a dialect
    switch, GPC only warns if we are `--pedantic'.

  * Bug fixed:  A field width of zero does no longer suppress output
    (except for Strings where ISO requires it (which can be overridden
    with `--no-clip-strings' - see above)).

  * Bug fixed:  Writing out Chars no more crashes on FreeBSD.

  * Bug fixed:  Char operators, e.g. comparision, work now.

  * Bug fixed:  RTL dump generation (with option `-dr'; for debugging
    purposed) works now.

  * Bug fixed:  String value parameters, Conformant arrays (Standard
    Pascal) and open array parameters (Borland Pascal) are passed
    correctly now.  (Now it is taken into account that their size
    isn't known.)

  * GPC now warns about usage of conformant arrays if invoked with
    `--standard-pascal·level-0', `--borland-pascal', or `--delphi'.

  * Bug fixed concerning Objects:  The implicit `Self' parameter is
    passed correctly now when calling inherited methods.

  * Arrays can be initialized with not-absolutly-constant values now.

  * In ASM statements, tabs and newlines are now inserted automatically
    between different lines.  It was not good that one had to write
    '... \n\t' in Pascal programs.  (It's still allowed with (*$E+*),
    but you are not *required* to use it in ASM statements any more.)

  * Bug fixed:  Input and output parameter specifications in ASM
    statements may consist of a single character now.

  * If statements and such now default to short-circuit operations.
    This can still be switched to complete evaluation using
    `--no-short-circuit', (*$B+*), or (*$no-short-circuit*).  With
    `--standard-pascal' etc., the default becomes complete evaluation
    and can be switched to short circuit using `--short-circuit',
    (*$B-*), or (*$short-circuit*).

    (It is done this way because the cases where a program relies on
    complete evaluation of Boolean expressions are very rare; functions
    with side effects should not occur in such situations anyway because
    you cannot rely on the order of evaluation.  OTOH, there are *many*
    programs which rely on short circuit evaluation.)

  * Bugs fixed:  GPC now better distinguishes between Integer numbers
    and Boolean values and also knows about the difference between the
    pointer value `Nil' and the number `0'.

  * Bug fixed:  Set comparision with `<' and '>' works now.

  * Arrays of Chars now can be initialized by String constants even without
    `packed'.  With `--standard-pascal' etc., a warning is given.

  * Bug fixed:  Types declared equivalent to `CString' now work like
    `CString'.  In particular, String constants can be given to parameters
    of such a type.

  * Like in Borland Pascal, `PChar' is now implemented as an alternative
    to `CString' as a built-in identifier which can be redefined
    without warning (just like `CString').  This is switched off with
    `--standard-pascal' etc.

  * With (*$X+*) or when GPC is invoked with `--extended-syntax',
    `CString' (or `PChar') variables can be initialized with String
    constants, and they can be indexed like other Strings, but starting
    with 0 instead of 1.  This is not affected by the dialect options
    since ISO Pascal does not define `CString' or `PChar', and Borland
    Pascal also requires (*$X+*) to allow the above.  (And it makes
    not much sense to combine (*$X+*) with dialect options other than
    `--borland-pascal' anyway.)

    Extensions of this type must be explicitly switched on because they
    conflict with Pascal's type-checking rules, so don't expect the above
    to become GPC's default behaviour.  (This is a different situation than
    the definition of the data type `CString' itself because `CString' is
    just a redefinable built-in name for "^Char", but it is a type conflict
    to index a pointer variable.)

  * When I wanted to implement an option to enable pointer arithmetics
    I encountered that it already worked by default due to a bug.  :-)
    Now pointer arithmetics works only with (*$X+*) or `--extended-syntax'.
    (Like `CString' indexing, this is too dangerous to stay GPC's default
    behaviour, but it must be explicitly enabled.)

  * GPC now checks whether the `for' variable is of ordinal type.  With
    (*$X+*) or `--extended-syntax', pointer variables are okay, too.

  * Set member iteration ("for i in [ 2, 3, 5, 7 ] do ...") is now
    implemented into GPC.

The source - a diff against gpc-970401 - is being uploaded to

    ftp://agnes.dida.physik.uni-essen.de/gnu-pascal/alpha/

together with binaries for DOS (DJGPP), DOS and OS/2 (EMX), Linux (ELF),
and FreeBSD.

I thank everybody who reported these bugs, in particular Phil Nelson,
Frank Heckenbach, Stephen Lindholm, Abimbola A. Olowofoyeku, and Jan-Jaap
van der Heijden.  (Again I hope that I didn't forget your contribution.)
Jan-Jaap furthermore contributed very useful ideas - besides his own
work on GPC.  I also thank everybody who took part in the discussion
about GPC's default behaviour and helped to clarify what the standard
specifications say and what they don't, what is reasonable behaviour of
a compiler and what isn't.  (* It seems that GPC will get more options
than any other existing Pascal compiler ... :*)  My special thank goes
to Larry Carter for the donation of a licensed copy of Delphi, and to
Nick Burrett who did not only report the bug about RTL dump generation,
but also fixed it and sent me the patch.

Ah - is somebody out there willing to document all this?  I wrote several
announcements of this type since gpc-2.0, and right now they are the only
existing documentation for the new features in GPC.

Thanks in advance for your help!

Greetings,

    Peter

  Dipl.-Phys. Peter Gerwinski, Essen, Germany, free physicist and programmer
peter.gerwinski@uni-essen.de - http://home.pages.de/~peter.gerwinski/ [970201]
 maintainer GNU Pascal [970412] - http://home.pages.de/~gnu-pascal/ [970125]

Peter Gerwinski (peter@agnes.dida.physik.uni-essen.de)