4. Problem mit free

Problem mit free

  • S

    Vertexwahn schrieb:

    1u war kein tippfehler - ich dachte die malloc funktion erwartet als angabe der größe einen unsigned int, weil negative byte größen wenig sinn machen - mach das postfix u aus meinem Wert nicht eine unsinged integer?

    malloc erwartet ein size_t. Und mach das sizeof(strlen weg, das ist Quatsch, es heißt nur strlen.

    0
  • V

    supertux schrieb:

    malloc erwartet ein size_t. Und mach das sizeof(strlen weg, das ist Quatsch, es heißt nur strlen.

    und was bitte ist ein size_t? das ist doch ein unsgined int - oder? das sizeof ist natürlich Quatsch

    0
  • S

    Damit es geklärt ist, der Code wäre so richtig

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

typedef struct tmpUserInput{
        char * BottomImageFilename;
} UserInput;

int main(int argc,char *argv[])
{

        UserInput *Input = NULL;

        /* get user input 
        * 
        * in C++ macht man Kommetare mit //
        *
        */

        if(argc!=2)
        {
                printf("Benutzung: %s dateiname\n", argv[0]);
                return 1;
        }

        Input = malloc(sizeof(UserInput));

        if(!Input)
        {
                fprintf(stderr, "Du hast keinen Speicher frei mehr\n");
                return 1;
        }

        /* get memory */

        Input->BottomImageFilename = malloc(strlen(argv[1])+1);

        if(!Input->BottomImageFilename)
        {
                fprintf(stderr, "Du hast keinen Speicher frei mehr\n");
                free(Input);
                return 1;
        }

        strcpy(Input->BottomImageFilename, argv[1]);

        printf("Die Datei heißt: %s\n", Input->BottomImageFilename);

        free(Input->BottomImageFilename);
        free(Input);

        return 0;
}

    edit1:
    hier, damit du dich überzeugst, dass es so richtig läuft

    rex@supertux:~/tmp> valgrind --tool=addrcheck ./test ~/backgrounds/back8.jpg 
==17492== Addrcheck, a fine-grained address checker for x86-linux.
==17492== Copyright (C) 2002-2004, and GNU GPL'd, by Julian Seward et al.
==17492== Using valgrind-2.2.0, a program supervision framework for x86-linux.
==17492== Copyright (C) 2000-2004, and GNU GPL'd, by Julian Seward et al.
==17492== For more details, rerun with: -v
==17492== 
Die Datei heißt: /home/rex/backgrounds/back8.jpg
==17492== 
==17492== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0)
==17492== malloc/free: in use at exit: 0 bytes in 0 blocks.
==17492== malloc/free: 2 allocs, 2 frees, 36 bytes allocated.
==17492== For a detailed leak analysis,  rerun with: --leak-check=yes
==17492== For counts of detected errors, rerun with: -v

    edit2:

    Vertexwahn schrieb:

    und was bitte ist ein size_t? das ist doch ein unsgined int - oder?

    das weiß ich nicht, aber ich glaube schon.

    0
  • V

    C99 kennt auch die // Komentare 😉 (ja ja das wird immer falsch erklärt - es heißt dann immer C kennt nur den mehrzeilenkomentar - aber das hat sich spätestens seit 1999 geändert)

    es lag am dem sizeof operator - mit strcpy hab ich anscheinend in eine speicherbereich geschreiben der mir nicht gehört und bei free gab es dann die ersten prolbeme damit
    -danke es funzt jetzt

    0
  • S

    Vertexwahn schrieb:

    C99 kennt auch die // Komentare 😉

    ja, das weiß ich, aber /* */ sieht es bei C einfach besser 😉

    Vertexwahn schrieb:

    es lag am dem sizeof operator - mit strcpy hab ich anscheinend in eine speicherbereich geschreiben der mir nicht gehört und bei free gab es dann die ersten prolbeme damit
    -danke es funzt jetzt

    es lag daran, dass du den Speicher auch falsch reserviert hast.

    0
  • V
     

    UserInput *newUserInput(int argc, char *argv[])
{
	UserInput *newInput = NULL;

	if(argc != 4)
		return NULL;	// to less or to much arguments

	if(atoi(argv[3]) < 0 || atoi(argv[3]) > 1) 
		return NULL;

	newInput = malloc(sizeof(UserInput));

	// get memory
	newInput->BottomImageFilename = malloc(strlen(argv[1])+1u);
	newInput->TopImageFilename    = malloc(strlen(argv[2])+1u);
	// fill user input structure
	strcpy(newInput->BottomImageFilename, argv[1]);
	strcpy(newInput->TopImageFilename, argv[2]);
	newInput->AlphaBlendFactor = (float)(atof(argv[3]));

	return newInput;
}

    Speicherreservierung immer noch falsch?

    0
  • S

    Vertexwahn schrieb:

    Speicherreservierung immer noch falsch?

    sieht gut aus, aber schreib 1 statt 1u das sieht daemlich aus.

    0
  • S

    was für welche Fehler kommen denn? Überprüfe immer, dass malloc kein NULL zurückgibt. So kann ich nicht sagen, was falsch ist, weil der Code schon gut aussieht (mit Ausnahme von dem 1u)

    edit: oder war deine Frage so, dass wir sagen, ob das gut gemacht ist? Dann: überprüfe immer, dass malloc kein NULL zurückgibt

    0
  • V

    Shade Of Mine schrieb:

    sieht gut aus, aber schreib 1 statt 1u das sieht daemlich aus.

    wenn der Compiler auf den Wert 1 stößt dann interpretiert er das doch als Integer - wenn er auf 1u trifft dann interpretiert er das als unsigned int

    ist es eigentlich definiert wie die adition zwischen einem usigned int + int abläuft? wenn mich es nicht täuscht wird der unsigned int in einen int umgewandelt - dann werden die beiden int addiert und anschließend wird dieser int dann in einen unsigned int gepackt ohne rücksicht auf verluste

    ich fühl mich einfach wohler mit 1u 😉 oder ist das unberechtigt?

    0
  • V

    supertux schrieb:

    edit: oder war deine Frage so, dass wir sagen, ob das gut gemacht ist?

    yup - ich wollte nur wissen ob es so paßt - bei mir gibt es mit dem code keine probleme - mmmh mal sehen ob ich mir das 1u noch abgewöhne...

    0
  • S

    Vertexwahn schrieb:

    Shade Of Mine schrieb:

    sieht gut aus, aber schreib 1 statt 1u das sieht daemlich aus.

    wenn der Compiler auf den Wert 1 stößt dann interpretiert er das doch als Integer - wenn er auf 1u trifft dann interpretiert er das als unsigned int

    ist es eigentlich definiert wie die adition zwischen einem usigned int + int abläuft? wenn mich es nicht täuscht wird der unsigned int in einen int umgewandelt - dann werden die beiden int addiert und anschließend wird dieser int dann in einen unsigned int gepackt ohne rücksicht auf verluste

    ich fühl mich einfach wohler mit 1u 😉 oder ist das unberechtigt?

    das ist doch egal, weil strlen etwas >= 0 zurückliefert und 1 bereits positiv und "unsigned" ist, das heißt, dass bei der Umwandlung nichts verloren geht. Deshalb lass das u weg, vertrau uns.

    0
  • V

    supertux schrieb:

    das ist doch egal, weil strlen etwas >= 0 zurückliefert und 1 bereits positiv und "unsigned" ist, das heißt, dass bei der Umwandlungnichts verloren geht. Deshalb lass das u weg, vertrau uns.

    mmmh - irgendwo hab ich gelesen, dass alles was ganzzahlig ist als signed int interpretiert wird - falls es nicht mir in nen signed in paßt wirds als signed long interpretiert - mmh... ist das jetzt richtig oder falsch?

    0
  • P

    Vertexwahn schrieb:

    ich fühl mich einfach wohler mit 1u 😉 oder ist das unberechtigt?

    Ist korrekt. size_t ist immer unsigned (siehe aktueller C Standard Kapitel 7.17).

    Fuer Konvertierungen zwischen signed und unsigned-Typen siehe Kapitel 6.3.1.1 und 6.3.1.3 (des aktuellen C Standards). I.d.R. wird die Konvertierung dann vorgenommen, wenn sie gebraucht wird. "signed int" und "unsigned int" haben den gleichen Rang. D.h. es wird in Ausdruecken eine Konvertierung in den Zieltyp vorgenommen (integer promotion).

    Fuer "sizeof(x) + 1" bedeutet das, das "1" nach "unsigned int" konvertiert werden muss. "1u" ist sauberer und macht klar, dass der Ausdruck "unsigned" ist.

    Bei der Konvertierung von "signed int" nach "unsigned int" wird wegen desselben Ranges aber i.d.R. keine Compiler-Warnung ausgegeben.

    0
Anmelden zum Antworten