I have uploaded a new beta version of GPC to
<http://www.g-n-u.de/gpc/>!
Because our main server is still out of order, please note:
- The new URL, as stated above. www.gnu-pascal.de still doesn't
work.
- There are just the "bare bones" files (full and minimal source
distribution, binaries for Linux/IA32 with and without gcc). No
diffs, no separate test files, no HTML pages etc.
- The main directory in the full source distribution is probably
different! Be careful with automatic build scripts.
- The releases are signed with a new OpenPGP key. The fingerprint is
given in my signature in this mail and my other mails to the
gpc(a)gnu.de list for some weeks.
When the main server is back again, I'll do the usual release
procedures there.
One major change is that the types `Integer', `Word', `Cardinal' are
now equivalent to `PtrInt', `PtrWord', `PtrCard', no more
(necessarily) to C's `int' and `unsigned int' types. New types
`CInteger', `CWord', `CCardinal' are provided for the latter
purpose.
This affects C interfaces in particular. A "porting guide" is given
below. If you maintain any such interfaces, be sure to read it
carefully.
Another major improvement is in the area of initializers, thanks to
Waldek Hebisch. GPC now allows initialization of variant records
(fjf259.pas, peter6.pas) and packed arrays (emil5.pas) and supports
Extended Pascal's structured initializers (fjf964*.pas, fjf967*.pas,
fjf968*.pas) as well as record, array and set values (constdef.pas,
fjf966*.pas, fjf971*.pas).
Unfortunately, we don't have very many test programs for these new
features yet. If you can send us some (according to the guidelines
described in the manual), this will be very welcome.
Other new features:
* `Discard'
* new make variable `GPC_PAGESIZE' to set the page size when
building the manual (PDF, PostScript, DVI)
* `qualified' and import lists are no more allowed after `uses'
(only after `import', as EP demands) (@)
* the `GMP' unit doesn't support gmp-2.x anymore (if you used it,
just upgrade to a newer GMP version) (@)
* conflicts between object fields/methods and ancestor type names
are detected as required by OOE (fjf945*.pas) (@) (O)
* repeated function headings (in `forward' declarations and
interfaces) are checked stricter: if one has a result variable, so
must the other (according to the OOE draft) (@) (O)
Bugfixes:
* records with no fields are invalid according to EP (fjf972.pas)
* `Index' and `Pos' cannot be used in constant expressions
(fjf970*.pas)
* the `__FILE__' and `__BASE_FILE__' macros should return full paths
* `Sqr' sometimes evaluates its argument twice (fjf963.pas)
* memory leak in routines with a local variable of file type that
are left via `Exit' or `Return' (fjf962.pas)
* using a Boolean function as a condition in a `repeat' loop doesn't
work correctly (artur1*.pas)
* overstrict type-checking in comparisons involving procedural types
(fjf960*.pas)
* `Read', `Write' etc. evaluate its arguments in the wrong order
(az43*.pas)
* `Read' etc. evaluate references to string parameters twice
(fjf958.pas)
* on targets with 16 bit `Integer' type, the `MicroSecond' field of
`TimeStamp' causes a compilation error
* character arrays indexed by non-integer ordinal types treated as
strings cause internal compiler errors (fjf957*.pas)
* `-W[no-]cast-align' does not work (fjf956*.pas)
* in `FormatTime' `%Z' and `%z' unless provided by system library
ignore DST
* powerpc: `--strength-reduce' doesn't work with `for' loops (was
kludged before, fixed in gcc-3.3.3)
* AIX: `ReturnAddress' doesn't work after use of dynmamic variables
(backend bug, fixed in gcc-3.3.3)
* functions returning sets are called twice if range-checking is on
(inga1*.pas)
PORTING GUIDE FOR THE NEW C COMPATIBLE INTEGER TYPES
====================================================
In my experience, the transition goes as follows:
1. If you want your code to keep working with older GPC versions
after this change, add (near the top) the following part. You can
omit the types you will not need in the following.
{$if __GPC_RELEASE__ < 20041017}
type
CInteger = Integer;
CCardinal = Cardinal;
CWord = Word;
{$endif}
2. In all C-visible declarations, replace `Integer' with `CInteger'
and `Cardinal'/`Word' with `CCardinal'/`CWord'.
C-visible declarations are usually `external' declarations
(routines and/or variables) in Pascal which are implemented in C,
but they can also be Pascal-implemented declarations (usually
with a `name' attribute) which are declared `extern' in C code.
Do not forget structures that are used within such declarations,
e.g. parameters of type [pointer to] a record, or procedural
parameters, etc.
The same goes for other languages such as C++.
3. Fix any resulting incompatibilites. (This is the nasty part.)
Value parameters are usually no problem.
Anything else might be a problem, e.g., reference parameters,
variables, structure fields, procedural parameters' parameters
(including value parameters). As long as they are used only in
the implementation of a unit/module which exports a Pascal
interface, necessary changes can be confined to and handled
within this interfaec.
Otherwise, you have the choice whether to change the interface,
which will require further changes in code using the interface,
or to add wrappers to keep the interface.
Example:
unit MyCInterface;
interface
uses GPC;
type
t = record
x, y, z: Integer
end;
procedure a (n: Integer); external name 'a';
procedure b (var n: Integer); external name 'b';
procedure c (var r: t); external name 'c';
function d (var n: Integer): TString;
implementation
function cd (var n: Integer): CString; external name 'd';
function d (var n: Integer): TString;
begin
d := CString2String (cd (n))
end;
end.
Changing a to
procedure a (n: CInteger); external name 'a';
is usually harmless.
Changing b to
procedure b (var n: CInteger); external name 'b';
is problematic, since all callers would need to change their types
(which might cause further ramifications in indirectly dependent
code). So it might be in order to add a wrapper, such as:
procedure b (var n: Integer);
[implementation]
procedure cb (var n: CInteger); external name 'b';
procedure b (var n: Integer);
var cn: CInteger;
begin
cn := n; { omit if n is used only as an "output" parameter }
cb (n);
n := cn
end;
Procedure c uses a record containing `Integer' fields. Here, it's a
hard choice between adding a wrapper (might be expensive, as the
record gets bigger, and if more routines are affected) or changing
the record to:
type
t = record
x, y, z: CInteger
end;
The choice might depend on how many other routines use this
structure and how many of them are written in Pascal or C, and how
much existing code already uses the structure and what it does with
it.
Function d already has a wrapper, so it's usually best to also take
care of the new change there:
function d (var n: Integer): TString;
var cn: CInteger;
begin
cn := n; { omit if n is used only as an "output" parameter }
d := CString2String (cd (n))
n := cn
end;
Finally, note that `Integer' might be bigger than `CInteger',
especially on newer platforms (that's the reason for the whole
change in the first place). So if you want to have a bigger range
available, you might want to consider changing from `CInteger' etc.
(`[unsigned] int' in C) to `MedInt' etc. (`[unsigned] long' in C).
This, however, requires (possibly substantial) changes in the C
code, and might be out of your control (when interfacing to 3rd
party libraries).
Frank
--
Frank Heckenbach, frank(a)g-n-u.de, http://fjf.gnu.de/, 7977168E
GPC To-Do list, latest features, fixed bugs:
http://www.gnu-pascal.de/todo.html
NEW! GPC download signing key: ACB3 79B2 7EB2 B7A7 EFDE D101 CD02 4C9D 0FE0 E5E8
Hi Folks,
the GNU Application Libraries for Pascal (GNUALP) framework has grown. After
multithreading, it now also provides database access. As a default
implementation, there is an ODBC unit available.
The tarballs can be downloaded from http://www.markus.gerwinski.de/gnualp/. To
run the ODBC part, you will have to install gnualp-0.1.5.tar.gz first, then
gnualpodbc-0.1.1.tar.gz. Both projects can be installed, as usual, with
./configure, make, make install.
To run the demo program(s) in the demos/pas resp. demos/c subdirs of
gnualpodbc, you'll need to have a working ODBC environment installed. If you
have, just start the odbcdemo program with a valid data source name as command
line argument, and you'll see a nice little command-line SQL client. :-)
gnualpodbc-0.1.1 is tested with the following system configurations:
- SuSE Linux 8.0 and above, iodbc-3.51.2, and a mysql-4.0.20 database
accessed via myodbc-3.51.09.
- Windows XP with MinGW, mysql-4.0.20, and myodbc-3.51.9-win. You'll maybe
have to download libmsvcp60 from somewhere (it was pre-installed in my
MinGW distro, but that doesn't seem to be standard).
Have fun,
Markus