Frust der Woche "strcpy"

[Klebwax]

Mal kein Problem, das gelöst werden muß, aber eines das mich gestern 4 Stunden gekostet hat.
Ich progge schon seit einiger Zeit mit ATMEL Studio 7 in C herum.
Gestern wollte ich einen String in einen anderen mit strcpy reinkopieren und das wollte nicht funktionieren.
.......

Warning pointer targets in passing argument 1 of 'strcpy' differ in signedness [-Wpointer-sign]
....

Ein char ist ja eigentlich im Prinzip das gleiche wie ein uint8_t.
Übrigens einen unsigned char mag der Compiler auch nicht! Und spuckt die selbe Fehlermeldung aus.

Mal davon abgesehen, daß "Warning" kein Fehler ist, lernt man daraus follgendes: die Funktionen der libc, die mit str anfangen, behandeln Strings, Zeichenketten. Diese bestehen in C aus chars, Buchstaben. Wenn man Arrays von uint8_t kopieren will, benutzt man mencpy().

Man hätte da auch nicht lange suchen müssen. Wie strcpy() definiert ist, steht in string.h. Daher (und nur daher) weiß das auch der Compiler. Typischerweise kann man sich das auch mit der IDE anzeigen lassen. Da steht, der Typ des ersten Parameter ist char*. Und der Compiler hat richtig bemerkt, bei zeile steht uint8_t *, also etwas anderes. Die Stringlibray ist für den Compiler genauso unbekannt, wie von dir geschriebener Code.

Man könnte das Problem umgehen, wenn man in string.h statt char * uint8_t * schreiben würde. Damit wäre dann natürlich jeder andere Code, der strcpy() benutzt kaputt.

Ein char ist etwas anderes, als uint8_t. In anderen, moderneren Sprachen werden Zeichen als Unicode dargestellt. Und das sind keine 8 Bit. Es schadet also nicht, sich auch in C daran zu gewöhnen, etwas pingeliger zu sein, wenn es um Strings geht.

Übrigens, der Compiler und die libc sind unterschiedliche Dinge. Der GCC ist immer der GCC und benimmt sich gleich. Die unterstützenden Libraries, zum Beispiel für Integer oder Long-Integer Mathematik etc. sind natürlich CPU-abhängig und damit unterschiedlich.

MfG Klebwax

[HaWe]

Man könnte das Problem umgehen, wenn man in string.h statt char * uint8_t * schreiben würde.
Ein char ist etwas anderes, als uint8_t.

Nein, anders herum!
Man könnte das Problem umgehen, wenn man für einen ctring (string.h) für einen AVR (!)
statt char *
int8_t *
schreiben würde,
denn char ist auf AVRs signed, wie ich bereits schrieb!

[wkrug]

Alles schön und gut was Ihr hier schreibt und vermutlich auch richtig.
Nach der Sinnhaftigkeit wird man aber schon fragen dürfen, ob man für eine signed 8 Bit Variable 3 bzw. 4 Verschiedene Definitionen braucht, die dann wiederum nur mit bestimmten Funktionen laufen. Eine Eindeutige sollte da doch auch reichen?
Ganz zu schweigen von den Sonderfunktionen, die man dann noch für die Flash und EEProm Behandlung braucht.

Mit diesen " Spielchen " hab Ich schon viel Zeit vertrödelt.

Aber da wird man wohl damit leben müssen.
Betrachten wir's positiv - Wieder was gelernt.

[HaWe]

Alles schön und gut was Ihr hier schreibt und vermutlich auch richtig.
Nach der Sinnhaftigkeit wird man aber schon fragen dürfen, ob man für eine signed 8 Bit Variable 3 bzw. 4 Verschiedene Definitionen braucht, die dann wiederum nur mit bestimmten Funktionen laufen. Eine Eindeutige sollte da doch auch reichen?
(...)
Mit diesen " Spielchen " hab Ich schon viel Zeit vertrödelt.

Aber da wird man wohl damit leben müssen.
Betrachten wir's positiv - Wieder was gelernt.

braucht man nicht -
char alleine reicht immer.
stdint ist eine extra Lib, die kam erst einiges später.
Aber C ist nun mal auf verschiedenen Libs aufgebaut, die alle ihre eigenen Regeln haben, und ein kurzer Blick in die Lib/Funktions-Definitionen zeigt ja auch sofort, was man braucht.
An der signed/unsigned char Problematik für AVR und ARM habe ich mir auch schon die Zähne ausgebissen und die Haare gerauft.
Aber wie es so schön heißt: RTFM !