Speicherzugriffsfehler nachdem Programm durchgelaufen ist

"ignoring return value of 'realloc', declared with attribute warn_unused_result"

Da meckert der Compiler, und das ist auch gut so. realloc() könnte auch schiefgehen, und in dem Fall fliegt deinem Dozenten das Ding um die Ohren.

Die Warnungen kann man bei üblichen Compilern abschalten, rein sprachlich könnte man sie auch durch einen void-Cast übergehen. Bringt aber nix, weil man halt schon prüfen sollte, ob realloc() durchgegangen ist.

der erste fehler scheint zu sein, dass realloc garnix zurückgibt wenn der übegebene pointer den wert NULL hat.

Stimmt nicht, realloc() gibt was zurück, wenn der Zeiger NULL war, nämlich das gleiche, was malloc() zurückgeben würde.

irgendein tipp ?

Immer die Rückgaben von Funktionen prüfen, in denen ein "alloc" vorkommt. Den Dozenten wüst beschimpfen, wenn er das nicht einsehen will.

okay verstehe ich, wie ich es mache keine ahnung

Einfach für jeden Zeiger, den malloc/realloc/calloc dir gegeben haben, irgendwann free() aufrufen.

supertux

lalas schrieb:

hmmm...okay verstehe ich, wie ich es mache keine ahnung

ich muss auch in einer zweiten funktion mit "realloc" arbeiten und da bekomme ich ne compiler-warnung "ignoring return value of 'realloc', declared with attribute warn_unused_result"

vielleicht hat das was damit zu tun ?

nicht vielleicht, du *musst*! Was ist wenn ralloc fehlschlägt und NULL zurückliefert? Dann überschreibst du Speicher, der dir möglicherweise gar nicht gehört.

lalas schrieb:

int StrLstEingabeKompakt (char* acListe[], int nAnzahl)
{
  void* vMem = NULL;
  char szPuffer[200];
  int s, nByteNeu, nByteSum;

  for (s=0; s<nAnzahl; s++)
  {
    fgets (szPuffer, 200, stdin);
    if (strcmp (szPuffer, "#\n")==0) break;
    nByteNeu=strlen(szPuffer)+1;
    
    realloc (vMem, nByteSum+nByteNeu);
    memcpy (vMem+nByteSum, szPuffer, nByteNeu);
    nByteSum+=nByteNeu;
    strcpy(acListe[s], szPuffer);
  }
  return s;
}

die funktion ist ziemlich verbuggt. was mir auf den ersten blick auffällt:
- vMem ist ein void*, d.h. die addition vMem+nByteSum wird kein compiler fressen wollen.
- nByteSum wird nicht mit 0 initialisiert, hat also unvorhersehbaren inhalt
dozenten machen sowas gern (code aus dem kopf ganz schnell auf die tafel kritzeln) damit ihr euch damit auseinandersetzt wenn's kracht. ihr sollt ja aus fehlern lernen und selbständig wissen erarbeiten, nicht alles vorgekaut bekommen.

- vMem ist ein void*, d.h. die addition vMem+nByteSum wird kein compiler fressen wollen.

Darüber bin ich auch schon gestolpert. warn_unused_result deutet akut auf den gcc hin, und der kann void-Arithmetik als Erweiterung (die aber in vielen Pakteten default-mäßig aufgedreht ist). Führt dazu, dass die Addition anstandslos durchgeht.

gnu-flamer schrieb:

- vMem ist ein void*, d.h. die addition vMem+nByteSum wird kein compiler fressen wollen.

Darüber bin ich auch schon gestolpert. warn_unused_result deutet akut auf den gcc hin, und der kann void-Arithmetik als Erweiterung (die aber in vielen Pakteten default-mäßig aufgedreht ist). Führt dazu, dass die Addition anstandslos durchgeht.

wie bitte??? nimmt er das als 'char*' an?

lalas

das void* vMem meinte unser dozent müsse so sein, weil realloc ein void* übergeben habe möchte als ersten parameter.
wie ich dazu einen int addieren kann ist mir auch schleierhaft, aber laut dozent sollen wir das so schreiben.

ich würde das ganze ja gerne umschreiben, nur ist mir nicht so ganz klar wie ich das anders stricken kann.

der erste teil entspricht ja der "normalen" eingabefunktion.

danach soll einfach der speicherbereich des eingegeben string berechnet werden und danach der speicherbereich des zweiten strings dazu addiert werden.

so soll bewirkt werden das die strings alle in einem aufeinander folgenden speicherbereich gespeichert werden.

nByteNeu=strlen(szPuffer)+1 müsste doch den speicherbedarf als int in nByteNeu schreiben, oder ?

Swordfish

lalas schrieb:

das void* vMem meinte unser dozent müsse so sein, weil realloc ein void* übergeben habe möchte als ersten parameter.
wie ich dazu einen int addieren kann ist mir auch schleierhaft, aber laut dozent sollen wir das so schreiben.

Wenn ich diesen "Dozenten" erwisch...

In C kann jeder Pointertyp implizit nach void* umgewandelt werden. Ein void -Pointer ist ein Pointer, von dem der Compiler keine Ahnung hat, welche Art Element (Typ) dahintersteckt. Somit ist Pointerarithmetik mit void -Pointern ein Ratespiel.

lalas schrieb:

ich würde das ganze ja gerne umschreiben, nur ist mir nicht so ganz klar wie ich das anders stricken kann.

Mir auch nicht. Deine (seine) StrLstEingabeKompakt( ) ist mir auch spanisch, da 1. (wie schon erwähnt) das realloc( ) herzlich wenig bringt, wenn man die neue Adresse wegwirft und 2. die Adressen der jeweiligen Tokens nicht im Array acListe landen.

lalas schrieb:

nByteNeu=strlen(szPuffer)+1 müsste doch den speicherbedarf als int in nByteNeu schreiben, oder ?

? Was meinst Du damit? Für Speichergrößen sollte man eigentlich den Typ size_t verwenden ( - deine Funktionen sollten statt Integern auch size_t verwenden und zurückgeben).

Vielleicht hilft dir das:

#include <stdlib.h>
#include <stdio.h>
#include <string.h>

#define MAX_ITEMS 100

size_t StrLstEingabeKompakt( char *list[ ], size_t max_items )
{
	char input[ 200 ];
	char *data = 0;
	size_t data_size = 0;
	size_t input_length = 0;
	size_t i = 0;

	for( ; i < max_items; ++i ) {

		fgets( input, 200, stdin );

		if( !strcmp( input, "#\n" ) ) {

			break;
		}

		data = realloc( data, data_size + ( input_length = strlen( input ) + 1 ) );
		strcpy( data + data_size, input );
		list[ i ] = data + data_size;
		data_size += input_length;
	}

	return i;
}

void StrLstAusgabe( char* list[], size_t num_items )
{
	size_t i = 0;

	for( ; i < num_items; ++i ) {

        // fgets( ) liest das newline mit ein. Ausgabe mit puts( ) wär' hässlich ;)
		printf( list[ i ] );
	}
}

int main( )
{
	char *list[ MAX_ITEMS ];
	size_t num_items = StrLstEingabeKompakt( list, MAX_ITEMS );
	StrLstAusgabe( list, num_items );
	free( list[ 0 ] );
}

cheers, Swordfish

PS: void* castet man nicht.

lalas

spitze, das hat mir echt geholfen...danke euch allen.

habe den code jetzt soweit (fast) fertig und es funktioniert alles. muss nun nur noch sortieralgorithmen einbauen und fertig.

was ich allerdings noch immer nicht begriffen habe ist das mit dem free()

was muss ich genau nach dem aufruf von malloc, realloc, etc. genau machen ? einfach am ende der funktion free() schreiben oder noch irgendwelche parameter mit angeben ?

free nimmt void-Zeiger als einzigen Parameter (siehe Swordfish -- auch der hat hin und wieder recht).

gccsucks-freak schrieb:

wie bitte??? nimmt er das als 'char*' an?

Bin leider ein wenig betrunken, trotzdem folgendes:

int main(int ac, char **av)
{
    char buf[32] = {'0', '1', '2', '3', '4', 0};
    void *v = buf;

    v += 1;

    printf("%d %d %d\n", v, v+1, v+2);

    return 0;
}

Kompiliert mit dem GCC ohne Probleme und gibt drei aufeinanderfolgende Ganzzahlen aus. Ist das standard-konform?

#include <stdio.h>

int main(int ac, char **av)
{
    char buf[32] = {'0', '1', '2', '3', '4', 0};
    void *v = buf;

    v += 1;

    printf("%c\n", *(char*)v);

    return 0;
}

Gibt aus: 1

gnu-flamer schrieb:

...Ist das standard-konform?

niemals. bei *void v; v += 1; geht das +=1 nicht.

Swordfish

free-flamer schrieb:

(siehe Swordfish -- auch der hat hin und wieder recht).

cheers, Swordfish

Swordfish schrieb:

free-flamer schrieb:

(siehe Swordfish -- auch der hat hin und wieder recht).

na, da freut sich unser kleines fischlein aber.

Swordfish

fish'n'chips-freak schrieb:

na, da freut sich unser kleines fischlein aber.

Ja ... *freu*

cheers, Swordfish

na, da freut sich unser kleines fischlein aber.

Dann werd ich ihn gleich ein wenig betrüben, damit wir's nicht zu gemütlich haben.

Thou shall not fflush stdin!
Thou shall not cast void pointers! And therefore
Thou shall not cast the result of malloc!

Dein C-Code war gut, aber da drin ist noch ein Syntaxfehler zu töten. Ich sag's mit Shakespeare:

So shalt thou feed on Death, that feeds on men,
and, Death once dead, there's no more dying then.

Swordfish

syntax-flamer schrieb:

[...] aber da drin ist noch ein Syntaxfehler zu töten.

glaub' ich nicht.

cheers, Swordfish

glaub' ich nicht.

<offtopic>
Warum nicht?
</offtopic>