Hallo,
ich versuche gerade das Small Protokoll von ELECTRONIC ASSEMBLY an
meinen Controller ATmega16 und Compiler/Debugger (AVR Studio/ AVR
Simulator) anzupassen.
Die meisten Compilerfehler habe ich schon ausmertzen können.
Ich bekomme aber 10 mal den Fehler:
expected 'unsigned char *' but argument is of type 'char *'
(für display.c)
Und 10 mal die Warnung:
pointer targets in passing argument 1 of 'eDIP_command6' differ in
signedness
(auch für display.c)
Ich habe mal ein beispiel "ausgeschnitten" welches diesen Fehler+Warnung
produziert:
display.h
******
1
#define ESC 35
2
3
#define eDIP_YW(n1,n2) eDIP_command2("YW", n1, n2) //#YW=Write output port: #YW n1,n2 (n1=0: Set all ports to n2=8-bit binary value; n1=1..8: n2=0 Reset; n2=1 Set; n2=2 Invert port)
Mein Englisch ist gut genug, um die Meldungen zu verstehen. Trotzdem
DANKE!
Ich bin der Meinung, dass in dem Code ausschließlich "unsigned char"
verwendet wird, deshalb verstehe ich es ja nicht.
Außerdem ist der Orginalcode ja nicht von mir und hat auch
funktioniert...eben auf einem andern System...
deine String-Konstante "YW" ist signed (weil beim Compiler default
signed ist bei unspezifiziert). Daher die Warnung. Alternativ in den
Optionen einstellen, dass solche unspezifizierten Datentypen unsigned
sein sollen.
Ein Fest a. schrieb:> Ich bin der Meinung, dass in dem Code ausschließlich "unsigned char"> verwendet wird, deshalb verstehe ich es ja nicht.
Kann ja sein, aber erstens zeigst du den Code dafür nicht, und zweitens:
woher weisst du das?
Oliver
Ein Fest a. schrieb:> Ich bekomme aber 10 mal den Fehler:> expected 'unsigned char *' but argument is of type 'char *'> (für display.c)> Und 10 mal die Warnung:> pointer targets in passing argument 1 of 'eDIP_command6' differ in> signedness> (auch für display.c)
Das ist ausschließlich beim AVR-GCC so, alle anderen Compiler sind nicht
so pingelig. Er will unbedingt "char" für alle Strings und nichts
anderes.
Es ist natürlich Quatsch, da es keine negativen Zeichen gibt, also jeder
8Bit-Typ würde vollkommen korrekt compilieren.
Ich hab keine Ahnung vom Compilerbau, sonst hätte ich diese vollkommen
überflüssige Warnung schon deaktiviert.
Entweder Du schaltest alle Warnungen ab oder castest an den
entsprechenden Stellen nach (void*).
Peter
Peter Dannegger schrieb:> Quatsch,
Stimmt. Denn das hat weder was mit avr-gcc, noch mit strings zu tun.
Ein Fest a. schrieb:> _Bool eDIP_command6(unsigned char * data,
Wenn man dann da einen signed char * übergibt, gibts halt eine Warnung.
Und das ist auch gut so ;)
Oliver
Oliver schrieb:> Peter Dannegger schrieb:>> Quatsch,>> Stimmt. Denn das hat weder was mit avr-gcc, noch mit strings zu tun.>> Ein Fest a. schrieb:>> _Bool eDIP_command6(unsigned char * data,>> Wenn man dann da einen signed char * übergibt, gibts halt eine Warnung.> Und das ist auch gut so ;)
Ganz so ist das nicht. Der Compiler muss 3(!) Character Datentypen
unterscheiden:
char
signed char
unsigned char
Ja. Auch wenn char entweder signed oder unsigned sein muss, ist es doch
zunächst erst mal ein dritter eigenständiger Datentyp.
So wie die Funktion benutzt wird:
Mach halt das erste Funktions-Argument zu einem char* und die Sache ist
gegessen. Das ist, so wie das aussieht, sowieso immer ein String.
Und wenn man ganz pingelig ist, dann müsste das erste Funktionsargument
eigentlich ein const char* sein, denn genau das ist der Datentyp eines
String Literals: Array von const Charactern.
Allerdings wurde bei der Einführung von 'const' in die Sprache für
diesen Fall extra eine Ausnahmeregelung zugelassen, weil man sich
ansonsten bei vorhandenen Programmen vor lauter Fehlermeldungen nicht
mehr hätte retten können.
Karl Heinz Buchegger schrieb:> Ganz so ist das nicht. Der Compiler muss 3(!) Character Datentypen> unterscheiden:> char> signed char> unsigned char
Das tut er auch. Nur er warnt nicht, wenn man diese Typen untereinander
zuweist. Er mach das stillschweigend und man wundert sich über die
lustigsten Effekte.
Er darf auch nicht warnen, denn solche Zuweisungen sind legal.
Die Warnung erfolgt nur bei der Zuweisung von Pointern darauf.
Da aber char-Pointer in der Regel Strings sind, ist dort das Vorzeichen
schnurzpipegal und damit die Warnung völliger Quatsch.
Ich finde es auch schön, wenn der Datentyp sofort ersichtlich ist.
Ich benutze also gar kein "char" mehr, sondern nur noch "uint8_t" bzw.
"int8_t".
Und für die Stringfunktionen muß man dann eben nach (void*) casten, um
diese völlig unsinnige Warnung zu unterdrücken.
Peter
Peter Dannegger schrieb:> Und für die Stringfunktionen muß man dann eben nach (void*) casten, um> diese völlig unsinnige Warnung zu unterdrücken.
Worüber redet ihr eigentlich?
1
externvoidsf(constsignedchar*);
2
externvoiduf(constunsignedchar*);
3
externvoidf(constchar*);
4
5
voidfoo(void)
6
{
7
sf("a");
8
uf("b");
9
f("c");
10
}
Bringt keine einzige Warnung oder Fehler, es sei denn mann fordert die
Warnung mit -Wpointer-sign explizit an, von daher versteh ich das
Gemeckere nicht:
foo.c:9:5: warning: pointer targets in passing argument 1 of 'sf' differ
in signedness [-Wpointer-sign]
foo.c:3:13: note: expected 'const signed char *' but argument is of type
'char *'
foo.c:10:5: warning: pointer targets in passing argument 1 of 'sf' diffe
r in signedness [-Wpointer-sign]
foo.c:4:13: note: expected 'const unsigned char *' but argument is of ty
pe 'char *'
Will man einen Fehler dafür, setzt man eben -Werror oder
-Werror=pointer-sign. Und wenn man keinen Fehler mag, dannn gibt man
diese Optionen einfach nicht an.
Peter Dannegger schrieb:> Und für die Stringfunktionen muß man dann eben nach (void*) casten, um> diese völlig unsinnige Warnung zu unterdrücken.
???
Stringfunktionen nehmen einen char* als Argument, und das ist der
passenden Datentyp für Strings. Wenn die den bekommen, gibt es auch
keine Warnung.
Oliver