mikrocontroller.net

Forum: PC-Programmierung C - warning: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conv


Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hey, ich experimentiere gerade ein wenig mit Functions, Pointern und 
Void-Pointern.

Das unten aufgeführte Script läuft und gibt das richtige Ergebnis, 
jedoch bekomme ich auf die Zeile
b=*(int*)a;
 folgende Warnung: "warning: incompatible integer to pointer conversion 
assigning to 'void *' from 'int'"

Ich versuche verzweifelt den Hintergrund zu verstehen, komme aber leider 
nicht dahinter :/

#include <stdio.h>

void test (int *a);
void test2 (int d);
void *stage (const void*);
void *stage2 (const void*);

int main() {

    int f=0;

    //test(&e);
    //test2(e);

    if (f==0) {
        stage(&f);
        printf("\n%d",f);
    }

    if (f==1) {
        stage(&f);
        printf("\n%d",f);
    }

    if (f==2) {
        f=*(long*)stage2(&f);
        printf("\n%d",f);
    }

    if (f==3) {
        f=*(long*)stage2(&f);
        printf("\n%d",f);
    }
    return 0;
}

void test(int *a) { 
    int b=3;
    int c=2;
    *a=b+c; 
}

void test2(int d) {
    d++;
    //printf("%d",d);
}

void *stage (const void*num) {
    long nr;
    nr=(*(int*)num)++;
    return (void*)nr;
}

void *stage2(const void*a) {
    static void *b;
    b=*(int*)a;

    if (b==(int*)2)
        b+=1;
    else if (b==(int*)3)
        b+=6;

    return &b;
}

Autor: Walter K. (vril1959)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was ist an „ " incompatible integer to pointer conversion assigning to 
'void *' from 'int'" unverständlich?

Beitrag #5746535 wurde von einem Moderator gelöscht.
Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rechts vom = steht ein int (der gesamte Ausdruck)

Ein Pointer ist keine Ganzzahl. Auch wenn es manchmal so aussieht.
Verlasse dich bei diesen Experimenten auf Nichts.
Sie haben auch keine nachvollziehbare Aussage.

Es kann mit einem anderen Compiler/Version/Optimierungsstufe/System 
anders aussehen

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
In C schreibt man keine Scripte sondern Programme. C ist schließlich 
keine Scriptsprache. Dein Programm enthält mehrere Fehler und 
funktioniert daher nicht; es hat nur zufällig den Anschein zu 
funktionieren. Durch Änderung der Umgebung (Compiler-Version, -Optionen, 
Betriebssystem, Prozessor) kann das schon ganz anders aussehen.

Dennis schrieb:
> return (void*)nr;

Irgendeinen long-Wert nach void* casten ist fehlerhaft. Es können Daten 
verloren gehen (der long ist ggf. nicht wiederherstellbar) und beim 
Dereferenzieren des Pointers kann beliebiger Unfug passieren. Es 
"funktioniert" nur weil du den Rückgabewert nirgends verwendest.

Dennis schrieb:
> if (b==(int*)2)

Was soll das sein? Einen Integer vom Wert "2" in einen Pointer-Typ zu 
casten ergibt Unsinn. Der Compiler warnt zu recht.

Dennis schrieb:
> return &b;

Hier fehlt ein cast. &b ist vom Typ void**.

Dennis schrieb:
> f=*(long*)stage2(&f);

Hier dereferenzierst du einen Pointer vom Typ "long*" welcher aber auf 
ein *b zeigt und schneidest dann noch ggf. Bits ab (cast nach int). Es 
wird also der ggf. gekürzte Wert in "b" ausgegeben, d.h. die Adresse von 
f.
Würde einer der if-Blöcke ausgeführt, wäre diese Adresse inkrementiert 
und damit ungültig.

So ein Code ist natürlich nicht nur fehlerhaft, sondern auch unlesbar 
und unwartbar. Auf die Nutzung von void*, das Casten zwischen 
verschiedenen Pointer-Typen und insbesondere das Casten zwischen 
Pointern und Integern sollte man so weit wie irgend möglich vermeiden 
(das geht in C++ übrigens besser als in C dank templates). Falls man 
doch zwischen Pointer und Integer casten muss, sollte man das nur mit 
dem Integer-Typ "uintptr_t" machen, auf keinen Fall mit "long" oder 
"int". Auf AMD64 z.B. ist ein Zeiger 64bit-lang, "long" und "int" aber 
meist (je nach Compiler) nur 32bit. Somit gehen 32bits verloren. 
Umgekehrt ist auf x86 ein Pointer nur 32bit groß, ein "long" könnte je 
nach Compiler 64bit sein wodurch wieder Daten verloren gehen wenn man 
den "long" auf den Zeiger umwandelt. uintptr_t ist immer richtig groß. 
Irgendwelche Zahlen (2, 3) nach Pointer casten ist zwar möglich, aber 
hässlich - diesen Zeiger darf man nicht dereferenzieren, sondern nur 
wieder zurück auf den Integer casten.

Stelle deinen Compiler auf einen strikten Sprachstandard (ohne 
Erweiterungen) und aktiviere alle Warnungen. So lernt man am Besten. 
Beim GCC geht das z.B. mit den Optionen "-std=c11 -Wall -Wextra 
-Wconversion -pedantic -Werror". Code der damit anstandslos übersetzt 
wird hat eine deutlich höhere Wahrscheinlichkeit, dass er korrekt ist.

Autor: Rufus Τ. F. (rufus) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sehen wir uns doch die nähere Umgebung mal an:
void *stage2(const void*a) {
    static void *b;
    b=*(int*)a;

Hier wird der void-Pointer a also zu einem int-Pointer gecastet:
    (int *) a

dieser int-Pointer dann dereferenziert
   * ((int *) a)

und das Ergebis --ein int-- einem void-Pointer zugewiesen:
   b = * ((int *) a)

(Die zusätzlichen Klammern dienen dem Verständnis, worauf sich der 
jeweilige Operator bezieht)


Und damit sollte die Warnung des Compilers verständlich sein:

"Zuweisung eines ints zu einem Pointer"

Man könnte jetzt noch einen zusätzlichen Typecast einführen
   b = (void *) (* ((int *) a))

dann wäre die Warnung weg.

Autor: c-hater (Gast)
Datum:

Bewertung
-4 lesenswert
nicht lesenswert
Rufus Τ. F. schrieb:

> Man könnte jetzt noch einen zusätzlichen Typecast einführen
>
>
>    b = (void *) (* ((int *) a))
> 
>
> dann wäre die Warnung weg.

Und der ganze syntaktische Aufwand nur, um eine aus Sicht der Maschine 
völlig legale Operation auch für den Compiler zu legalisieren...

Wenn man das dann noch unter besonderer Berücksichtigung des 
Sachverhalts betrachtet, dass bei Maschinen, wo diese Operation nicht 
legal ist, das Geschwalle zwar den Compiler ruhig stellt, aber letztlich 
trotzdem nix funktionieren wird, sollten dann doch erste Zweifel am 
Nutzen dieses ganzen Geschwalles aufkommen...

Aber natürlich: wenn C die Bibel ist, dann ist es von Gott gegeben, dass 
C alles löst und überhaupt...

42

Autor: A. K. (prx)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wieder auf Streit aus?

Autor: leo (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Aber natürlich: wenn C die Bibel ist, dann ist es von Gott gegeben, dass
> C alles löst und überhaupt...

Du schliesst von extrem schlechten, unleserlichen und sinnfreien Code 
zum Experimentieren auf die Sprache um deinen Mist abzuladen.

leo

Autor: Dennis (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vielen Dank für die raschen und ausführlichen Antworten.

Das hilft mir schon etwas beim Verständnis :)

Autor: Besser gar keinen Cast benutzen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wir sollten den Anfängern besser den Rat geben: Datenstrukturen so 
anlegen, das keine Casts erforderlich sind. Casts nur in einigen 
Sonderfällen wie malloc() oder memcpy() nutzen. Vor allem, niemals von 
Const-Pointer auf Nicht-Const casten. Das gibt immer undurchschaubare 
Probleme.

Autor: Nop (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:

> Irgendwelche Zahlen (2, 3) nach Pointer casten ist zwar möglich, aber
> hässlich - diesen Zeiger darf man nicht dereferenzieren, sondern nur
> wieder zurück auf den Integer casten.

Für memory mapped Register, IO und bestimmte Speicherbereiche ist das 
doch völlig normal. Daß man das in defines kapselt, ist ja bloß 
Textersetzung.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Besser gar keinen Cast benutzen schrieb:
> Casts nur in einigen Sonderfällen wie malloc() oder memcpy() nutzen.

In C sind da keine Cast nötig.
In C++ verwendet man sie (zumindest malloc) nicht.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
A. K. schrieb:
> Wieder auf Streit aus?

Dirk B. schrieb:
> Besser gar keinen Cast benutzen schrieb:
>> Casts nur in einigen Sonderfällen wie malloc() oder memcpy() nutzen.
>
> In C sind da keine Cast nötig.
> In C++ verwendet man sie (zumindest malloc) nicht.

Und bei memcpy ist auch in C++ kein Cast nötig.

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk B. schrieb:
> Besser gar keinen Cast benutzen schrieb:
>> Casts nur in einigen Sonderfällen wie malloc() oder memcpy() nutzen.
>
> In C sind da keine Cast nötig.
> In C++ verwendet man sie (zumindest malloc) nicht.

Bitte was?

malloc() liefert doch einen Zeiger vom Typ void* zurück. Seit wann kann 
man sowas verwenden ohne zu casten?

: Bearbeitet durch User
Autor: Dr. Sommer (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mark B. schrieb:
> malloc() liefer doch einen Zeiger vom Typ void* zurück. Seit wann kann
> man sowas verwenden ohne zu casten?

C erlaubt die implizite Konvertierung von void* auf andere Zeiger-Typen, 
damit die armen C-Programmierer nicht ständig casten müssen (ala "int* f 
= (int*) malloc (sizeof(int));"). In C++ schreibt man halt einfach "new 
int".

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> C erlaubt die implizite Konvertierung von void* auf andere Zeiger-Typen,
> damit die armen C-Programmierer nicht ständig casten müssen (ala "int* f
> = (int*) malloc (sizeof(int));"). In C++ schreibt man halt einfach "new
> int".

Oh, okay. Ich habe bei malloc() immer gecastet... hat immer funktioniert 
;-)

Autor: Dr. Sommer (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark B. schrieb:
> Oh, okay. Ich habe bei malloc() immer gecastet... hat immer funktioniert
> ;-)

Ist auch sinnvoll, damit der Code auch unter C++ funktioniert.

Autor: Dirk B. (dirkb2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dr. Sommer schrieb:
> Mark B. schrieb:
>> Oh, okay. Ich habe bei malloc() immer gecastet... hat immer funktioniert
>> ;-)
>
> Ist auch sinnvoll, damit der Code auch unter C++ funktioniert.

C Programme sollte man mit einem C-Compiler übersetzen.

Den bieten die allermeisten C++-Compiler auch an.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Dirk B. schrieb:
> Dr. Sommer schrieb:
>> Mark B. schrieb:
>>> Oh, okay. Ich habe bei malloc() immer gecastet... hat immer funktioniert
>>> ;-)
>>
>> Ist auch sinnvoll, damit der Code auch unter C++ funktioniert.
>
> C Programme sollte man mit einem C-Compiler übersetzen.
>
> Den bieten die allermeisten C++-Compiler auch an.

Vielleicht hat man aber ein Stück C-Code, das man in eine C++-Source 
einfügen will. Das hat Dr.Sommer wohl sagen wollen.

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
Mark B. schrieb:
> Dr. Sommer schrieb:
>> C erlaubt die implizite Konvertierung von void* auf andere Zeiger-Typen,
>> damit die armen C-Programmierer nicht ständig casten müssen (ala "int* f
>> = (int*) malloc (sizeof(int));"). In C++ schreibt man halt einfach "new
>> int".
>
> Oh, okay. Ich habe bei malloc() immer gecastet... hat immer funktioniert
> ;-)

Das sollte man in C aber besser nicht tun.

Carl D. schrieb:
>> C Programme sollte man mit einem C-Compiler übersetzen.
>>
>> Den bieten die allermeisten C++-Compiler auch an.
>
> Vielleicht hat man aber ein Stück C-Code, das man in eine C++-Source
> einfügen will. Das hat Dr.Sommer wohl sagen wollen.

Davon würde ich abraten. Wenn man das braucht, steckt man den C-Code in 
eine C-Datei. Die Funktionen lassen sich problemlos auch von C++-Code 
aus aufrufen. Es gibt doch ein paar subtile Unterschiede, durch die ich 
nicht einfach blind darauf vertrauen würde, dass C-Code als C++ noch 
genau gleich funktioniert.

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Mark B. schrieb:
>> Oh, okay. Ich habe bei malloc() immer gecastet... hat immer funktioniert
>> ;-)
>
> Das sollte man in C aber besser nicht tun.

Warum nicht?

Autor: Rolf M. (rmagnus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mark B. schrieb:
>> Das sollte man in C aber besser nicht tun.
>
> Warum nicht?

Falls du mal das dazugehörige #include <stdlib.h> vergisst, fehlt eine 
Deklaration für malloc. Standard-Verhalten von C ist dann, int als 
Return-Typ anzunhemen. Das geht spätestens dann schief, wenn du auf 
einem System bist, wo int und Zeiger nicht zufällig die gleiche Größe 
haben.
Ohne Cast kommt dann die Meldung, dass du versuchst, einen int in einen 
Zeiger umzuwandeln. Mit Cast sagst du dem Compiler, dass du das so 
willst und unterdrückst damit die Meldung.

Autor: Mark B. (markbrandis)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Rolf M. schrieb:
> Falls du mal das dazugehörige #include <stdlib.h> vergisst, fehlt eine
> Deklaration für malloc. Standard-Verhalten von C ist dann, int als
> Return-Typ anzunhemen. Das geht spätestens dann schief, wenn du auf
> einem System bist, wo int und Zeiger nicht zufällig die gleiche Größe
> haben.
> Ohne Cast kommt dann die Meldung, dass du versuchst, einen int in einen
> Zeiger umzuwandeln. Mit Cast sagst du dem Compiler, dass du das so
> willst und unterdrückst damit die Meldung.

Na ja, den Fall halte ich nun nicht gerade für sehr wahrscheinlich.

Edit: Außerdem erhalte ich mit -Wall sowieso eine Warnung:
warning: implicit declaration of function 'malloc' [-Wimplicit-function-declaration]

: Bearbeitet durch User
Autor: Rolf M. (rmagnus)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
Ja, die Compiler geben da heute deutlich bessere Warnungen aus als 
früher, daher mag das nicht mehr so von Bedeutung sein.
Ich würde einen nicht nötigen Cast aber abgesehen davon sowieso lieber 
weglassen.

Autor: vn nn (Gast)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
c-hater schrieb:
> Und der ganze syntaktische Aufwand nur, um eine aus Sicht der Maschine
> völlig legale Operation auch für den Compiler zu legalisieren...

Nö der ganze syntaktische Aufwand ist eigentlich völlig unnötig, aber 
der TS will halt herumspielen.
Aber du hast halt keine Ahnung von C, deswegen glaubst du dass das nötig 
wäre.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.