Komische XC8-Warnung

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

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

1

ATCA_STATUS at_cmd_info(uint8_t *info_dest, uint8_t length)

2

{

3

    if(NULL != info_dest)

4

    {

5

      [...]

6

      for([...])

7

      {

8

        if(i < length) {

9

           info_dest[i] = i2c_receive();

10

        }

11

      }

12

      [...]

13

    }

14

}

XC8 schrieb:

>
> Wäre das folgende erlaubt?
>

1

> ATCA_STATUS at_cmd_info(uint8_t info_dest[7])

2

>

>

Was sagt denn der Compiler zu diesem Konstrukt?

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:

1

        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.

Probier mal.

1

ATCA_STATUS at_cmd_info(uint8_t info_dest[])

2

{

3

    if(info_dest == NULL)

4

        return AT_NULLPOINTER;

5

6

    [...]

7

    for([...])

8

    {

9

        info_dest[i] = i2c_receive();

10

    }

11

    i2c_stop();

12

    [...]

13

}

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

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

Wo hin zeigt den da der Pointer?

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.

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

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

Oller Streithammel, such dir nen Andren!

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 ;-)

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

1

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

2

>

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

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.

1

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.