hamster_nz was replying to Nwb, as you can see from the quote. You should read hamster_nz's post #12 instead.Originally Posted by awsdert
hamster_nz was replying to Nwb, as you can see from the quote. You should read hamster_nz's post #12 instead.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Tip, works with GCC, CLANG and Intel C++ Compiler (but I'm not sure of __attribute__ syntax there... probably __declspec):
Code:void cleanup_str( char **p ) { free( *p ); } ... /* Some function */ { char *s __attribute__((cleanup(cleanup_str))) = NULL; if ( asprintf( &s, "blablabla: %s = %d\n", str, i ) < 0 ) return 0; // exit the scope. cleanup_str is called. ... use s pointer here... } ... out of scope... cleanup_str() is called.
Yeah that was my mistake for not noticing, doesn't change the validity of what I said, haphazard is after all not what I was going for with maintaining a list of buffers during the life time of the app
That's certainly an interesting way to do it, I prefer explicit calls though, even if that means creating a struct to put all the variables in that need cleanup and just pass it onto a single function which calls all of them, something like:
This provides a consistent and clean way of returning when appropriateCode:struct FOO { struct A *a; struct B *b; } int FooReturn( struct FOO *foo, int ret ) { if( foo->a ) free( foor->a ); if ( foo->b ) free( foor->b ); return ret; } int FooReportAndReturn( FILE *file, char *path, uint line, struct FOO *foo, int err ) { fprintf( file, "%f:%u: Error 0x%08X (%u) '%s'", path, line, err, err, strerror( err ) ); return FooReturn( foo, err ); } #define FooMacroReportAndReturn( FOO, ERR ) FooReportAndReturn( stderr, __FILE__, __LINE__, FOO, ERR ) int Foo() { int err struct FOO foo = {NULL}; foo.a = malloc( sizeof(struct A); foo.b = malloc( sizeof(struct B); .... if ( err ) return FooMacroReportAndReturn( &foo, err ); ... return FooReturn( &foo, 0 ); }
It is always best to free any memory you have allocated using, malloc(), calloc(), or realloc(), then using valgrind under Linux, you can double check for any allocations you missed, along with other memory errors. I use valgrind on all my code.
The other issue with free is not setting the pointer to NULL after freeing the memory. You CANNOT access the memory after freeing it up!!! A better free() can help if consistently used:
This is the way free() should have been defined by Dennis!Code:#include <stdio.h> #include <stdlib.h> void *free2(void *ptr); int main(void) { char *ptr = NULL; ptr = malloc(100); ptr = free2(ptr); /* Can also be called as with free(): free2(ptr); ptr = NULL; */ return 0; } void *free2(void *ptr) { free(ptr); return NULL; }
Did you mean to say that memory available in stack is limited compared to heap (I got this impression because the discussion was about allocating memory on the heap)?
If so, why would that be? I had read that the stack and heap share the same memory space.. stack being at the top and growing downwards and heap being at the bottom and grouping upwards until they meet and there is no more memory left. So since they share the same memory space and grow until they can't.. they should have the same memory limit..
