>> sprintf(keyid,"%d",id);
>snprintf(keyid, 4, "%d", id);
>but 4 seems rather smallish. Also, why map ints to chars here? Might
as
>well defer that to the snprintf call in construct_keyname, changing
the
>'postfix' argument to an int.
I change it to a char because of mapping idnr numbers to usernames,
and also libmemcache takes strings for keynames.
On 04/01/2012 at 1:56 PM, Paul J Stevens wrote:On 04/01/2012 02:05
PM, skr...@hushmail.com wrote:
On 04/01/2012 02:05 PM, skr...@hushmail.com wrote:
>
> Ok say I have this
>
> char* construct_keyname(char *key, char *postfix){
> char *keyname;
> keyname = (char *)malloc(KEY_SIZE*sizeof(char)); //allocate
> memory that is freed inmemcache_gstr and memcache_gid
>
> snprintf(keyname,
> (
>
(strlen(MEMCACHE_PRFX)+strlen(postfix)+strlen(key))
> +3
> ),
> "%s%s_%s",
> MEMCACHE_PRFX,
> key,
> postfix);
>
> return keyname;
> }
>
> I have allocated memory for the prefix name
>
> char *memcache_gstr(char *key, int id){
> char *ret;
> char *keyname;
> char keyid[4];
> sprintf(keyid,"%d",id);
> keyname= construct_keyname(key,keyid);
> printf("key: %sn", keyname);
> ret = getmc(keyname);
> free(keyname);
> return ret;
> }
> then I call it here and since the return value of the keyname
> constructor is allocated memory can I free it with the pointer that
I
> assigned to it? ie: keyname
>
> keyname is a pointer that points to the return value of
> construct_keyname() and the return value is allocated on the "heap".
Is
> that right?
>
>
> On 04/01/2012 at 7:51 AM, Paul J Stevens wrote:
>
> On 04/01/2012 02:38 AM, skr...@hushmail.com wrote:
> > https://github.com/skrapsrwt/dbmail-memcache/
>
> I looked at the 'push change and added some comments.
>
> Most importantly you need to understand C doesn't have automatic
> allocation/de-allocation of memory like PHP does.
>
> If you want to assign something to a chunk of memory that memory
must be
> allocated, either on the 'stack', or on the 'heap'.
>
> The stack is local to the scope. So it can be passed
'down-stream' if
> you are careful, but it can never be returned to the calling
scope.
>
> The heap is where malloc/free do their thing: a global memory
space that
> you can use - if you use it following the rules. Heap memory is
always
> safe to pass around.
>
> - you must allocated everything you need.
> - for each malloc call, there must be a free call.
>
> stack allocation:
>
> char foo[128]; // char array on the stack you can assign 128
bytes to
>
> char *foo = g_new0(char, 128); // same size char array on the
heap
>
>
> g_new0 is a simple wrapper around calloc. It allocates memory
and cleans
> it out.
>
> If you allocate on the stack it is always a good idea to clean
it
> explicitely:
>
> char foo[128];
> memset(foo, 0, sizeof(foo));
>
>
>
> --
> ________________________________________________________________
> Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
>
> * Premium Hosting Services and Web Application Consultancy *
>
> www.nfg.nl/i...@nfg.nl/+31.85.877.99.97
>
> ________________________________________________________________
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
>
>
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/i...@nfg.nl/+31.85.877.99.97
________________________________________________________________
>
> Ok say I have this
>
> char* construct_keyname(char *key, char *postfix){
> char *keyname;
> keyname = (char *)malloc(KEY_SIZE*sizeof(char)); //allocate
> memory that is freed inmemcache_gstr and memcache_gid
Use:
keyname = g_new0(char, KEY_SIZE);
which will clean out the assigned memory segment.
>
> snprintf(keyname,
> (
>
(strlen(MEMCACHE_PRFX)+strlen(postfix)+strlen(key))
> +3
> ),
This ain't right.
the second argument to snprintf doesn't have to be the exact size of
the
remainder arguments. Just the max size of the string in the first
argument. So:
snprintf(keynam, KEY_SIZE, "%s%s_%s", MEMCACHE_PRFX, key, postfix);
> "%s%s_%s",
> MEMCACHE_PRFX,
> key,
> postfix);
>
> return keyname;
> }
>
> I have allocated memory for the prefix name
>
> char *memcache_gstr(char *key, int id){
> char *ret;
> char *keyname;
> char keyid[4];
please add:
memset(keyid, 0, sizeof(keyid));
you really need to clean out memory. There is *no* guarantees the
memory
doesn't contain values already.
> sprintf(keyid,"%d",id);
snprintf(keyid, 4, "%d", id);
but 4 seems rather smallish. Also, why map ints to chars here? Might
as
well defer that to the snprintf call in construct_keyname, changing
the
'postfix' argument to an int.
> keyname= construct_keyname(key,keyid);
> printf("key: %sn", keyname);
> ret = getmc(keyname);
> free(keyname);
> return ret;
> }
> then I call it here and since the return value of the keyname
> constructor is allocated memory can I free it with the pointer that
I
> assigned to it? ie: keyname
>
> keyname is a pointer that points to the return value of
> construct_keyname() and the return value is allocated on the "heap".
Is
> that right?
Yes. Though you always have to make sure the pointer wasn't modified.
Consider the following leaking example:
char *longstring = g_new0(char, 65535);
longstring += 100; // now longstring points to the 100th
// char in the array
g_free(longstring); // the first 100 chars are *not* freed.
One way this is commonly solved:
char *longstring = g_new0(char, 65535);
char *start = longstring;
g_free(start);
Leakage solved!
So there is another reason to do static builds: you can use valgrind
to
help you catch this kind of problem early on.
Also: valgrind is much better than gdb or gcc to help pin-point the
cause of segfaults.
longstring += 100;
--
________________________________________________________________
Paul J Stevens pjstevns @ gmail, twitter, skype, linkedin
* Premium Hosting Services and Web Application Consultancy *
www.nfg.nl/i...@nfg.nl/+31.85.877.99.97
________________________________________________________________
_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev_______________________________________________
Dbmail-dev mailing list
Dbmail-dev@dbmail.org
http://mailman.fastxs.nl/cgi-bin/mailman/listinfo/dbmail-dev
