beste Praxis für die Bereitstellung einer C-API, die interne Funktionen verbirgt [closed]

Ich habe eine C-Bibliothek geschrieben, die aus einigen .h-Dateien und .c-Dateien besteht. Ich kompiliere es als .a statische Bibliothek.

Ich möchte dem Benutzer nur bestimmte Funktionen zur Verfügung stellen und den Rest so dunkel wie möglich halten, um das Reverse Engineering einigermaßen zu erschweren.

Ideally meine Bibliothek würde bestehen aus:

1- Eine .h-Datei mit nur den Funktionen, die dem Benutzer zur Verfügung stehen.

2- myLibrary.a: Möglichst nicht rückentwickelbar

Was sind die Best Practices dafür? Wo soll ich suchen, gibt es irgendwo ein gutes Tutorial / Buch?

Genauer

für

Ich habe bereits alle meine .h und .c, und ich möchte vermeiden, sie zu ändern, Funktionsdeklarationen von .h nach .c zu verschieben und potenzielle pbs in Zirkelverweise aufzunehmen. Ist das möglich

Ist es zum Beispiel eine gute Idee, eine neue .h-Datei zu erstellen, die ich nur zum Verteilen mit meiner .a-Datei verwenden würde? Das .h würde Kopien der Funktionen enthalten, die ich verfügbar machen und Deklarationen der von mir verwendeten Typen weiterleiten möchte. Ist das eine gute Idee?

für

a) Welche GCC-Flags (oder Xcode) muss ich beachten (zum Entfernen, ohne Debug-Symbole usw.)? b) Einen guten Zeiger, um zu lernen, wie man Code-Verschleierung macht?

Jeder Gedanke wird helfen,

anke, ba

Antworten auf die Frage(6)

Ihre Antwort auf die Frage