mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Komische XC8-Warnung


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: XC8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Teo D. (teoderix)
Datum:

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

Autor: XC8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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();
        }
      }
      [...]
    }
}

Autor: Daniel V. (danvet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Yalu X. (yalu) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch Moderator
Autor: XC8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: XC8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Toxic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: XC8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: XC8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Teo D. (teoderix)
Datum:

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

Wo hin zeigt den da der Pointer?

Autor: Carl D. (jcw2)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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"

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

: Bearbeitet durch User
Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oller Streithammel, such dir nen Andren!

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

: Bearbeitet durch User
Autor: Toxic (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

: Bearbeitet durch User
Autor: XC8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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
?

Autor: XC8 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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).

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: mh (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Teo D. (teoderix)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Carl D. (jcw2)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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