Huge Zahlenklasse mit RSA Absturz bei deconstructor

firefly

Die Frage ist auch um was für eine (Hardware) Platform es sich hier handelt, und was der Grund ist, das auf eine libc (um welchen denn überhaupt?) verzichtet werden muss.

*john 0

@Finnegan sagte in Huge Zahlenklasse mit RSA Absturz bei deconstructor:

Wenn du also irgendwo eine malloc-Implementierung hast, dann ist das meiner Einschätzung nach alles was ein std::vector oder ein std::basic_string brauchen.

Nein, da kommt einiges an Abhängigkeiten zusammen. Das fängt damit an, dass die Container nicht malloc nutzen sondern std::allocator<T>, und dann kommen da so Abhängigkeiten wie die Traits-, Exception-, … -Header dazu.

It0101

Noch ein Tipp von mir: Arbeite dich in Unittests ein und teste deine Module ( z.B. dein Array ) einzeln ab. Unittests sind ein wirksames mittel gegen solche Fehler wie bei deinem Resize.
Und selbst wenn du kein Test-Framework aus irgendwelchen Gründen verwenden kannst, kannst du trotzdem Unittests programmieren, denn letztendlich prüfst du nur Rückgabewerte oder Stati von irgendwelchen Variablen und dazu braucht es nicht zwingend ein Framework wie gtest oder anderes.

Finnegan

@john-0 sagte in Huge Zahlenklasse mit RSA Absturz bei deconstructor:

@Finnegan sagte in Huge Zahlenklasse mit RSA Absturz bei deconstructor:

Wenn du also irgendwo eine malloc-Implementierung hast, dann ist das meiner Einschätzung nach alles was ein std::vector oder ein std::basic_string brauchen.

Nein, da kommt einiges an Abhängigkeiten zusammen. Das fängt damit an, dass die Container nicht malloc nutzen sondern std::allocator<T>, und dann kommen da so Abhängigkeiten wie die Traits-, Exception-, … -Header dazu.

Ich meine damit schon externe Abhängigkeiten. Der Default-Allocator std::allocator<T> dürfte mit dem malloc der libc implementiert sein und bei den anderen genannten Headern sehe ich nicht, was die aus der libc brauchen sollten. Exception Handling könnte eventuell Unterstützung einer (externen) Compiler-Runtime benötigen, die auch wiederum Abhängigkeiten haben kann. So genau weiss ich das nicht. Wie ich schon sagte, es is möglich, dass sich das je nach Implementierung der C++-Standardbibliothek alles nicht so leicht voneinander trennen lässt, aber ich sehe nicht wie ein std::vector inklusive aller Abhängigkeiten grundsätzlich mehr als die malloc-Implementierung aus der libc benötigen sollte.

*john 0

@Finnegan sagte in Huge Zahlenklasse mit RSA Absturz bei deconstructor:

Der Default-Allocator std::allocator<T> dürfte mit dem malloc der libc implementiert sein …

Ja, es ist eine der Möglichkeiten, aber es gab/gibt hinreichend viele Compiler die unter UNIX/Linux (keine Ahnung wie die API auf anderen Plattformen aussieht) direkt brk/sbrk nutzen. Und die ganzen Header sollte man auch nicht unterschätzen, weil man sie ggf. erst einmal implementieren muss.

Finnegan

@john-0 sagte in Huge Zahlenklasse mit RSA Absturz bei deconstructor:

@Finnegan sagte in Huge Zahlenklasse mit RSA Absturz bei deconstructor:

Der Default-Allocator std::allocator<T> dürfte mit dem malloc der libc implementiert sein …

Ja, es ist eine der Möglichkeiten, aber es gab/gibt hinreichend viele Compiler die unter UNIX/Linux (keine Ahnung wie die API auf anderen Plattformen aussieht) direkt brk/sbrk nutzen. Und die ganzen Header sollte man auch nicht unterschätzen, weil man sie ggf. erst einmal implementieren muss.

brk/sbrk/mmap sind schon ziemlich low-level, erstere mehr wie ne Stack-Allokation und letzteres auf Speicherseiten-Ebene. Da bräuchte es auf jeden Fall noch ne generische Speicherverwaltung obendrauf die etwas platzeffizienter für beliebige angeforderte Größen ist und den Speicher auch sinnvoll freigeben und wiederverwenden kann. Eben sowas wie malloc. Die genannten Compiler müssten dann sowas selbst mitbringen.

Ich wollte es aber nicht zu sehr abschweifen lassen. Eigentlich war ich ja hauptsächlich neugierig, wo bei @Tuxist1 der operator new herkommt ohne libc. Kann man natürlich auch separat einbauen.

Quiche Lorraine

@Tuxist1 sagte in Huge Zahlenklasse mit RSA Absturz bei deconstructor:

Es gibt einen zweiten branch wo ich noch die libc mit implementiere kann deshalb kein std:: einbinden kann da std:: wiederum von der libc abhängig ist.

Sorry das ich da mal nachhake.

Aber ich verstehe nicht warum man libc bzw. STL nicht nutzen möchte.

In der STL steckt eine Menge Hirnschmalz und lässt sich nicht so einfach nachprogrammieren. Deine array Implementierung mit c_str() Funktion z.B. sieht unter Visual Studio folgendermaßen aus:

https://github.com/microsoft/STL/blob/main/stl/inc/xstring

Und wo ich gerade in deinem Repo eine Datei namens atomic.cpp sehe, möchte ich dir auch die Visual Stdio Variante zeigen:

https://github.com/microsoft/STL/blob/main/stl/inc/atomic

8000 LOC, Holla die Waldfee

firefly

Und dass keine libc verwendet wird ist aktuell nicht korrekt.

z.b. werden folgende header in verschiedenen cpp dateien inkludiert:

Wobei eventuell der Plan ist, diese durch eine eigene Implementierung zu ersetzen?

Wenn es nicht gerade aus reiner spielerei/wissbegierde ist, sollte man das tunlichst vermeiden so was selbst zu implementieren.

Tuxist1

in dem main branch wird libc mit implementiert:

https://tuxist.de/git/jan.koester/systempp/-/tree/main

habe einen zweiten branch der mit standart libc gebaut wird:

https://tuxist.de/git/jan.koester/systempp/-/tree/without-libc

wollte erstmal in den zweiten tree https einbauen damit das backend von meinem Blog
"http://tuxist.de" wieder funktioniert hat mit den cookie richtlinien zu tun.

Aber jetzt mal zu systempp soll die basis von fenriros bilden, im moment bin ich unzufrieden über den wildwuchs von unix/linux konfiguartions Dateien jeder und alles macht da was er will führt dazu das es unnötig viel Arbeit konfigurations Oberflächen dafür zu schreiben. Das zweite Problem was ich sehe ist das man auf tiefere ebene zum teil sehr schwerig zu verstehende api hat und meist nur auf c ebene. Ich versuche da Abhilfe zu schaffen da ich als Rentner jetzt zeit dafür habe.

Unterschiede Fenriros zu anderen Posix Systemen:
-confdb mit conffs eine art registry
-sid statt fortlaufender uid's nt kompatible
-vollständige C++ ABI
-bsd lizens
-keine gnu abhängikeiten

Nach dem https implementiert werde ich mich wieder meinem elfparser widmen damit ich endlich in System chrooten kann und danach stdio implementieren danach noch paar kleine posix geschichten damit hoffentlich llvm unter der chroot kompeliert der basis Compiler für das System. Danach Feinit damit ich ein init system habe und CMake support für Linux Kernel und Python.

Quiche Lorraine

@Tuxist1 sagte in Huge Zahlenklasse mit RSA Absturz bei deconstructor:

Ich versuche da Abhilfe zu schaffen da ich als Rentner jetzt zeit dafür habe.

Wenn ich so deinen letzten Beitrag lese, habe ich das Gefühl dass du dich übernimmst. Die Libc nachzuprogrammieren ist keine kleine Sache, ebenso Verschlüsselung und erst Recht nicht eine Grundlage eines Betriebssystems.

Aus meiner Sicht wäre das Aufgabe eines kleinen Entwicklungsteams für die nächsten X Jahre.

Tuxist1

@Quiche-Lorraine da hast du recht bin ich schon 4 Jahre bei spalte immer wieder Sachen ab die ich auch so gebrauchen kann, das hält meine Motivation am laufen. Das schöne ist mal lernt unheimlich viel.