Frank Heckenbach wrote:
Rick Engebretson wrote:
One issue to consider is naming conflicts. Since dot qualified names seem to be a problem, perhaps prepending the c library name to the pascal name will avoid name conflicts.
The last alpha release supports qualified identifiers.
What's more of a problem is that C allows the same identifier for different purposes (`int foo' can exist in the same scope as `struct foo', `union foo' or `enum foo'). Prefixing all structs/unions/enums with something unique might be a solution.
An even bigger problem is C's case-sensitivity. This will probable require some heavier name mangling.
A libc unit for pascal is a big departure from the dos world.
And I don't support the idea. Just as I think it was wrong for BP to promote Dos specific calls in the `Dos' unit (which we now have to painfully emulate for legacy code), and later Windows specific calls (so far as to suggest using C-strings (`PChar') in regular Pascal code), I don't think it's good style for any but perhaps some very special-purpose programs to use low-level system-specific calls.
Well, libc in general doesn't have to be system-specific, but unfortunately it often is, if you consider the number of autoconf checks (or equivalent) any nontrivial, portable C code (including our RTS) needs. Using libc in a Pascal program directly means the programmer would have to do all those autoconf checks himself -- translating the libc headers wouldn't help there (*) ...
To avoid this, we've already provided Pascal interfaces for much of libc's functionality (built-in and in the GPC module).
(*) Unless the translator would also do part of what autoconf does. In principle, that's possible, since it sees the declarations as it translates them. What it could not do (easily) is to check for functions that exist in the library, but not in the headers (that still occurs today -- *especially* in libc implementations --, that's why for many things there are separate autoconf checks for the existance and the declaration or a routine).
Other c-libs like OpenGL, etc. will follow.
I think most other libraries are easier to translate. With many libraries you have only one implementation, or a few (ncurses, PDCurses, ...), whereas many systems have their own libc. In addition, libc headers are often full of macros, and translating them automatically is very tricky.
(And, of course, a Pascal interface to OpenGL does not require a Pascal libc interface, even if OpenGL uses libc itself.)
I really don't care about ISO-this or ISO-that.
All of this is non-ISO-Pascal as it doesn't specify a way for external imports, anyway.
Pascal is an elegant language that should allow casual programmers to tap into the c-library platform without too many paw prints.
For commonly used things, I'd rather provide a proper interface (see above), so all the autoconf stuff (which often involves testing on different systems which a single programmer acnnot always easily do) must be done only once.
Frank
I don't know how, in any detail, fpc accomplishes a monolithic libc unit. But I think gpc qualified identifiers will help build the bindings properly. I am not critical of anybody's work.
With my limited effort, the fpc libc functions are actually easier to use than fpc native functions. The man2html cgi program on staroffice5.2 (or tkman) gives quick reference to definitive man page documentation.
I just look at pascal as a far better superset of C than is C++. Ultimately, it all comes down to organizing bits.