Casten macht Probleme

> Warning: expected 'const uint8_t *' but argument is of type 'unsigned
> char'
>
> Wieso hat er jetzt zu 'unsigned char' und nicht zu 'uint8_t' gecastet?!

Weil Du es hingeschrieben hast. Das ist aber nicht das Problem sondern 
der fehlende Asterisk:

> dez = (uint8_t)Hex2Dez((uint8_t)txt,2);
                                 ^

Oh das ging ja schnell :)

Joachim Drechsel schrieb:
> Das braucht 3 Byte, die terminierende 0 zählt auch mit.

ja stimmt, hatte ich ein meinem Beispiel nicht beachtet. sry

g457 schrieb:
> Weil Du es hingeschrieben hast. Das ist aber nicht das Problem sondern
> der fehlende Asterisk:

Was ist denn ein "Asterisk"? Wie müsste denn die Code Zeile richtig 
lauten?

> Was ist denn ein "Asterisk"? Wie müsste denn die Code Zeile richtig
> lauten?

Die Funktion erwartet einen Pointer auf konstante uint8_t:

>> static uint16_t hex2num (const uint8_t * ascii, uint8_t num)
                                          ^

Du machst aus 'txt' einen einzelnen uint8_t:

> dez = (uint8_t)Hex2Dez((uint8_t)txt,2);
                          ^^^^^^^

Korrekt wäre besagter Pointer:
dez = (uint8_t)Hex2Dez((uint8_t*)txt, 2);
                               ^

g457 schrieb:
> Korrekt wäre besagter Pointer:
> dez = (uint8_t)Hex2Dez((uint8_t*)txt, 2);
>                                ^

ich erstelle also beim casten noch einen konstanten pointer vom typ 
uint8_t, der auf txt[0] zeigt. und dieser pointer wird dann der Funktion 
übergeben?

> ich erstelle also beim casten noch einen konstanten pointer vom typ
> uint8_t, der auf txt[0]

Du hast Recht, einen Pointer auf Konstante (n.b. das ist was anderes als 
ein konstanter Pointer), das hab ich unterschlagen:

dez = (uint8_t)Hex2Dez((const uint8_t*)txt, 2);

Das Rumcasten bei der Nutzung kannst Du dir übrigens ersparen wenn Du es 
bereits bei der Deklaration von txt adäquat anpasst.

g457 schrieb:
> Das Rumcasten bei der Nutzung kannst Du dir übrigens ersparen wenn Du es
> bereits bei der Deklaration von txt adäquat anpasst.

bei der Deklaration von txt anpassen? oha wie geht das denn? txt ist 
doch ein String und kein Pointer. Könntest du mir mal ein Beispiel 
geben?

> txt ist doch ein String und kein Pointer.

Strings sind(tm) Pointer. Letztenendes kommt es drauf welchen Zeigertyp 
man wie und wie oft braucht.

uint8_t* txt = (uint8_t*)"C9";
[..]
dez = (uint8_t)Hex2Dez(txt, 2);

g457 schrieb:
> uint8_t* txt = (uint8_t*)"C9";
> [..]
> dez = (uint8_t)Hex2Dez(txt, 2);

ah cool :)

vielen dank für die hilfe!

>> Strings sind(tm) Pointer.
>
> Nein.

Doch, im Rahmen der Fragestellung ist das korrekt. Für die Allgemeinheit 
beachte man das nicht nur zufällig beigefügt "(tm)".

Stefan Rand schrieb:
> g457 schrieb:
>> Strings sind(tm) Pointer.
>
> Nein.
...
> Ergo: Pointer und Strings sind unterschiedliche Dinge.

Ein C-String ist ein Char-Array. Ein Array ist eine andere Schreibweise 
für Pointer. Doch, ein Array ist eigentlich nichts anderes als ein 
Pointer.

Stefan Rand schrieb:
> Das sieht man schon daran, daß ein Pointer auf heute üblichen Kisten 4
> Byte breit ist, ein String aber auch mehrere Megabyte groß sein kann.

Eine Adresse ist 4-Byte groß, wenn der Adressbus 4-Byte groß ist. Ist er 
größer oder kleiner, so können das z.B. 2-Byte oder auch 8-Byte sein. 
Bei meiner Kiste sind es z.B. 8-Byte, was auch bei einer 64-Bit-Kiste 
nicht anders zu erwarten ist.

Die Funktion malloc() kennt ja jeder. Wenn man hier mehrere Megabytes 
sich reserviert, wie groß ist dann der zurückgegebene Pointer? - Wenn 
ich jetzt so frage, dann habe ich die Frage falsch gestellt. Ich müsste 
nämlich fragen, wie viel Speicher ist hinter diesem zurückgegeben 
Pointer.

Ergo, eigentlich sind Pointer und Arrays sich gar nicht so 
unterschiedlich. Man kann sogar behaupten, sie sind das gleiche.

Leider werden die Begriffe "Pointer" und "Adresse" regelmäßig in einen 
Topf geworfen, obwohl es zwei paar Schuhe sind.

1

const char txt[3] = "C9";

2

uint8_t dez = 0;

3

dez = (uint8_t)Hex2Dez(txt,2);

In diesem Fall steht "txt" als Platzhalter für die Adresse, an der der 
String "C9" im Speicher steht. Es ist aber kein Pointer.
An die Funktion Hex2Dez wird in diesem Beispiel kein Pointer übergeben, 
sondern eine Adresse.
Ein Pointer ist eine Speicherstelle, die eine Adresse aufnehmen kann.
Das würde so aussehen:

1

const char txt[3] = "C9";

2

const char* pointer;

3

uint8_t dez = 0;

4

// Den Pointer mit der Adresse des Strings beschreiben

5

pointer = txt;

6

// Einen Pointer übergeben

7

dez = (uint8_t)Hex2Dez(pointer,2);

Adresse und Zeiger sind ohnehin zwei gefährliche Begriffe in C...

Man kann sich das aber recht einfach klarmachen:

1

char v[10] = "hallo";

2

char *s = "Welt";

Beides sind Initialisierer, allerdings für zwei völlig verschiedene 
Dinge. Die erste Zeile initialisiert sechs Zeichen in dem Vektor 'v'. 
Die zweite Zeile initialisiert einen Zeiger 's'.

Dementsprechend deklarieren folgende Zeilen zwei verschiedene Dinge:

1

char v[10];

2

char *s;

Das bemerkenswerte daran ist lediglich, dass der Vektor 'v' implizit in 
einen Zeiger auf sein erstes Element zerfällt, wenn man ihn als r-value 
benutzt.

'char v[10];' ist viel eher sowas wie 'struct st_t st;' als 'char *s;'.

Sven P. schrieb:
> 'char v[10];' ist viel eher sowas wie 'struct st_t st;' als 'char *s;'.

'char v[10];' ist eher wie ein konstanter Zeiger, wo noch 10 Char's 
auf'm Stack reserviert werden 'char * const s = alloca(sizeof(char) * 
10);'.

mar IO schrieb:
> Sven P. schrieb:
>> 'char v[10];' ist viel eher sowas wie 'struct st_t st;' als 'char *s;'.
>
> 'char v[10];' ist eher wie ein konstanter Zeiger, wo noch 10 Char's
> auf'm Stack reserviert werden 'char * const s = alloca(sizeof(char) *
> 10);'.
Vorsicht damit...

1

  char *s = "Hallo";

2

  char v[10] = "Welt";

3

4

  printf("%p  <-->  %p\n", s, &s);

5

  printf("%p  <-->  %p\n", v, &v);

1

kamajii:~/temp $ c test.c

2

kamajii:~/temp $ ./a.out 

3

0x4006c4  <-->  0x7fff8429f978

4

0x7fff8429f980  <-->  0x7fff8429f980

Karl Heinz Buchegger schrieb:
> Nein bitte nicht. Sagt das keinem Anfänger.

Ja, ich weiß. Für mich ist ein Array einfach eine Aneinanderreihung des 
selben Datentyps... Die Sachen mit Initialisierung usw. ziehe ich gar 
nicht in Betracht, sondern nur die Verwendung. Darum auch die Rede von 
"... eigentlich andere Schreibweise von ...".

Und mit Verwendung meine ich eigentlich das:

http://openbook.galileocomputing.de/c_von_a_bis_z/012_c_zeiger_012.htm#mjeac6320125efac0480883292b05b7c46