cast unsigned char * (uint8_t *) zu const char *

Habe ich eine Funktion, die einen uint8_t * argument :

uint8_t* ihex_decode(uint8_t *in, size_t len, uint8_t *out)
{
    uint8_t i, hn, ln;

    for (i = 0; i < len; i+=2) {
        hn = in[i] > '9' ? (in[i]|32) - 'a' + 10 : in[i] - '0';
        ln = in[i+1] > '9' ? (in[i+1]|32) - 'a' + 10 : in[i+1] - '0';

        out[i/2] = (hn << 4 ) | ln;
    }

    return out;
}

Ich diese Funktion mit :

uint8_t data[SPM_PAGESIZE]; //SPM_PAGESIZE = 256 bytes
uint8_t sysex_data[SPM_PAGESIZE/2];
ihex_decode(data, strlen(data), sysex_data);

Aber in diesem Fall, mein compiler (avr-gcc) return eine Warnung :

main.c|89|warning: pointer targets in passing argument 1 von "strlen" unterscheiden sich im Fehler
/usr/include/string.h|399|note: expected " const char *", aber argument ist vom Typ 'uint8_t *'

So, ich habe eine Lösung gefunden, indem Sie die Typumwandlung der Daten var :

ihex_decode(data, strlen((const char *)data), sysex_data);

Verschwindet die Warnung, aber ich Frage mich, ob diese Lösung sicher ist.

Gibt es eine bessere Möglichkeit ?

Dank

Warum sind Sie mit uint8_t für ein Typ, der offenbar char ?
Weil mein Programm läuft auf dem mikrocontroller. So kann ich nicht negativen Wert.
Das macht keinen Sinn. Die Eingabe von Daten zu sein scheint ASCII-hex, so ist es natürlich char. Die Ausgabe der Daten natürlich bleiben würde, als uint8_t.
So schlagen Sie vor, mich zu ändern uint8_t *in zu char *in ?
Das problem hier ist nicht mit uint8_t, das problem ist, dass Leute, die glauben, dass char ist eine geheimnisvolle, Magische Art. Wenn Sie sorgfältig prüfen, werden Sie finden, dass es keine negativen zahlen in der ASCII-Tabelle. Also mit uint8_t für ASCII-Zeichen ist völlig in Ordnung, in der Tat, es ist die richtige Art zu verwenden. Der C-standard geschieht, zu verwenden, char-Typ für historische/unlogische Gründe, das ist, warum Sie bekommen die Warnung. Nur festgelegten Weg die Warnung, uint8_t ist korrekt.

InformationsquelleAutor Loïc G. | 2011-08-10

  1. 4

    Ist es sicher. Der Fehler hat mit der Mischung von Integer-Datentyp ohne Vorzeichen 8 bit mit Zeichen, die unterzeichnet werden, wenn Sie nur char.

    Sehe ich jedoch, dass die Funktion akzeptiert uint8_t und hat character rechnen, so sollte es akzeptiert chars (oder const chars, für die Sache). Beachten Sie, dass eine Zeichen-Konstante 'c' ist der Typ char, und Sie sind mischen von signed und unsigned in die Ausdrücke in ihex_decode, so dass Sie müssen vorsichtig sein, zu vermeiden, überläufe oder negative zahlen behandelt werden als große positive zahlen.

    Einen letzten style-note. Als in wird nicht geändert, sollte es Lesen const uint8_t* in (oder const char* in wie oben) in den Parametern. Ein weiteres Stil-Fehler (das kann führen zu sehr schlechten Fehler) ist, dass Sie akzeptieren len als size_t, aber die erklären, die i loop variable als uint8_t. Was ist, wenn die Zeichenfolge länger als 255 Byte Länge?

    Char kann signed oder unsigned, das ist die Aufgabe der Implementierung, soweit ich weiß.
    OK, @Rudy, add up "in diesem Fall" 🙂
    Man könnte es Bearbeiten.
    Tatsächlich, es ist nicht sicher, theoretisch, obwohl Sie keine wirkliche Welt, die Implementierung, die ich je gesehen habe, ein problem haben würde. Es ist möglich für char mehr als 8 bit. In einer solchen Implementierung uint8_t wäre, haben die gleiche Größe wie char (da sizeof(char) 1) würde aber ignorieren die oberen paar bits. So eine Umsetzung, kann sich ein uint8_t als null aber nicht gleich null ist, wenn die Besetzung auf ein char. Somit strlen könnte der index das Ende des Arrays.
    ein genaue Breite geben, wenn eine Umsetzung nicht über eine type ist genau 8 bits, dann ist es nicht zu bieten uint8_t.

    InformationsquelleAutor Diego Sevilla

  2. 1

    Alles, was ist non-const * sicher sein kann, gegossen const * in C. Es speichern.

    Aber die Warnung ist nicht zu verwerfen const Qualifikation.
    Die Warnung wird in Bezug auf die Umwandlung von uint8_t * zu char *
    Die Frage, die ich beantwortet war: "ich Frage mich, ob diese Lösung sicher ist.'. Ich antwortete es.

    InformationsquelleAutor Patrick B.

  3. 1

    Dies ist sicher. Die Warnung (ich glaube) erscheint, da Sie eine Umwandlung von unsigned auf signed.

    Ich bin mir nicht ganz sicher, dass es ist sicher. Was wäre der Zweck der Warnung, wenn es keine Konsequenzen?
    Nicht, weil strlen() erwartet einen const char * ?
    Nein, es ist nicht.
    Nein, char* kann immer geworfen werden, const char* implizit, als es stärkt nur die Einschränkungen. signiert <-> unsigned, jedoch kann sich ändern, die interpretation der Daten und brechen einige algorithmen, so gibt es eine Warnung über es. 0 ist das gleiche aber in beiden Darstellungen, so strlen sollte gut funktionieren.

    InformationsquelleAutor the_nic

  4. 0

    Sein sicher, ist das Spektrum der char < uint8_t.

    InformationsquelleAutor Kamath

Schreibe einen Kommentar