Forum: Compiler & IDEs Pointer auf char/ unsigned char Fehlermeldung


von Ein Fest a. (einfest_a)


Lesenswert?

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)
4
#define eDIP_command2(ins,n1,n2)      eDIP_command6(ins,n1,n2,0,0,0,0,2)

display.c
******
1
#include "display.h"
2
3
/*=========================================================================
4
Function:   eDIP_command6
5
Input:    * uchar data, uchar data1, data2, data3, data4, data5, data6, parameter
6
Output:    Bool (true if ACK received, false if transfer failed)
7
Discription:transfers simple commands, with "parameter" variables, this is an
8
      internal function, use definitions (macros)
9
=========================================================================*/
10
11
_Bool eDIP_command6(unsigned char * data, unsigned char data1, unsigned char data2, unsigned char data3, unsigned char data4, unsigned char data5, unsigned char data6, unsigned char parameter)
12
13
{
14
  unsigned char buf[9];
15
16
  buf[0]=ESC;
17
  buf[1]=*data++;
18
  buf[2]=*data;
19
  buf[3]=data1;
20
  buf[4]=data2;
21
  buf[5]=data3;
22
  buf[6]=data4;
23
  buf[7]=data5;
24
  buf[8]=data6;
25
  
26
  return 1;
27
}
28
29
int main(void)
30
{
31
  eDIP_YW(1,0);
32
  return 0;
33
}

Eigentlich ist der Programmteil ja recht überschaubar...aber ich 
verstehe es einfach nicht!

Für eine Hilfe wäre ich dankbar!

Gruß,
Tobi

von Oliver (Gast)


Lesenswert?


von Ein Fest a. (einfest_a)


Lesenswert?

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...

von Thomas K. (muetze1)


Lesenswert?

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.

von Ein Fest a. (einfest_a)


Lesenswert?

Danke!

von Oliver (Gast)


Lesenswert?

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

von Peter D. (peda)


Lesenswert?

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

von Oliver (Gast)


Lesenswert?

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

von Karl H. (kbuchegg)


Lesenswert?

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.
1
_Bool eDIP_command6(const char * data, unsigned char data1, unsigned char data2, unsigned char data3, unsigned char data4, unsigned char data5, unsigned char data6, unsigned char parameter)
2
{
3
  ...
4
}

von Peter D. (peda)


Lesenswert?

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

von Johann L. (gjlayde) Benutzerseite


Lesenswert?

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
extern void sf (const signed char*);
2
extern void uf (const unsigned char*);
3
extern void f (const char*);
4
5
void foo (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.

von Oliver (Gast)


Lesenswert?

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

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.