warning: cast to pointer from integer of different size

A. K. schrieb:
> Was dir der Compiler damit sagen wollte:
>   (unsigned char) hat 1 Byte, (unsigned char *) hat 2
> und das ist zwar nicht falsch, aber könnte ein Hinweis auf ein
> Missverständnis sein.
Ich kann es jetzt nicht testen, aber die Warnung müsste auch kommen, 
wenn für 'i' z.B. uint16_t (32, 64) verwendet wird. Das Entscheidende: 
'i' ist eine normale Variable. Da die Funktion eine Adresse erwartet, 
wird gemeckert. Einfach eine Zahl als Zeiger verwenden, kann ordentlich 
in die Hose gehen. Denn: woher weißt du denn, dass an den Adressen 0..99 
nichts steht? Hier vielleicht zufällig... Deshalb die Warnung. Typecast 
lieber vermeiden!
Man könnte das so machen, dann gibt's (zumindest vom Compiler) 
hoffentlich nichts zu meckern:

1

#define E_MAX 100

2

uint8_t EEMEM Ziel[E_MAX];     // Speicher im EPROM ordentlich reservieren

3

for (uint8_t i=0; i < E_MAX; i++)

4

 eeprom_write_byte(&Ziel[i],0x22);

(Für dieses spezielle Problem gibt's natürlich 'eeprom_write_block')

Ralf schrieb:
> Denn: woher weißt du denn, dass an den Adressen 0..99
> nichts steht?

Grundsätzlich kann ich aber doch davon ausgehen, dass ich der einzige 
bin, der dahin schreibt, oder?

D.h. Wenn ich nirgendwo eine Variable mit EEMEM deklariert habe, und 
keine meiner libraries den EEPROM beschreibt, sollte ich mich beliebig 
austoben dürfen. Richtig?

Oder optimiert der gcc soweit, dass er Sachen ins EEPROM auslagert?

Verwirrter Anfänger schrieb:
> Grundsätzlich kann ich aber doch davon ausgehen, dass ich der einzige
> bin, der dahin schreibt, oder?
Das ist schon richtig, aber nicht die feine Art! Der Compiler hat schon 
seinen Grund, rumzumäkeln. Mit dem muss man sich nicht unbedingt 
anlegen. Und wenn du hier schon, sagen wir mal, schlampig mit den 
Datentypen umgehst, dann gibt's woanders mit Sicherheit böse 
Überraschungen!

Hab' gerade mal meinen Bastelcomputer hochgefahren.
Und
Timo P. schrieb:
> for(unsigned char i = 0; i<100;i++)
>     eeprom_write_byte((unsigned char*)i,0x22);
geändert zu

1

for(uint16_t i = 0; i<100;i++)

2

 eeprom_write_byte((uint8_t*)i,0x22);

... hätte nicht gedacht, dass der Compiler so eine Schlamperei 
durchgehen lässt.

Ich habe noch schnell mal so ein paar 'Konstruktionen' durchprobiert 
(C++ Builder). Ich hätte gedacht, dass da wenigstens so ein klizekleines 
Warnungchen kommen müsste. Aber richtig, es gibt ja immer mal wieder 
spezielle Bibliotheksfunktionen, da werden nur 'int'-s übergeben und das 
sind dann auch manchmal Adressen.
Aber trotzdem (ich hoffe es war nicht ernst gemeint):
Verwirrter Anfänger schrieb:
> Wenn ich nirgendwo eine Variable mit EEMEM deklariert habe, und
> keine meiner libraries den EEPROM beschreibt, sollte ich mich beliebig
> austoben dürfen.

A. K. schrieb:
> Dann sieht das in der Implementierung ungefähr so aus wie hier.
Mmh, könnte ich mir vorstellen, aber irgendwo sollte schon mal 
deklariert werden, dass vom EPROM was verwendet wird. Also ich meine, 
nicht rumtoben.

Meiner Meinung nach ist das API falsch gewählt:

1

void eeprom_write_byte (uint8_t *addr, uint8_t value);

Was hier addr heißt, ist in Wahrheit kein Zeiger, sondern ein Offset. 
Dieser Sachverhalt sollte sich im API widerspiegeln:

1

void eeprom_write_byte (uint16_t addr, uint8_t value);

wäre daher meiner Meinung nach besser.

willibald schrieb:
> Meiner Meinung nach ist das API falsch gewählt:void eeprom_write_byte (uint8_t
> *addr, uint8_t value);
> Was hier addr heißt, ist in Wahrheit kein Zeiger, sondern ein Offset.

Offset zu was? Es ist die Adresse einer Speicherstelle, also das, was 
eben auch in einem Zeiger steht.

> Dieser Sachverhalt sollte sich im API widerspiegeln:void eeprom_write_byte 
(uint16_t addr, uint8_t value);
> wäre daher meiner Meinung nach besser.

Wenn man dann eine EEMEM-Variable definiert, müßte man deren Adresse 
immer erst in einen Integer konvertieren, um sie an die Funktion zu 
übergeben.

Vlad Tepesch schrieb:
> nein, es ist ein Zeiger in den eeprom-Adressbereich, der auch mit 0
> anfängt.

Zeigertypen sind dann sinnvoll, wenn es etwas gibt, was man damit 
dereferenzieren kann. Das ist hier nicht der Fall, darum wäre es besser, 
den Adress-Offset als Integer anzugeben.

Mir fällt auch keine sinnvolle Anwendung ein, die an dieser Stelle 
tatsächlich einen Pointer braucht. Wisst ihr eine? Alle Szenarien, die 
mir einfallen, führen entweder auf definierte Offsets oder auf 
Pointer-Differenzen (also auch wieder Ganzzahlen).

willibald schrieb:
> Mir fällt auch keine sinnvolle Anwendung ein, die an dieser Stelle
> tatsächlich einen Pointer braucht. Wisst ihr eine?

Siehe http://www.mikrocontroller.net/articles/AVR-GCC-Tutorial#EEPROM

> Alle Szenarien, die mir einfallen, führen entweder auf definierte Offsets oder 
auf
> Pointer-Differenzen (also auch wieder Ganzzahlen).

Nochmals: Differenzen zu was?

OK, dieser EEMEM-Ansatz war mir nicht bekannt. Liegt vermutlich daran, 
dass ich kein AVR-Anwender bin.

Aber ihr habt Recht, das Konzept ist stimmig. Wieder was gelernt.

Karl Heinz Buchegger schrieb:
> Was erwartest du?
> Mit dem Cast sagst du dem Compiler explizit: Halt die Klappe.
Jaa, jaa. ;-)