[fpc-devel] Alternative parsers

[Hans-Peter Diettrich]

Marco van de Voort schrieb:

> I personally think that fully automated C header conversion is not possible.

It is, but at the same cost of e.g. fully automated Delphi project
conversion. In an FPC project the related items (modes, targets, search
paths...) are configurable in several ways - the equivalent
parametrization is required for every (other) compiler and its standard
library and header files. In ToPas all this can be specified in a
C-compatible way, using pragmas and defines, in a synthetic "project"
module. One problem is the determination of exactly that compiler
(including its library and header files), which must be used in order to
produce a correct result from the inevitable compiler specific idioms
and assumptions.

Some translations can require a deep analysis of the related code, in
order to determine e.g. the translation of PCHAR parameters, into Pascal
PCHAR or VAR char parameters. This is where most other translators apply
wild guesses, which will work most of the time, but leave the user
absolutely clueless when the generated translation doesn't work.


> The problem is that the only sane target (C/C++) are so different that
> interoperability is a bitch, and if you "just" want a C compiler, grab gcc.

This will work for most GNU sources on Linux, but not for Windows (MSVC,
BCB) related stuff. There exists no full-fledged gcc port for use on/for
Windows targets, MinGW and even CygWin don't track all the Windows
versions, features and quirks :-(

> (interoperability would be the reason to add it to FPC, I don't really
> expect for C users to drop gcc in droves and flock to FPC).

+1


> If the workarounds start changing the input, and it is not essentially:
> 
> - download C code. (e.g. zlib)
> - compile C part with FPC/C
> - compile own program with FPC/Pascal that uses C compiled part.
> 
> then one should wonder what it is actually good for.

You'll know what it's good for, when bugfixes or other patches are
applied to such a C library. In my own experiments with the compression
libraries I found an bug in the C code, and when I contacted the
maintainer, it turned out that exactly that bug had been fixed just a
few weeks ago - after the code had been in use already for over a
decade. This IMO is a strong argument against one-time (manual)
translations from C into Pascal, that will have to be updated, again
manually, for every update of the C sources.

Another problem exists in the beforementioned lack of portability of C
code. While FPC/Lazarus attempt to achieve that portability by an
intermediate layer (RTL, VCL...) and selectable targets (built into the 
compiler), C code has to be tweaked specifically for every target, that 
the developer decided to support. An FPC/C compiler could allow to apply 
the same support to C code, in target specific implementations of the C 
standard libraries, so that the compiled code will use the same basic 
functionality (memory management, file handling...), regardless of the 
source language. These libraries have to be adopted only once, for every 
supported target, like already done in the many supplied FPC packages.

As long as C libraries are already supplied as binaries (dll, so...), it 
may be sufficient to only translate their header files, or to make these 
usable otherwise. But else it will be necessary to translate the library 
sources into binaries, that either can be included into an FPC project, 
or can be used to create the platform specific shareable binaries, for 
use with further FPC applications or libraries.

DoDi