existierenden pointer auf NULL setzen

[Chandler B. (chandler)]

Guten morgen,
ich soll unittests schreiben, habe aber bei einer bedingung ein Problem.
Folgende funktion:

void handleReceive(void)
{
  uint8_t *header;
  header = NULL;

  removeReceive(cid_b, &(header), &(length), &is_valid);  // hier wird header gesetzt
  if(NULL != header)
  {
    data = header;
    MessageReceive(data, length); // Diese Funktion ist gemockt

    if(NULL != data )
    {
      // mache etwas
    }
    else
    {
      // mache etwas anderes
    }
  }
}

Mein Problem ist die bedingung
if(NULL != data)
hier bekomme ich es nicht hin, dass data=NULL ist, da es ja quasi vorher 
schon abgefragt worden ist (NULL != header und data = header).
Jetzt habe ich versucht data in der Funktion MessageReceive zu löschen

void mockMessageReceive(uint8 *buffer, uint16 lenght)
{
//  buffer= NULL;

//  delete buffer;

//  uint8 *pointer;
//  pointer = NULL;
//  buffer = pointer;

  free(buffer);

  printf("buffer: %p\r\n", &buffer);
}

Allerdings bekomme ihc es nicht hin buffer zu löschen, bzw. buffer auf 
NULL zu setzen.

[Mike R. (thesealion)]

Das geht auch so nicht. (Außer data wäre eine globale Variable und das 
ist hoffentlich nicht der Fall)

Ansonsten mach dir die Übergabe Typen (Call-by-Value und 
Call-by-Reference) klar.
Dann siehst du, dass die Abfrage

if(NULL != data )

in deinem Code nie falsch sein kann.

[Hannes J. (Firma: _⌨_) (pnuebergang)]

Wie sieht die Signatur des Originals MessageReceive() aus?

Wenn das die gleiche ist wie bei mockMessageReceive(), dann kann die 
Funktion/Methode buffer bzw. data nicht geändert zurückgeben. Damit ist 
Test if(NULL != data ) überflüssig.

[BeBe (Gast)]

Wo ist data definiert? Globale Variable?

So wie das programmiert ist, könnte die Verzweigung Toter Code sein 
(wenn die globale Variable nicht durch andere Codeteile verändert werden 
kann).

Für toten Code kann man keine Tests durchlaufen lassen. Das geht nur per 
Analyse.

[A. S. (Gast)]

Das ist ein Dilemma. Machst Du die Frage weg, wird das bei der nächsten 
Änderung durchgehen.

Also brauchst Du statt if ein Konstrukt, dass als Zusicherung aktiv 
bleibt aber nicht als zu durchlaufender Zweig zählt.

Eine Art assert, dass eine Warnung verursacht, wenn es auftreten kann.

Den Code zu durchlöchern ist hingegen kontraproduktiv.

[Oliver S. (oliverso)]

Hannes J. schrieb:
> Damit ist
> Test if(NULL != data ) überflüssig.

Und daher ist es auch irgendwie sinnfrei, darauf zu zu unit-testen.

Chandler B. schrieb:
> free(buffer);

Da sitzt das Problem. data kann zwar nicht NULL werden, aber auf einen 
nicht mehr gültigen Datenblock zeigen.

Oliver

[A. S. (Gast)]

Chandler B. schrieb:
> MessageReceive(data, length); // Diese Funktion ist gemockt

na, dann mock halt per #define und setze data auf 0.

aber wie gesagt, befasse Dich lieber mit statischer Code-Analyse statt 
"100% getestet, also alles OK".

[MaWin (Gast)]

Dass ein Codepfad tot ist und damit sinnlos und nicht testbar, ist das 
Ergebnis deines Tests.
Dieser Pfad kann also in der nächsten Version des Codes entfernt werden.

[A. S. (Gast)]

MaWin schrieb:
> Dieser Pfad kann also in der nächsten Version des Codes entfernt werden.

Wie stelle ich sicher, dass dieser Zweig auch "tot" bleibt?

Also wie ist das Konstrukt einer Sicherheitsabfrage, die nie zuschlagen 
soll?

[doppelt hält besser (Gast)]

Man kann doch einen Zeiger in der Funktion auf Null setzten, wenn man 
mit einem Doppelzeiger arbeitet.

Dann ist er auch außerhalb der Funktion NULL.

void
my_free (void** pp)
{
   free (*pp);
   *pp = NULL;
}

int
main (void)
{
   char* str = malloc (sizeof (*str) * 128);
   strcpy (str, "hi, there");

   puts (str);
   my_free ((void**)&str);

   // geht, da NULL
   free (str);
   free (str);
   free (str);

   return EXIT_SUCCESS;
}

[Oliver S. (oliverso)]

doppelt hält besser schrieb:
> Man kann doch

Man kann sicherlich alles mögliche, aber im Code oben steht halt die 
Funktion

Chandler B. schrieb:
> MessageReceive(data, length); // Diese Funktion ist gemockt

und die kann data nicht verändert.

Die einzige Möglichkeit, data auf NULL zu bekommen, wäre über einen 
amoklaufenden Parallel-Thread, der den Datenbereich überschreibt. Ob man 
daraf testen will oder gar muß, muß der TO selber wissen.

Oliver

[doppelt hält besser (Gast)]

Chandler B. schrieb:
> uint8_t *header;
>   header = NULL;
>   removeReceive(cid_b, &(header), &(length), &is_valid);  // hier wird
> header gesetzt

Da wird ja der Doppelzeiger benutzt.

Man muss halt auch bei der zweiten Funktion genauso arbeiten.

die Frage ist ja sowieso woher diese Variable "data" kommt. Vielleicht 
ist die Variable ja sogar global.

[doppelt hält besser (Gast)]

Chandler B. schrieb:
> unittests

suggeriert ja auch dass der Code nicht untouchable ist.  Also die erste 
Stelle zum Verbessern gefunden.

[MaWin (Gast)]

A. S. schrieb:
> Wie stelle ich sicher, dass dieser Zweig auch "tot" bleibt?

assert()

Wenn der echte Code allerdings nicht deutlich komplexer ist, als der 
gezeigte Code, sehe ich keinen Sinn in dieser Abfrage.
Sogar ganz im Gegenteil. Die zusätzliche Abfrage verkompliziert den 
Code. Die Lesbarkeit wird verschlechtert und somit wird die 
Fehleranfälligheit erhöht.

Ich würde den Pfad also ersatzlos streichen oder höchstens durch ein 
assert() ersetzen.