Wie funktioniert h2pas

[Mathias]

Es ist zwar grundsätzlich die Konvention das jede .c Datei eine .h Datei hat mit gleichem Namen, aber das ist mehr aus Bequemlichkeit und es gibt keinen technischen Grund warum das so sein sollte.

Ja, da hat man definitiv keine Garantie. Ich habe schon C-Header gesehen mit mehreren functionen. Und für jede function hatte es eine eigene C-Datei.

[Warf]

*g* passend zum Thema habe ich gestern meinen Artikel FPC_and_others veröffentlicht, in dem ich hoffentlich verständlich Zeige wie man C Quellen mit FreePascal verbinden kann, ggf ist das was für dich. Im Kern sehe ich das aber wie Theo, h2pas ist nur der Start, dann must du von Hand ran..

Bitte nicht so... ich weiß gar nicht wo ich anfangen soll...
Zunächst einmal die nitpicks und inhaltlichen Fehler:

FreePascal focuses on supporting C

C ist nicht gleich C und nicht alle C funktionen werden unterstützt. Die meisten Programmiersprachen unterstützen irgendwas zwischen C89 und C99. FreePascal unterstützt z.B. nicht den Typen complex für Komplexe Zahlen den C seit C99 unterstützt, oder Anonyme Struct und Union Member die seit C11 drin sind. Auch System APIs setzen sich normalerweise auf eine C Version fest. Der POSIX Standard in der letzten Version (2024) z.B. basiert auf C17, was eine leicht überarbeitete Version von C11 ist, und nicht das aktueller C23 (was viele neue Sprachfeatures hat).
Langer rede kurzer Sinn, nicht jeder C code lässt sich direkt nach Pascal übersetzen. C89 fast vollständig, C99 größtenteils ab da wirds etwas wackelig.

are provided in the ctypes unit

Meine Probleme mit der C-Types Unit hab ich glaube ich schon oft genug erwähnt. Einer der ganz besonders fies ist: cbool ist in FPC LongBool, was 4 bytes ist und -1 als True definiert, während in C _Bool oder bool (ab c23) 1 byte groß ist und 1 als True wert hat. Das kann zu richtig fiesen bugs führen wenn man das nicht weis

as both compilers typically represent them internally as integers starting from index 0

Nein! Enums in C sind keine Datentypen, es sind int Konstanten. Der code:

Code: Alles auswählen

enum WeaponType {
    WEAPON_PISTOL = 0,
    WEAPON_SHOTGUN = 1,
    WEAPON_ROCKET = 10
};

Korrekt nach Pascal übersetzt wäre:

Code: Alles auswählen

type WeaponType = cint;
const WEAPON_PISTOL = 0;
const WEAPON_SHOTGUN = 1;
const WEAPON_ROCKET = 10;

Pascal Enums sind eigene Typen, weshalb du die convertierung mittels "ord" im Beispiel machen willst. Wenn man C Code 1-1 übersetzen will sollte man keine Enums benutzen, weil das an anderen Stellen probleme machen kann.

Bitfield data types do not exist natively in FreePascal.

Doch:

Code: Alles auswählen

struct test_struct_t {
    unsigned Field1Bit: 1;
    unsigned Field2Bit: 2;
    unsigned Field6Bit: 6;
}

muss man ein bisschen kopfrechnen aber kann man übersetzen als:

Code: Alles auswählen

type
  TTestRec = bitpacked record
    Field1Bit: 0..1;
    Field2Bit: 0..3;
    Field6Bit: 0..63;
  end;

Code: Alles auswählen

#define SQUARE(x) ((x) * (x))

An dieser Stelle muss man sagen hat man echt nicht schönen C code vor sich, aber um nitpicky zu sein, ruf mal SQUARE(i++) auf und schau was passiert

Was man hoffentlich mehr in C code sieht was hier fehlt sind funktionen mit static linkage:

Code: Alles auswählen

static inline double square(double x) { return x*x; }

Diese findet man oft in Header files und die werden nicht exportiert, was bedeutet wenn man die in Pascal benutzen will muss man sie händisch übersetzen. NOTE: inline in C ist was anderes als inline in C++.

This ensures that the function uses the C calling convention, which is necessary for correct parameter passing and stack cleanup when interfacing with C libraries.

Jain... wenn man auf Windows arbeitet hat man häufig mit der Windows Nativen stdcall Calling Convention zu tun. Die kann FPC auch, das muss man nur wissen sonst knallts wenn man den code einfach übernimmt

Integrating Intermediate Compilation Artifacts (.a, .o)

In dem Kapitel sind so viele Fehler insbesondere die dinge die wirklich kaputt gehen das ich da gleich noch drauf eingehen werden daher heir erst mal einen generellen Punkt: Object Files und Static Libraries sind keine C/C++ Artifakte, sie sind teil des ELF Formats was die System ABI für Unix und Linuxsysteme darstellt. Das heißt das sind nicht nur irgendwelche dinge die aus dem C Buildprozess rausfallen, sondern sind Teile der Unix und Linux Systemspec. Deswegen funktioniert das ja auch so gut dagegen zu linken.
Das ist auch der Grund warum es auf Windows deutlich komplizierter ist, weil Windows das Portable Executable Format verwendet. MSys oder Cygwin emulieren Linux Tools auf Windows, was allerdings auch bedeutet das diese Compiler nicht so gut auf Windows sind.

["C" Sources...]

Die angehängten C beispiele sind unfassbar seltsam. Die meisten davon sind C++ code, aber nur die letzte Datei benutzt C++ features, die anderen benutzen das C subset von C++... aber nicht ganz korrekt:

Code: Alles auswählen

#include <cstdio>

void print_HelloWorld_from_a(void)
{
    printf("Hello World from a.\n");
}

Hier includest du cstdio, ein Header aus der C++ STL. Dieser definiert std::printf. Du benutzt aber nicht die namespaced C++ version sondern die global namespace C version. Das ist kein korrektes C++, entweder du schreibst C code:

Code: Alles auswählen

#include <stdio.h>

void print_HelloWorld_from_a(void)
{
    printf("Hello World from a.\n");
}

Oder du schreibst C++ Code:

Code: Alles auswählen

#include <cstdio>

void print_HelloWorld_from_a(void)
{
    std::printf("Hello World from a.\n");
}

Das was du machst ist weder noch.

[Das Buildsystem]

Die verwendung von shell scripten als Buildsystem ist definitiv möglich, aber sehr ungewöhnlich. Normalerweise nutzt man ein richtiges Buildsystem wie Makefiles oder für C++ explizit CMake, die sind auch noch Platform unabhängig, dann brauchst du keine .bat und .sh datei. Dein Buildsystem übersetzt wäre in etwa so etwas (aus dem Kopf geschrieben, nicht getestet):

Code: Alles auswählen

CXX:=g++
CXXFLAGS:=-g -Wall

SOURCES:=$(wildcard C/*.cpp)
OBJECTS:=$(patsubst C/%.cpp, lib/%.o, $(SOURCES))

lib/%.o: C/%.cpp
    $(CXX) $(CXXFLAGS) -c $< -o $@

obj/shared_o.o: lib/shared_o.o
    mv $< $@

obj/shared_a.a: lib/shared_a.o
    ar rcs $@ $<
 
%.so: lib/%.o
    $(CXX) -fPIC -shared -o $@ $<

all: obj/shared_o.o obj/shared_a.a shared_lib1.so shared_lib2.so
    true

---

Sooo... das Oben waren nur die nitpicks und kleineren Fehler, Kommen wir jetzt mal zu den sachen die wirklich kaputt sind. Beginnen wir hier mal mit dem Offensichtlichen: Runtimes.
Viele Sprachen haben Runtimes so auch C++, diese initialisieren z.b. die felder:

Code: Alles auswählen

extern "C" int test;

static int foo = 4;
int test = foo+3;

Mit dem Folgenden Pascal Programm:

Code: Alles auswählen

{$Link ctest.o}
var test: Integer; external;

begin
  WriteLn(test);
end.

Schreibt statt 7 0, weil ohne die notwendige C++ runtime die Initialisierung nicht ausgeführt wird.
D.h. wie in deinem Beispiel C++ Code statisch zu linken ist sehr gefährlich. Man muss die entsprechenden Initalisierungsroutinen (bei dem Beispiel oben müsste das die Funktion "_GLOBAL__sub_I_test" aus dem Objektfile) manuell aufrufen.

Das nächste ist ABI stabilität oder das fehlen davon... GLibC und die STDLib von C++ sind nicht ABI stabil. Wenn du dir also deine Object Files auf einer Maschine mit einer GCC Version baust und sie auf einer anderem Maschine mit anderer GLibC version linkst, kann das sehr schnell in die Hose gehen. Noch mehr sogar ist das Speicherlayout von C++ klassen Implementationsdefiniert, und kann sich theoretisch zwischen Compiler (versionen) oder sogar Compilersettings unterscheiden.
Du hängst im Repo die statische Version von der Microsoft C runtime an die ist afaik sogar tatsächlich ABI stabil (Microsoft ist da etwas stringenter als GNU), aber die libstdc++ geh ich von aus ist die von GNU. D.h. wenn jemand das versucht und nicht genau deine Compiler Version benutzt kanns krachen.

D.h. bei C, da C keine code basierte Runtime hat (sowas wie der initalisierungscode in C++) kann funktionieren, aber mit sehr vielen caveats. C++ außer man weiß ganz genau was man tut, sollte man beim statischen linken die Finger von lassen.

Zu guter letzt:

Execute install_libshared1_so.sh
(If this step is skipped, the debugger will crash because the implicid binded library is missing.)

Schau ich dochmal in die sh datei:

Code: Alles auswählen

sudo cp libshared1.so /usr/lib

Nein! Einfach nur NEIN

Erstens, wenn dann symlinken nicht hartkopieren. Aber selbst das, man wirft nicht einfach Dateien in seinen /usr/lib ordner, insbesondere wenns code ist den man nicht kennt. Benutz LD_LIBRARY_PATH stattdessen.

---

Zusammengefasst: Du musst da einiges korrigieren, allein inhaltlich. Die offensichtlich ChatGPT generierten Listen und co will ich gar nicht ansprechen. Ich weiß das AI Emojis und pro-contra listen liebt, aber sie blähen alles nur auf und machen verteilen die Informationen mehr als sie einen gewinn bringen.
Zum Inhalt: Statisches verlinken von ELF Object Files und Archiven (deshalb .a übrigens) ist extrem gefährlich und kompliziert. Wenn die person nicht bereits schon sehr gut sich mit C auskennt sollte man es nicht nutzen, und wenn man sich sehr gut mit C auskennt braucht man diesen Aritkel nicht.

Am besten einfach rauslassen und sich dafür mehr auf Dynamische Bibliotheken konzentrieren. Die sind relativ idiotensicher (also wenn man mal von dem Faux pas mit /usr/lib absieht) und sind der Weg wie man es machen sollte.

[Mathias]

C ist nicht gleich C und nicht alle C funktionen werden unterstützt. Die meisten Programmiersprachen unterstützen irgendwas zwischen C89 und C99. FreePascal unterstützt z.B. nicht den Typen complex für Komplexe Zahlen den C seit C99 unterstützt,

Dies habe ich auch schon festgestellt, Auch gibt es Sachen wie Float128. Teileweise kann man solches nachbilden, aber spätestens mit Writeln scheitert es. Man kann aber Sachen wie printf einfach von C anbinden.

Nein! Enums in C sind keine Datentypen, es sind int Konstanten. Der code:

Hier habe ich mich für die Konstanten Version entschieden, auch wen das Pascal enum schöner aussieht. Aber will man solche Pascal enum dann mit or Verküpfen, dann geht die casterrei los, was echt scheusslich ist.

Code: Alles auswählen

struct test_struct_t {
    unsigned Field1Bit: 1;
    unsigned Field2Bit: 2;
    unsigned Field6Bit: 6;
}

Die geht, sogar ohne Kopfrechnen.

Code: Alles auswählen

type
  TTestRec = bitpacked record
    Field1Bit: 1 shl 1 - 1;
    Field2Bit: 3 shl 3 -1;
    Field6Bit:6 shl 6 - 1;
  end;

So zum Schluss, C++ und Pascal passen überhaupt nicht zusammen. Was zB. bei QT sehr schade ist, es braucht ein Warper dazwischen.

[wennerer]

Hallo an Alle,
zunächst vielen Dank für alle Antworten. Ich hab da erstmal viel zu lesen und zu verdauen.

Viele Grüße
Bernd

[Warf]

Hier habe ich mich für die Konstanten Version entschieden, auch wen das Pascal enum schöner aussieht. Aber will man solche Pascal enum dann mit or Verküpfen, dann geht die casterrei los, was echt scheusslich ist.

Ja also Pascal Enums sind viel besser (insbesondere wenn man {$ScopedEnums On} einstellt) aber wenn man C code benutzt muss man sich leider an die C spielregeln halten.

Die geht, sogar ohne Kopfrechnen.

Code: Alles auswählen

type
  TTestRec = bitpacked record
    Field1Bit: 1 shl 1 - 1;
    Field2Bit: 3 shl 3 -1;
    Field6Bit:6 shl 6 - 1;
  end;

Ich glaube du meinst

Code: Alles auswählen

type
  TTestRec = bitpacked record
    Field1Bit: 1..1 shl 1 - 1;
    Field2Bit: 1..1 shl 2 -1;
    Field6Bit: 1..1 shl 6 - 1;
  end;

[Mathias]

Ich glaube du meinst

Hast recht, das ist wen man blind Eintippt.

Ja also Pascal Enums sind viel besser (insbesondere wenn man {$ScopedEnums On} einstellt) aber wenn man C code benutzt muss man sich leider an die C spielregeln halten.

Je nach Header kann man die Pascal enum verwenden. Aber zB. für GST ist es eine Katastrophe. Leider ist GST welches bei FPC dabei ist so blöd übersetzt. Das braucht es voll idiotische casts. Faort werden enum mit or verknüpft.

[corpsman]

*g* passend zum Thema habe ich gestern meinen Artikel FPC_and_others veröffentlicht, in dem ich hoffentlich verständlich Zeige wie man C Quellen mit FreePascal verbinden kann, ggf ist das was für dich. Im Kern sehe ich das aber wie Theo, h2pas ist nur der Start, dann must du von Hand ran..

Bitte nicht so... ich weiß gar nicht wo ich anfangen soll...

Danke für die vielen Hinweise, aus meiner Sicht ist der Artikel damit ein Voller Erfolg, denn ich lerne da nun noch sehr viel dazu, während ich versuchen werde alle deine Punkte ein zu arbeiten.

Ja ich habe ChatGTP bei der Übersetzung genutzt (hab alles in deutsch vor geschrieben und die KI hat dann übersetzt). Die Emoji's finde ich nicht störend im Gegenteil sie lockern den Langen Text auf, hier werden wir uns wohl nicht einig .

Du bist auch herzlich eingeladen, via PR Verbesserungen ein zu pflegen , genau deswegen habe ich es ja auf Github gestellt, dass hier jeder Lesen, aber auch beisteuern kann

[Mathias]

Danke für die vielen Hinweise, aus meiner Sicht ist der Artikel damit ein Voller Erfolg, denn ich lerne da nun noch sehr viel dazu, während ich versuchen werde alle deine Punkte ein zu arbeiten.

Ich habe den Artikel auch kurz gelesen, da ist auch die Stolper falle mit dem cbool. In meinen Augen ist die ein Bug in ctypes. Ich habe schon mehrere Header übersetzt und da war der bool immer 8Bit. Ich weis nicht wie die Entwickler auf die Idee gekommen sind den cbool auf 32bit zu setzen. Es gibt noch ein ganz gemeiner, der "long". Bei Linux ist der 64bit und bei Windows ist er 32bit. Auch der wchar_t muss man genau anschauen, da geht nicht einfach der widechar von FPC.

Code: Alles auswählen

Ja ich habe ChatGTP bei der Übersetzung genutzt (hab alles in deutsch vor geschrieben und die KI hat dann übersetzt). Die Emoji's finde ich nicht störend im Gegenteil sie lockern den Langen Text auf, hier werden wir uns wohl nicht einig ;).

Ich gebe es zu ich verwende für die Übersetzung auch ChatGPT. Es spart in gewissen Sachen sehr viel Tipparbeit. Aber das Ergebnis muss man sorgfältig überprüfen.

Bei h2pas ensteht eine gewisse Hassliebe. Man muss die Maken des Tools kennen, das ist es recht praktisch. Ich wollte mal reingucken, ob man es verbessern könnte, aber der Code ist total unübersichtlich. Ich hätte nie gedacht, das die so komplex sei.

[corpsman]

Bei h2pas ensteht eine gewisse Hassliebe. Man muss die Maken des Tools kennen, das ist es recht praktisch. Ich wollte mal reingucken, ob man es verbessern könnte, aber der Code ist total unübersichtlich. Ich hätte nie gedacht, das die so komplex sei.

Ich habe auch eine eigene h2pas variante geschrieben, und mein Code ist so schlecht, dass ich mich bisher nicht getraut habe den unter meinem Namen zu veröffentlichen .

[Mathias]

Ich habe auch eine eigene h2pas variante geschrieben, und mein Code ist so schlecht, dass ich mich bisher nicht getraut habe den unter meinem Namen zu veröffentlichen .

Ich denke, man würde weiter kommen, wen man von Grund aus etwas neues machen würde.
Aber sowas braucht natürlich einiges an Zeit.
Der erste Schritt würde sein, sämtliche Kommentare aus dem C-Code entfernen. Nur das ist schon ein harter Brocken. Aber da ja gcc dies auch machen muss, gibt es vielleicht ein fertiges Modul dazu.

[corpsman]

Ah du meinst weil die Kommentare von Präprozessor sachen abhängen, ja die Auf zu lösen war das was mein h2pas auch so kompliziert gemacht hat, wenns nur um "löschen" von Kommentaren geht, reicht ggf schon meine uncommenter.pas

[Mathias]

Oder man kann auch den gcc dazu verwenden,

Code: Alles auswählen

gcc -E forms.h -o forms_no_commend.h

Dabei werden aber auch sämtliche Makros entfernt.
Dafür werden aber sämtliche abhängige Header noch mit eingebunden, Wen man den Anfang seines Header kennt, kann man oberhalb alles rauslöschen.
Vielleicht kann man dies auch mit regex machen. ODer mit g_regex, welche bei glib2 dabei ist.

[Warf]

Ich hatte vor ewigkeiten mal einen C nach Pascal Transpiler angefangen auf basis von libclang. Der ist auch richtig in die Hose gegangen weil ich nicht wusste das clang verschiedene Parsing levels hat, und ich hab mir den Raw AST gedumpt, in dem bereits alle aliase und macros aufgelöst waren. Das hat zwar den "optimalen" code für die ausgewählte Buildconfig gegeben, als transpiler aber sehr nutzlos

Das ganze Thema ist gar nicht mal so leicht, vor allem wegen vielen der kleinen Eigenheiten von C die Pascal so nicht hat. Eine sache z.B. C unterscheidet zwischen Funktions und Funktionspointer typen. D.h. die Folgende Pascal Definition:

Code: Alles auswählen

type
  TMyProc = procedure(AValue: Integer); cdecl;

kann man in C in 2 varianten schreiben:

Code: Alles auswählen

typedef void (*myprocptr_t)(int); // Direktes äquivalent
// oder
typedef void (myproc_t)(int); // Funktionsdefinition
typedef *myproc_t myprocptr_t; // Pointer zu Funktion

Solche Kleinigkeiten können einen da richtig verrückt machen

[Mathias]

Code: Alles auswählen

typedef void (*myprocptr_t)(int); // Direktes äquivalent
// oder
typedef void (myproc_t)(int); // Funktionsdefinition

Dies ist auch ein gemeiner, wo h2pas scheitert. Bei sowas füge ich manuell den * ein, aber man muss daran denken, das man dies gemacht hat. Den bei Methode, wo dies callprocs übergeben werden, Kann es sein, das dann h2pas ein P anstelle des T Types nimmt.

[wennerer]

Hallo,
wer (trotz der Verbesserungsvorschläge) die Demo von corpsman testen möchte und auf das gleiche Problem wie ich

Warning: linker: /usr/bin/ld: -lstdc++ kann nicht gefunden werden: Datei oder Verzeichnis nicht gefunden

stößt möchte ich folgendes mitteilen.
Zunächst hab ich nach einer *-dev gesucht und auch mehrere Verionen gefunden und installiert. Hat leider nichts gebracht. Dann hab ich von Hand einen Symlink erstellt:

sudo ln -s -f /lib/x86_64-linux-gnu/libstdc++.so.6.0.33 /usr/bin/libstdc++.so

Hat auch nicht funktioniert (was ich nicht verstehe).

Letztlich hab ich den Symlink in dem Ordner der Executablen erzeugt und das geht:

sudo ln -s -f /lib/x86_64-linux-gnu/libstdc++.so.6.0.33 /home/......../Research-main/Content/FPC_and_others/libstdc++.so

Falls jemand eine bessere Lösung kennt bitte posten.

Viele Grüße
Bernd