Thema: char nach int umwandeln

[Cool-Andy]

Danke, dass du das Thema ausgegraben hast.
Könntest du bitte den Code posten, wie du es dir gedacht hast?
Weil, ich versuch es grad mit einer while-Schleife

Code: [Auswählen]

...
while (zahl != 0)
{
...
und des funzt net.
Wäre wirklich sehr nett von dir!
 

[kevin]

Wenn genau derselbe Code unter Linux/Windows funktioniert und in deinem Kernel nicht, würde ich nicht an der Funktion zweifeln, sondern am Code drum herum, zum Beispiel der Ausgabe. Wenn du überhaupt nicht weiterkommst, lad halt nochmal irgendwo deinen kompletten Code hoch, damit es jemand selber ausprobieren kann.

[Cool-Andy]

Wenn ich unter Windows debugge bricht die Anwendung in der Umwandlung von int nach char ab!

[Cool-Andy]

OK, meine "int to char"-Funktion:

Code: [Auswählen]

void itoc (int value)
{
    int rest = 0;
    char letter[1];
    char string[100];
    int i = 0;
    int z;
    while (value != 0)
    {
        rest = value%10;
        letter[0] = (char) (0x30+rest);
        string[i] = letter[0];
z = value/10;
        i++;
    }
    i++;
    string[i] = '\0';
    printf ("x: ");
    printf (string);
}

Wenn ich diese Funktion starte, bleibt der Bildschirm schwarz! 

EDIT:
Ich hab mein Fehler schon selber gefunden. Hier mal mein geupdateter Code:

Code: [Auswählen]

void itoc (int value)
{
int rest = 0;
    char letter[1];
    char string[100];
    int i = 0;
int z;
    while (value != 0)
    {
        rest = value%10;
        letter[0] = (char) (0x30+rest);
        string[i] = letter[0];
z = value/10;
value = z;
        i++;
    }
    i++;
    string[i] = '\0';
printf ("x: ");
    printf (string);
}

Hat jemand jetzt noch ne Idee, wie ich den String umdrehen kann? 

[erik.vikinger]

Hallo,

Code: [Auswählen]

void rotate_str(char* const text,const int length)
{
  //bei Länge 1 oder 0 nichts machen :
  if (length < 2) { return; }

  //Indices um von vorne und hinten bis zur Mitte zu arbeiten :
  int low = 0;
  int high = length - 1;

  while (low < high)
   {
     //Zeichen vertauschen :
     char ctemp = text[low]; text[low] = text[high]; text[high] = ctemp;
     //Indices weiterschieben :
     low++; high--;
   }
}'length' natürlich ohne das 0-Byte am Text-Ende, wie immer alles ohne Gewähr
Sollte aber klappen.


Grüße
Erik

[kevin]

Code: [Auswählen]

void reverse_string(char* s)
{
    char* p;
    for (p = s + strlen(s) - 1; *s && p > s; *p ^= *s, *s ^= *p, *p-- ^= *s++);
}Tut mir leid, ich konnte nicht anders.

[Cool-Andy]

Tut mir leid, ich konnte nicht anders.

Was auch immer mir damit sagen wolltest, die Funktion von erik.vikinger hat funktioniert.

Vielen Dank! 

[kevin]

Meine funktioniert auch, aber ich würde sie aus dem offensichtlichen Grund der Nichtoffensichtlichkeit nirgends so einbauen.

[Cool-Andy]

Aja, OK! 

[erik.vikinger]

Hallo,

Tut mir leid, ich konnte nicht anders.

Dieses Gefühl kenne ich nur zu gut. Aber in diesem konkreten Fall hättest Du der Versuchung ruhig widerstehen dürfen. Sowas würde ich ja schon fast in die Kategorie "Human-Code-Obfuscator" einsortieren.

In meiner Variante würde ich noch zwei Korrekturen vornehmen:

Code: [Auswählen]

 //bei Null-Pointer oder Länge 1 oder 0 nichts machen :
  if ( (text == NULL) || (length < 2) ) { return; }

Code: [Auswählen]

    //Zeichen vertauschen :
     const char ctemp = text[low]; text[low] = text[high]; text[high] = ctemp;Die erste Korrektur ist sicher offensichtlich (hat taljeth in seiner Variante auch drin) und die zweite sagt das 'ctemp' nicht verändert werden darf (alternativ kann man auch 'register' anstatt 'const' nehmen um etwas mehr Performance zu bekommen, ein guter Compiler sollte das aber selber sehen).
Achja, generell 'unsigned int' anstatt 'int' währe dem Problem angemessener da Strings üblicherweise keine negative Länge haben.

EDIT: den Funktions-Namen von taljeth finde ich besser.


Grüße
Erik

[kevin]

Die erste Korrektur ist sicher offensichtlich (hat taljeth in seiner Variante auch drin)

Nein, wenn sie NULL kriegt, segfaultet meine Funktion, ganz im Sinne der klassischen C-Stringfunktionen. Schon bei der Initialisierung von p (im strlen), aber auch die for-Bedingung wäre dafür falschrum geschrieben.

[erik.vikinger]

Hallo,

aber auch die for-Bedingung wäre dafür falschrum geschrieben.

Stimmt, jetzt hab ichs gesehen.

Code: [Auswählen]

; *s && p > s;Mit dem '*s' prüfst Du ja das s nicht auf ein 0-Byte zeigt (und nicht das s kein Null-Pointer ist), was eigentlich nicht passieren dürfte da s ja nur bis zur Hälfte durch den String wandert und bei einem leeren String sollte 'p > s' für einen Schleifen-Abbruch sorgen.

ganz im Sinne der klassischen C-Stringfunktionen

Aha, wusste ich nicht. Wenn eine C++ Library eine Exception wirft ist das ja in Ordnung, die Exception kann man fangen oder eben nicht, aber den ganzen Prozess vom OS killen zu lassen find ich nicht gut und ein Signal-Handler im User-Programm kann IMHO nicht so viel ausrichten da er kaum rauskriegt wo im Code das Problem entstand und erst recht nicht das Programm sinnvoll weiterlaufen lassen kann.

wenn sie NULL kriegt, segfaultet meine Funktion

Woher kommt eigentlich "segfault"? Gab es mal ein UNIX das Segmentierung unterstützt hat? Da ja in Wirklichkeit ein Pagefault (die 0te Page lässt man ja extra dafür immer ungemappt) dahinter steckt find ich den Namen irgendwie unpassend.


@Cool-Andy : sorry für meine OT-Frage aber ich gehe davon aus das Dein eigentliches Problem von diesem Thread gelöst ist.


Grüße
Erik

[kevin]

Mit dem '*s' prüfst Du ja das s nicht auf ein 0-Byte zeigt (und nicht das s kein Null-Pointer ist), was eigentlich nicht passieren dürfte da s ja nur bis zur Hälfte durch den String wandert und bei einem leeren String sollte 'p > s' für einen Schleifen-Abbruch sorgen.

Stimmt, das ist Blödsinn. Gedacht war es für den leeren String.

Aha, wusste ich nicht. Wenn eine C++ Library eine Exception wirft ist das ja in Ordnung, die Exception kann man fangen oder eben nicht, aber den ganzen Prozess vom OS killen zu lassen find ich nicht gut und ein Signal-Handler im User-Programm kann IMHO nicht so viel ausrichten da er kaum rauskriegt wo im Code das Problem entstand und erst recht nicht das Programm sinnvoll weiterlaufen lassen kann.

Man übergibt den Stringfunktionen eben keine Nullpointer.

Ich hab jetzt keine großartige Lust, damit rumzuspielen, aber theoretisch müsste der Signalhandler die Codestelle schon rauskriegen, das sollte ja seine eigene Rücksprungadresse sein. Ob man damit was sinnvolles anstellen kann, ist die andere Frage. Wahrscheinlich könnte man mit setjmp/longjmp eher ein Exceptionhandling aufbauen und bräuchte dann die Adresse vom Fault überhaupt nicht.

Woher kommt eigentlich "segfault"? Gab es mal ein UNIX das Segmentierung unterstützt hat? Da ja in Wirklichkeit ein Pagefault (die 0te Page lässt man ja extra dafür immer ungemappt) dahinter steckt find ich den Namen irgendwie unpassend.

Wird wohl so sein, aber ich kann dir nicht sagen, welche Unixe das waren.

Wikipedia sagt: "Die englische Bezeichnung segmentation fault stammt aus einer Zeit, in der Speicherbereiche durch Segmentierung vor unerlaubtem Zugriff geschützt wurden. Heute werden andere Schutzmechanismen verwendet, insbesondere Paging; der Terminus segmentation fault hat sich aber unverändert erhalten."

[erik.vikinger]

Hallo,

Man übergibt den Stringfunktionen eben keine Nullpointer.

Ah ja, das ist natürlich richtig. Trotzdem könnte z.B. strlen() -1 zurückliefern, würde ich zumindest als nett einstufen.
Meine Frage ziehlte aber eher darauf ab ob das so definiert ist das die Standard-Funktionen eben nicht selber auf einen NULL-Pointer prüfen sollen. Es könnte ja auch eine Plattform geben wo NULL-Pointer nicht zu einer (CPU-)Exception führen.

.... Ob man damit was sinnvolles anstellen kann, ist die andere Frage.

Es währe auf jeden Fall mit erheblicher Arbeit für den Programmierer verbunden, dann sollte man doch lieber zu C++ wechseln und diese Arbeit dem Compiler überlassen.

".... der Terminus segmentation fault hat sich aber unverändert erhalten."

Na dann wird es ja Zeit das er auf meiner Plattform wieder zu altem Ruhm aufsteigt.
Jedenfalls hab ich extra dafür jedem Segment nicht nur ein Limit sondern auch ein Minimum angedacht, somit ist das Offset 0 (falls das OS die Segmente so einrichtet) nicht nutzbar und löst einen segfault aus. Den Selector 0 lehnt die CPU ebenfalls ab.
Das Minimum möchte ich nun aber auch benutzen um nicht Speicher am Anfang der Segmente zu verschwenden falls ich mal ASLR implementieren sollte.


Grüße
Erik

[kevin]

Ah ja, das ist natürlich richtig. Trotzdem könnte z.B. strlen() -1 zurückliefern, würde ich zumindest als nett einstufen.

Um ein bisschen Erbsen zu zählen: strlen gibt einen size_t zurück, also kann es kein -1 liefern. Aber ja, natürlich hätte man das so definieren können, dass es irgendeine Form von Fehlerbehandlung macht (allerdings bringt der Test auf NULL auch nicht so viel, im Zweifelsfall steckt das Ding in einer struct und hat ein Offset von NULL) - hat man aber eben nicht.

Meine Frage ziehlte aber eher darauf ab ob das so definiert ist das die Standard-Funktionen eben nicht selber auf einen NULL-Pointer prüfen sollen. Es könnte ja auch eine Plattform geben wo NULL-Pointer nicht zu einer (CPU-)Exception führen.

Es ist nicht so definiert, dass sie es nicht prüfen dürfen oder dass sie eine Exception werfen sollen. Für strlen selber ist überhaupt kein Fehlerfall definiert, das Dereferenzieren eines Nullpointers ist explizit undefiniert. Mit strlen(NULL) kann das jeweilige System also machen, was ihm gerade in den Kram passt.