Komische XC8-Warnung

[XC8 (Gast)]

Hallo,

ich bekomme komische Warnungen von meinem XC8-Compiler:

ATCA_STATUS at_cmd_info(uint8_t *info_dest)
{
    [...]
    for([...])
    {
        info_dest[i] = i2c_receive();
    }
    [...]
}

warning: (1498) pointer (at_cmd_info@info_dest) in expression may have no targets

In dem XC8-Manual steht gar nichts zu einem Fehler/Warnung mit der Nr. 
1498.
Ich denke der Compiler warnt mich davor, dass der Speicher hinter 
`info_dest` zu klein ist. Aber warum? Jemand ne Idee?

Desweiteren gibt es auch Warnungen von Library-Code:

/opt/microchip/xc8/v1.45/sources/common/doprnt.c:538: warning: (373) implicit signed to unsigned conversion
/opt/microchip/xc8/v1.45/sources/common/doprnt.c:541: warning: (373) implicit signed to unsigned conversion
/opt/microchip/xc8/v1.45/sources/common/doprnt.c:757: warning: (373) implicit signed to unsigned conversion
/opt/microchip/xc8/v1.45/sources/common/doprnt.c:1316: warning: (373) implicit signed to unsigned conversion
/opt/microchip/xc8/v1.45/sources/common/doprnt.c:1317: warning: (373) implicit signed to unsigned conversion
/opt/microchip/xc8/v1.45/sources/common/doprnt.c:1500: warning: (373) implicit signed to unsigned conversion
/opt/microchip/xc8/v1.45/sources/common/doprnt.c:1524: warning: (373) implicit signed to unsigned conversion

[Teo D. (teoderix)]

Er warnt, weil er SO keinen Plan hat, ob du für das Array, genügend 
Platz eingeplant hast.

[XC8 (Gast)]

Danke für die Antwort!

Und wie sage ich dem Compiler, dass der Übergebene Speicher groß genug 
ist?

Wäre das folgende erlaubt?

ATCA_STATUS at_cmd_info(uint8_t info_dest[7])

Nicht um ein Array zu erzeugen, sondern um den Compiler mitzuteilen, 
dass der übergebene Puffer mindestens 7 byte umfassen muss.

[Daniel V. (danvet)]

Oder die Länge des Arrays mit übergeben und den Zeiger auf NULL prüfen

ATCA_STATUS at_cmd_info(uint8_t *info_dest, uint8_t length)
{
    if(NULL != info_dest)
    {
      [...]
      for([...])
      {
        if(i < length) {
           info_dest[i] = i2c_receive();
        }
      }
      [...]
    }
}

[Daniel V. (danvet)]

XC8 schrieb:

>
> Wäre das folgende erlaubt?
>

> ATCA_STATUS at_cmd_info(uint8_t info_dest[7])
>

>

Was sagt denn der Compiler zu diesem Konstrukt?

[Yalu X. (yalu) (Moderator)]

Welchen Typ hat der Rückgabewert von i2c_receive?

Vermutlich ist er vorzeichenbehaftet. Da info_dest[i] vom Typ uint8_t
ist, können damit keine negativen Zahlen dargestellt werden, was zur
Warnung führt.

Wenn du sicher bist, dass durch die implizite Typkonvertierung keine
fehlerhaften Ergebnisse entstehen können, kannst du die Konvertierung
explizit machen und dadurch die Warnung beseitigen:

        info_dest[i] = (uint8_t)i2c_receive();

Das alles gilt natürlich nur unter der Voraussetzung, dass i2c_receive()
tatsächlich vorzeichenbehaftet ist. Ist das nicht der Fall, liegt das
Problem woanders. Mit der Größe des Arrays hat das aber nichts zu tun.

[XC8 (Gast)]

Sorry für die späte Antwort.

Yalu X. schrieb:
> Welchen Typ hat der Rückgabewert von i2c_receive?
i2c_receive hat 'uint8_t' als Rückgabewert.


Ich habe noch folgendes gefunden:

And it is basically stating that the pointer passed as argument "uint8_t *buffer" is being dereferenced and since there is no assignment of this pointer on the function it may has no valid address to be dereferenced for. So the compiler believes that before this function is called the pointer was assigned a valid address. Again, I am not worried about this warning.

Ergibt für mich keinen Sinn, da der Compiler den Argumenten beim 
Funktionsaufruf Werte zuweist.

Siehe: http://www.microchip.com/forums/FindPost/958305

Ich habe noch folgendes probiert:

ATCA_STATUS at_cmd_info(uint8_t *info_dest)
{
    if(info_dest == NULL)
        return AT_NULLPOINTER;

    [...]
    for([...])
    {
        info_dest[i] = i2c_receive();
    }
    i2c_stop();
    [...]
}

Ändert aber nichts an der Warnung.

[Teo D. (teoderix)]

Probier mal.

ATCA_STATUS at_cmd_info(uint8_t info_dest[])
{
    if(info_dest == NULL)
        return AT_NULLPOINTER;

    [...]
    for([...])
    {
        info_dest[i] = i2c_receive();
    }
    i2c_stop();
    [...]
}

So ist wenigstens klar, das mit dem Pointer ein Array gemeint ist....

[XC8 (Gast)]

Teo D. schrieb:
> So ist wenigstens klar, das mit dem Pointer ein Array gemeint ist....

Ändert auch nichts :(.

Habe jetzt auch mal die Buffergröße mitgegeben und in der Schleife 
abgebrochen, sollte der Buffer zu klein sein.

Ich schreib mal den Microchip Support an.

[mh (Gast)]

XC8 schrieb:
> ...

ATCA_STATUS at_cmd_info(uint8_t *info_dest)
{
    [...]
    for([...])
    {
        info_dest[i] = i2c_receive();
    }
    [...]
}

> ...

Kannst du ein minimales, vollständiges Beispiel geben, dass den Fehler 
reproduziert? Also ohne unbekannte Macros (ATCA_STATUS), ohne unbekannte 
Funktionen (i2c_receive), ohne die [...] und mit Compiler-Optionen.

Es werden sich hier vermutlich nicht viele Leute finden, die den XC8 
installiert haben und dir trotz der wenigen Infos helfen wollen.

[Toxic (Gast)]

XC8 schrieb:
> Ich schreib mal den Microchip Support an.

Ich wuerde einfach mal googeln:
http://www.microchip.com/forums/m1038697.aspx

und mich bei XC8/PICs-Fragen direkt mit Microchip Forumusern 
unterhalten.

[XC8 (Gast)]

Toxic schrieb:
> Ich wuerde einfach mal googeln:
> http://www.microchip.com/forums/m1038697.aspx
>
> und mich bei XC8/PICs-Fragen direkt mit Microchip Forumusern
> unterhalten.

Ge-googled habe ich, aber nach der konkreten Warnung und nicht 
allgemein. Danke für den Link!

mh schrieb:
> Kannst du ein minimales, vollständiges Beispiel geben, dass den Fehler
> reproduziert?

Gerne.

uint8_t minimal_beispiel(uint8_t *buffer)
{
    *buffer = 0xFF;
    return 0;
}

führt zu

attec508a.c:162: warning: (1498) pointer (minimal_beispiel@buffer) in expression may have no targets
attec508a.c:162: warning: (759) expression generates no code

Ich denke den 'Generates no code' wird man los, wenn der Wert 0xFF nicht 
ge-hardcoded wird. Spielt aber für das Beispiel keine Rolle.

[mh (Gast)]

Da fehlt mindestens nen include, oder du hast Fehlermeldungen/Warnungen 
unterschlagen.

Aber vermutlich hast du ne ganze Menge andere Sachen unterschlagen:
XC8 schrieb:
> attec508a.c:162
bei 5 Zeilen die du zeigst.

Gibt es die Warnung auch, wenn in der Datei nichts anderes steht außer 
den 5 Zeilen + fehlendes inclcude?

[XC8 (Gast)]

mh schrieb:
> Da fehlt mindestens nen include, oder du hast Fehlermeldungen/Warnungen
> unterschlagen.

Jaaa. uint8_t ist halt kein Standarddatentyp, dazu muss stdint.h oder 
inttypes.h inkludiert werden (ich vergesse immer welche der beiden es 
ist).

Alternativ nimm halt einfach nur int. Geht genauso.

int minimal_beispiel(int *buffer)
{
    *buffer = 0xFF;
    return 0;
}

attec508a.c:155: warning: (1498) pointer (minimal_beispiel@buffer) in expression may have no targets
attec508a.c:155: warning: (759) expression generates no code

mh schrieb:
> Aber vermutlich hast du ne ganze Menge andere Sachen unterschlagen:
> XC8 schrieb:
>> attec508a.c:162
> bei 5 Zeilen die du zeigst.
Naja, ist halt ein Minimalbeispiel. Abgesehen davon ist doch erkennbar, 
dass ich die ganze Funktion gepostet habe. Die anderen Funktionen in der 
Datei sind für das Verhalten vollkommen irrelevant.


mh schrieb:
> Gibt es die Warnung auch, wenn in der Datei nichts anderes steht außer
> den 5 Zeilen + fehlendes inclcude?

Ja.

test.c:4: warning: (1498) pointer (minimal_beispiel@buffer) in expression may have no targets
test.c:4: warning: (759) expression generates no code

[Teo D. (teoderix)]

XC8 schrieb:
> test.c:4: warning: (1498) pointer (minimal_beispiel@buffer) in
> expression may have no targets

Wo hin zeigt den da der Pointer?

[Carl D. (jcw2)]

int minimal() {}

ist von extern sichtbar (da nicht static) und kann deshalb von anderen 
Compilation-Units aufgerufen werden. Wie die das machen,weiß der 
Compiler aber nicht, im Gegensatz zu Aufrufenaus der gerade übersetzten 
Compilation Unit. Also sagt er zur Sicherheit "kann schief gehen".

Man kann sich natürlich darüber streiten, ob diese "keine Katze in der 
Nicrowelle trocken"-Meldung wirklich hilft, aber zumindest kann man MC 
deshalb nicht verklagen.
Leider haben "viele Warnungen" Konjunktur gegenüber "wenige Wichtige" 
und es ist hat "echt hilfreich", wenn die eine Nadel-Warnung in dem 
Haufen Warnung-Heu so stark heraus sticht.
Eventuell kann man dieses Feature des XC8 aber auch ausschalten.

[mh (Gast)]

XC8 schrieb:
> ... Die anderen Funktionen in der
> Datei sind für das Verhalten vollkommen irrelevant.
Du verstehst etwas nicht und Fragst in einem Forum nach Hilfe. Glaubst 
du, dass du die richtige Person bist, um zu entscheiden wo oder was das 
Problem ist?

Du solltest dir mal https://stackoverflow.com/help/mcve durchlesen und 
für deine nächste Problembeschreibung zu Herzen nehmen.

XC8 schrieb:
> mh schrieb:
>> Gibt es die Warnung auch, wenn in der Datei nichts anderes steht außer
>> den 5 Zeilen + fehlendes inclcude?
>
> Ja.

Dann fehlen jetzt noch die Compiler-Optionen

[Teo D. (teoderix)]

XC8 schrieb:
> *buffer = 0xFF;

Hat so kein Ziel -> NULL.

Ruf diese Funktion mal korrekt auf oder initialisiere mal den Pointer 
auf eine gültige Adresse.
Dann ist bei mir die Warnung auch weg.

[mh (Gast)]

Teo D. schrieb:
> XC8 schrieb:
>> *buffer = 0xFF;
>
> Hat so kein Ziel -> NULL.
>
> Ruf diese Funktion mal korrekt auf oder initialisiere mal den Pointer
> auf eine gültige Adresse.
> Dann ist bei mir die Warnung auch weg.

Das kann wohl kaum die Lösung sein oder wie soll man das bei 
Bibliotheksfunktionen machen?

[Carl D. (jcw2)]

mh schrieb:
> Teo D. schrieb:
>> XC8 schrieb:
>>> *buffer = 0xFF;
>>
>> Hat so kein Ziel -> NULL.
>>
>> Ruf diese Funktion mal korrekt auf oder initialisiere mal den Pointer
>> auf eine gültige Adresse.
>> Dann ist bei mir die Warnung auch weg.
>
> Das kann wohl kaum die Lösung sein oder wie soll man das bei
> Bibliotheksfunktionen machen?

Wenn der Compiler gut ist, sollte er spätestens wenn eine Prüfung auf 
ungleich NULL drin ist, mit der Warnung aufhören. Denn darum geht's ja 
eigentlich:
"Achtung, du dereferenzierst einen Pointer, von dem ich nicht weiß, ob 
er gültig ist"

[Teo D. (teoderix)]

mh schrieb:
> Das kann wohl kaum die Lösung sein oder wie soll man das bei
> Bibliotheksfunktionen machen?

'extern' dazu klöppeln?
Ist ja NUR ne Warnung, kein Error.

[mh (Gast)]

Carl D. schrieb:
> Wenn der Compiler gut ist, sollte er spätestens wenn eine Prüfung auf
> ungleich NULL drin ist, mit der Warnung aufhören. Denn darum geht's ja
> eigentlich:
> "Achtung, du dereferenzierst einen Pointer, von dem ich nicht weiß, ob
> er gültig ist"

Wenn das tatsächlich der Grund ist und sich nicht ausschlaten lässt, 
gehört der Compiler in den Müll.

Ich alleine entscheide wo und wann ich einen Pointer auf NULL prüfe. Und 
ich ziehe vor dort zu prüfen, wo der Pointer NULL werden kann und nicht 
da, wo ich ihn benutze.

[Teo D. (teoderix)]

mh schrieb:
> Wenn das tatsächlich der Grund ist und sich nicht ausschlaten lässt,
> gehört der Compiler in den Müll.

Teo D. schrieb:
> Ruf diese Funktion mal korrekt auf oder initialisiere mal den Pointer
> auf eine gültige Adresse.
 Dann ist bei mir die Warnung auch weg

[mh (Gast)]

Teo D. schrieb:
> 'extern' dazu klöppeln?
Was soll extern bringen?

Teo D. schrieb:
> Ist ja NUR ne Warnung, kein Error.
Jede unsinnige Warnung, die nicht beseitigt werden kann lenkt von echten 
Warnungen ab, und ist damit nicht zu akzeptieren. Was ist, wenn ich 30 
Funktionen habe, die nen Pointer als Argument haben. Wie soll ich dann 
die eine echte Warnung sehen?

[Teo D. (teoderix)]

Oller Streithammel, such dir nen Andren!

[Carl D. (jcw2)]

mh schrieb:
> Carl D. schrieb:
>> Wenn der Compiler gut ist, sollte er spätestens wenn eine Prüfung auf
>> ungleich NULL drin ist, mit der Warnung aufhören. Denn darum geht's ja
>> eigentlich:
>> "Achtung, du dereferenzierst einen Pointer, von dem ich nicht weiß, ob
>> er gültig ist"
>
> Wenn das tatsächlich der Grund ist und sich nicht ausschlaten lässt,
> gehört der Compiler in den Müll.
;-)

Wenn stimmt, was weiter oben wohl getestet wurde, daß der XC8 die 
Prüfung nicht erkennt, dann könnte das auch ein "haben wir auch" auf die 
diversen Prüfungen, die clang und GCC drauf haben, sein.

> Ich alleine entscheide wo und wann ich einen Pointer auf NULL prüfe. Und
> ich ziehe vor dort zu prüfen, wo der Pointer NULL werden kann und nicht
> da, wo ich ihn benutze.
In einer Library wäre das aber nicht der beste Ansatz.

Vielleicht bist du aber nur zu jung und kannst Dinge, die Compiler für 
dich erledigen (mangels Bedarf) noch nicht so richtig würdigen. Ich 
schreibe zunehmend größere Programme, als ich sie noch komplett 
überblicken könnte. Da ist man über Hilfe froh ;-)

[Toxic (Gast)]

Teo D. schrieb:
> klöppeln

Apropos "klöppeln"
https://www.youtube.com/watch?v=bGbWuk3riKs

[mh (Gast)]

Carl D. schrieb:
> In einer Library wäre das aber nicht der beste Ansatz.
Ich sage nicht, dass es für jeden und alles der beste Ansatz ist. Für 
meine Zwecke halte ich es für den besten Ansatz. Andere gewichten die 
Argumente dafür und dagegen anders und kommen zu einem anderen Ergebnis.

Ich habe mal eine Funktion aus einer sehr bekannten Library 
ausgewählt: memcpy. Ich zitiere aus der Beschreibung aus 
http://en.cppreference.com/w/c/string/byte/memcpy, da ich zu Faul bin 
sie aus dem Standard herauszusuchen:

The behavior is undefined if either dest or src is a null pointer.

Und tatsächlich weder glibc noch newlib prüfen in memcpy, ob einer der 
Pointer NULL ist.

Es gibt also noch andere Personen, die der Meinung sind, dass es ein 
geeigneter Ansatz ist.

[Carl D. (jcw2)]

mh schrieb:
> Carl D. schrieb:
>> In einer Library wäre das aber nicht der beste Ansatz.
> Ich sage nicht, dass es für jeden und alles der beste Ansatz ist. Für
> meine Zwecke halte ich es für den besten Ansatz. Andere gewichten die
> Argumente dafür und dagegen anders und kommen zu einem anderen Ergebnis.
>
> Ich habe mal eine Funktion aus einer sehr bekannten Library
> ausgewählt: memcpy. Ich zitiere aus der Beschreibung aus
> http://en.cppreference.com/w/c/string/byte/memcpy, da ich zu Faul bin
> sie aus dem Standard herauszusuchen:
>

> The behavior is undefined if either dest or src is a null pointer.
>

>
> Und tatsächlich weder glibc noch newlib prüfen in memcpy, ob einer der
> Pointer NULL ist.
>
> Es gibt also noch andere Personen, die der Meinung sind, dass es ein
> geeigneter Ansatz ist.

Vermutlich ist obiger Text schon ein paar Jährchen alt.
Und es ist ja nicht so, daß man Warnungen nicht ignorieren könnte, wenn 
man weiß, was man tut, nur manchmal bemerkt man solche Sachen einfach 
nicht und es ist immer besser das zur Compile-Zeit zu erfahren.
Und wie hatte mal einer in einem Vortrag (über C++) zu Compiletime 
Exceptions in constexpr gesagt: die werden nicht ausgeliefert.

[mh (Gast)]

Carl D. schrieb:
> Und es ist ja nicht so, daß man Warnungen nicht ignorieren könnte, wenn
> man weiß, was man tut, nur manchmal bemerkt man solche Sachen einfach
> nicht und es ist immer besser das zur Compile-Zeit zu erfahren.

Nur was macht man, wenn man dutzende dieser Warnungen hat, und die 
echten Warnungen nicht mehr sofort sieht?
Ich hab nicht ohne Grund mehrfach nach den Compiler-Optionen gefragt.

[Carl D. (jcw2)]

mh schrieb:
> Carl D. schrieb:
>> Und es ist ja nicht so, daß man Warnungen nicht ignorieren könnte, wenn
>> man weiß, was man tut, nur manchmal bemerkt man solche Sachen einfach
>> nicht und es ist immer besser das zur Compile-Zeit zu erfahren.
>
> Nur was macht man, wenn man dutzende dieser Warnungen hat, und die
> echten Warnungen nicht mehr sofort sieht?
> Ich hab nicht ohne Grund mehrfach nach den Compiler-Optionen gefragt.

Ich hab ja nicht gesagt, daß mir dieser Compiler gut gefällt. Er warnt 
vor etwas, dessen Beseitigung er nicht erkennt. Man kann die Warnungen 
anscheinend nicht ausschalten, ...
Manchmal entscheidet man sich eben auch für (oder gegen) eine 
Architektur, weil sie von brauchbaren (nicht) Compilern unterstützt 
wird.
Und so wurde ich dann mit PIC nie warm. Ein Privileg, das ich mir bei 
den kleinen Bastelrechnern daheim leisten kann, auf den dicken Hobeln 
auf der Arbeit nicht.

[XC8 (Gast)]

Teo D. schrieb:
> Teo D. schrieb:
>> Ruf diese Funktion mal korrekt auf oder initialisiere mal den Pointer
>> auf eine gültige Adresse.
>  Dann ist bei mir die Warnung auch weg

Wir reden aneinander vorbei.
Zeig mal bitte deinen Code.

Carl D. schrieb:
> ist von extern sichtbar (da nicht static) und kann deshalb von anderen
> Compilation-Units aufgerufen werden. Wie die das machen,weiß der
> Compiler aber nicht, im Gegensatz zu Aufrufenaus der gerade übersetzten
> Compilation Unit. Also sagt er zur Sicherheit "kann schief gehen".

Wie kann man eine Funktion denn falsch aufrufen? Wenn ich ein Argument 
weglasse, schlägt die Kompilierung fehl. Zudem weiß der Compiler durch 
die Prototypen (aus den Headern) wie die Funktion aufgerufen werden soll 
(und das in jeder Compilation Unit).

[Teo D. (teoderix)]

XC8 schrieb:
> Alternativ nimm halt einfach nur int. Geht genauso.
> int minimal_beispiel(int *buffer)
> {
>     *buffer = 0xFF;
>     return 0;
> }

minimal_beispiel(0x100);

oder

> int minimal_beispiel(int *buffer)
> {
      buffer = 0x100;
>     *buffer = 0xFF;
>     return 0;
> }

Get doch NUR um:

Teo D. schrieb:
> XC8 schrieb:
>> test.c:4: warning: (1498) pointer (minimal_beispiel@buffer) in
>> expression may have no targets
?

[XC8 (Gast)]

Danke!
Teo D. schrieb:
>> Alternativ nimm halt einfach nur int. Geht genauso.
>> int minimal_beispiel(int *buffer)
>> {
>>     *buffer = 0xFF;
>>     return 0;
>> }
>> minimal_beispiel(0x100);

Ok, so klappt es bei mir auch.
Die Funktionen wurde bei mir noch gar nicht aufgerufen, dass hat der 
Compiler wohl als Anlass genommen sich zu beschweren?!?
(Über die 'Function never called'-Warnung hinaus natürlich).

[Teo D. (teoderix)]

XC8 schrieb:
> Compiler wohl als Anlass genommen sich zu beschweren?!?

Das is aber ne andere Warnung, die bleibt auch beim 2. Beispiel 
erhalten.

XC8 schrieb:
> attec508a.c:162: warning: (759) expression generates no code

Irgend was mit 'Wird nie aufgerufen/verwendet' könnte auch noch 
auftauchen.
(mom nur aus der Erinnerung, läuft hier grad nicht)

[mh (Gast)]

Teo D. schrieb:
> XC8 schrieb:
>> Alternativ nimm halt einfach nur int. Geht genauso.
>> int minimal_beispiel(int *buffer)
>> {
>>     *buffer = 0xFF;
>>     return 0;
>> }
>
> minimal_beispiel(0x100);

Teo D. schrieb:
>> int minimal_beispiel(int *buffer)
>> {
>       buffer = 0x100;
>>     *buffer = 0xFF;
>>     return 0;
>> }

Autsch! Ich hoffe der Compiler gibt bei den Beispielen echte Warnungen. 
Sowas wie "assignment makes pointer from integer without a cast". Mal 
davon abgesehen, dass das vermutlich undefined behaviour ist.

[Teo D. (teoderix)]

mh schrieb:
> Autsch! Ich hoffe der Compiler gibt bei den Beispielen echte Warnungen.

Aber sowas von... :)

Darum gings aber nicht!
Du hast schon kariert das dies ein Beispiel ist, kein Programm!

Oller Krawallheini..... :P

[Carl D. (jcw2)]

XC8 schrieb:
> Carl D. schrieb:
>> ist von extern sichtbar (da nicht static) und kann deshalb von anderen
>> Compilation-Units aufgerufen werden. Wie die das machen,weiß der
>> Compiler aber nicht, im Gegensatz zu Aufrufenaus der gerade übersetzten
>> Compilation Unit. Also sagt er zur Sicherheit "kann schief gehen".
>
> Wie kann man eine Funktion denn falsch aufrufen? Wenn ich ein Argument
> weglasse, schlägt die Kompilierung fehl. Zudem weiß der Compiler durch
> die Prototypen (aus den Headern) wie die Funktion aufgerufen werden soll
> (und das in jeder Compilation Unit).

z.B.

minimal_beispiel(NULL);

Passiert das in einer anderen Compilation-Unit, dann weiß der Compiler 
davon nichts und genau das sagt er.
Wie schon einmal geschrieben scheint er aber nicht schlau genug zu sein, 
eine Prüfung auf !=NULL zu verstehen, deswegen ist das für mich nicht 
einer der Besten seiner Art.