Frage zur C-Code


  • Mod

    Es setzt/löscht/erfragt das flag_number'te Bit in dem, auf was adr zeigt.



  • Das Programm hat Fehler (z.B. der weiterer Programmablauf bei Feld = NULL) und der Autor weiß nicht, was er tut (z.B. Zeile 80).


  • Mod

    Ich finde Zeile 48 sehr interessant. Das passt nicht so recht dazu, dass die diskutierten Funktionen mit einzelnen Bits arbeiten.



  • Oh, und malloc wird in der Schleife aufgerufen, free aber außerhalb.



  • Dann passt das fflush(stdin) ja perfekt ins Bild.



  • Hallo,
    hat sich erledigt kann zu. Danke für jeden Antwort.
    gruß



  • SeppJ schrieb:

    Es setzt/löscht/erfragt das flag_number'te Bit in dem, auf was adr zeigt.

    Nope, adr ist der Beginn eines char-Arrays.

    Der Code behandelt einen fortlaufenden Speicherbereich aus chars als wäre es ein Array aus Bits.


  • Mod

    BitFiddler schrieb:

    SeppJ schrieb:

    Es setzt/löscht/erfragt das flag_number'te Bit in dem, auf was adr zeigt.

    Nope, adr ist der Beginn eines char-Arrays.

    Der Code behandelt einen fortlaufenden Speicherbereich aus chars als wäre es ein Array aus Bits.

    Nein.



  • SeppJ schrieb:

    BitFiddler schrieb:

    SeppJ schrieb:

    Es setzt/löscht/erfragt das flag_number'te Bit in dem, auf was adr zeigt.

    Nope, adr ist der Beginn eines char-Arrays.

    Der Code behandelt einen fortlaufenden Speicherbereich aus chars als wäre es ein Array aus Bits.

    Nein.

    Doch. Habe sowas mal selbst programmiert. Sieht fast genau so aus.


  • Mod

    BitFiddler schrieb:

    Doch. Habe sowas mal selbst programmiert. Sieht fast genau so aus.

    So, so. Ein Programm, das du geschrieben hast, macht etwas anderes, als das Programm des TE. Daher ist das was ich darüber geschreiben habe, was das Programm des TE macht, falsch, weil dein Programm etwas anderes macht. Super Argument.



  • SeppJ schrieb:

    BitFiddler schrieb:

    Doch. Habe sowas mal selbst programmiert. Sieht fast genau so aus.

    So, so. Ein Programm, das du geschrieben hast, macht etwas anderes, als das Programm des TE.

    Nee, fast das selbe

    // flag_number ist bit-offset, adr ist Startadresse des Bit-Arrays
    void set_flag_v2(unsigned int flag_number, void *adr) 
    { 
        char *pc = (char *)adr;             // Wir brauchen einen char*
        int ioff = (flag_number - 1) / 8;   // ioff ist index auf den einzelnen char
        int ibit = (flag_number - 1) % 8;   // ibit ist ein bit in diesem char  
        pc[ioff] = pc[ioff] | (1 << ibit);  // char laden, das bit auf 1 setzen und char zurückschreiben
    }
    

    Habe ich nun ...
    char mem[100];

    und mache ....
    set_flag_v2 (300, mem);

    Dann wird das 3. Bit im 37. Element von mem auf 1 gesetzt
    Logisch ist es das 300. Bit eines Bit-Arrays.
    Kann sein, dass ich mich irgendwo verzählt habe, aber so etwa funktioniert der Code.


  • Mod

    Ja, und? Was hat irgendetwas davon mit

    BitFiddler schrieb:

    SeppJ schrieb:

    Es setzt/löscht/erfragt das flag_number'te Bit in dem, auf was adr zeigt.

    Nope, adr ist der Beginn eines char-Arrays.

    zu tun?



  • SeppJ schrieb:

    Ja, und? Was hat irgendetwas davon mit

    BitFiddler schrieb:

    SeppJ schrieb:

    Es setzt/löscht/erfragt das flag_number'te Bit in dem, auf was adr zeigt.

    Nope, adr ist der Beginn eines char-Arrays.

    zu tun?

    Das Bit wird nicht immer in dem Datenwort verändert, auf das adr zeigt, sondern es liegt in den meisten Fällen weiter vorn. Die "effektive Bitadresse" wird in der Funktion berechnet.


  • Mod

    BitFiddler schrieb:

    SeppJ schrieb:

    Ja, und? Was hat irgendetwas davon mit

    BitFiddler schrieb:

    SeppJ schrieb:

    Es setzt/löscht/erfragt das flag_number'te Bit in dem, auf was adr zeigt.

    Nope, adr ist der Beginn eines char-Arrays.

    zu tun?

    Das Bit wird nicht immer in dem Datenwort verändert, auf das adr zeigt, sondern es liegt in den meisten Fällen weiter vorn. Die "effektive Bitadresse" wird in der Funktion berechnet.

    😕 Das widerspricht in keinster Weise dem, was ich sagte.



  • SeppJ schrieb:

    BitFiddler schrieb:

    SeppJ schrieb:

    Ja, und? Was hat irgendetwas davon mit

    BitFiddler schrieb:

    SeppJ schrieb:

    Es setzt/löscht/erfragt das flag_number'te Bit in dem, auf was adr zeigt.

    Nope, adr ist der Beginn eines char-Arrays.

    zu tun?

    Das Bit wird nicht immer in dem Datenwort verändert, auf das adr zeigt, sondern es liegt in den meisten Fällen weiter vorn. Die "effektive Bitadresse" wird in der Funktion berechnet.

    😕 Das widerspricht in keinster Weise dem, was ich sagte.

    Es widerspricht mindestens dem: https://www.c-plusplus.net/forum/p2549692#2549692


  • Mod

    BitFiddler schrieb:

    Es widerspricht mindestens dem: https://www.c-plusplus.net/forum/p2549692#2549692

    Es ist dem Code vollkommen egal, ob das chars oder wer weiß was sind. Im Orgiginalcode ist wird ein void* via void* übergeben! Wo sind da deine chars? Der Datentyp ist vollkommen irrelevant und der Code geht auch genau so damit um.

    Was ist los mit dir? Dies ist Computercode. Dies ist kein Gedicht, dass man irgendwie interpretieren kann, oder zu dem man eine persönliche Meinung haben kann. Es ist objektiv, was der Code macht und was nicht, da gibt es nichts zu diskutieren.



  • SeppJ schrieb:

    BitFiddler schrieb:

    Es widerspricht mindestens dem: https://www.c-plusplus.net/forum/p2549692#2549692

    Es ist dem Code vollkommen egal, ob das chars oder wer weiß was sind. Im Orgiginalcode ist wird ein void* via void* übergeben! Wo sind da deine chars? Der Datentyp ist vollkommen irrelevant und der Code geht auch genau so damit um.

    Schau mal unauffällig auf die Variable "pc" in der Funktion, was das ist und was damit gemacht wird. 😉


  • Mod

    BitFiddler schrieb:

    Schau mal unauffällig auf die Variable "pc" in der Funktion, was das ist und was damit gemacht wird. 😉

    Und schau du mal ganz auffällig auf die Variable Feld in der main und die Variable adr in der Funktion, was das ist und was damit gemacht wird.

    Wen interessiert der Datentyp von irgendeinem Zwischenergebnis, wenn es um die Funktionalität von Code geht? Mit dem gleichen Argument könntest du behaupten, es ginge um ints, weil ioff ein int ist. Merkst du, was für einen Blödsinn du laberst?

    Schau dir mal Funktionen an, die auf char-Feldern arbeiten, z.B. alles aus string.h. Keine einzige davon nimmt void* entgegen, sondern alle nehmen char*. warum? Weil sie nur auf char* funktionieren können!

    Schau dir hingegen allgemeine Funktionen für alle Datentypen an, z.B. qsort, realloc, memset, etc. Keine einzige davon nimmt char* entgegen. Warum? Weil sie eben auf allem funktionieren, nicht nur auf chars! Und trotzdem, wenn du die mal nachprogrammierst, wird bei vielen davon in deren Implemntierung ein char* auftauchen. Ein minderes technisches Details, völlig unerheblich für die Funktionalität.

    Ich werde deinen weiteren Schmarrn nicht mehr mit einer Antwort würdigen.



  • SeppJ schrieb:

    Wen interessiert der Datentyp von irgendeinem Zwischenergebnis, wenn es um die Funktionalität von Code geht?

    In dem Fall ist der char-Datentyp ziemlich entscheidend für die Funktion. Sie sieht den Pointer als die Basisadresse einer Folge von 8-Bit Speicherzellen, die bitweise manipuliert werden können. Ich will dem Programmierer mal unterstellen, dass er weiß, wie seine Hardware organisiert ist. Auch wenn er nicht weiß, dass char nicht zwingend 8 Bit breit ist.

    SeppJ schrieb:

    Schau dir hingegen allgemeine Funktionen für alle Datentypen an, z.B. qsort, realloc, memset, etc. Keine einzige davon nimmt char* entgegen. Warum? Weil sie eben auf allem funktionieren, nicht nur auf chars!

    Leider hasst du vergessen zu erwähnen, was diese spezielle Funktion mit allgemeinen Funktionen zu tun hat. Aber egal.

    SeppJ schrieb:

    Ich werde deinen weiteren Schmarrn nicht mehr mit einer Antwort würdigen.

    Eine weise Entscheidung. Du würdest dich nur noch weiter verzetteln.


Anmelden zum Antworten