From: <jol...@gm...> - 2007-03-12 20:06:54
|
Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : pfritz > Project : e17 > Module : libs/ecore > > Dir : e17/libs/ecore/src/lib/ecore > > > Modified Files: > Ecore_Str.h ecore_str.c > > > Log Message: > add ecore_str_split(), thanks to rookmoot > > =================================================================== > RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/Ecore_Str.h,v > retrieving revision 1.4 > retrieving revision 1.5 > diff -u -3 -r1.4 -r1.5 > --- Ecore_Str.h 17 Feb 2007 06:25:53 -0000 1.4 > +++ Ecore_Str.h 13 Mar 2007 01:17:33 -0000 1.5 > @@ -46,7 +46,9 @@ > EAPI int ecore_str_has_prefix(const char *str, const char *prefix); > > EAPI int ecore_str_has_suffix(const char *str, const char *suffix); > - > +EAPI char **ecore_str_split(const char *string, const char *delimiter, > + int max_tokens); > +EAPI void ecore_str_vector_free(char **str_array); > > #ifdef __cplusplus > } > =================================================================== > RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/ecore_str.c,v > retrieving revision 1.5 > retrieving revision 1.6 > diff -u -3 -r1.5 -r1.6 > --- ecore_str.c 17 Feb 2007 06:25:53 -0000 1.5 > +++ ecore_str.c 13 Mar 2007 01:17:33 -0000 1.6 > @@ -20,7 +20,8 @@ > #include <sys/types.h> > #include <string.h> > > -# include "ecore_private.h" > +#include "ecore_private.h" > +#include "Ecore_Data.h" > > /* > * Copy src to string dst of size siz. At most siz-1 characters > @@ -129,3 +130,95 @@ > > return (strncmp(str + str_len - suffix_len, suffix, suffix_len) == 0); > } > + > +/** > + * Splits a string into a maximum of max_tokens pieces, using the given > + * delimiter. If max_tokens is reached, the final string in the returned > + * string array contains the remainder of string. > + * > + * @param string A string to split. > + * @param delimiter A string which specifies the places at which to split the > + * string. The delimiter is not included in any of the > + * resulting strings, unless max_tokens is reached. > + * @param max_tokens The maximum number of strings to split string into. > + * If this is less than 1, the string is split completely. > + * @return A newly-allocated NULL-terminated array of strings. > + * Use ecore_str_vector_free() to free it. > + */ > +char** > +ecore_str_split(const char *string, const char *delimiter, int max_tokens) > +{ > + char **str_array = NULL; > + char *s; > + size_t n = 0; > + int max = max_tokens; > + const char *remainder; > + size_t delimiter_len; > + > + CHECK_PARAM_POINTER_RETURN("string", string, NULL); > + CHECK_PARAM_POINTER_RETURN("delimiter", delimiter, NULL); > + > + /* on the first run we just count the number of the strings we'll finally > + * have */ > + remainder = string; > + s = strstr(remainder, delimiter); > + if (s) > + { > + delimiter_len = strlen(delimiter); > + while (--max_tokens && s) > + { > + remainder = s + delimiter_len; > + s = strstr(remainder, delimiter); > + n++; > + } > + } > + if (*string != '\0') n++; > + > + str_array = malloc(sizeof(char *)*(n + 1)); > + str_array[n] = NULL; > + > + /* reset to the initial values */ > + n = 0; > + max_tokens = max; > + remainder = string; > + s = strstr(remainder, delimiter); > + if (s) > + { > + while (--max_tokens && s) > + { > + size_t len; > + char *new_string; > + > + len = s - remainder; > + new_string = malloc(sizeof(char)*(len + 1)); > + memcpy(new_string, remainder, len); > + new_string[len] = 0; > + str_array[n++] = new_string; > + > + remainder = s + delimiter_len; > + s = strstr(remainder, delimiter); > + } > + } > + if (*string != '\0') str_array[n] = strdup(remainder); > + > + return str_array; > +} > + > +/** > + * Free an array of strings and the array itself > + * > + * @param str_array An NULL-terminated array of strings to free. > + */ > +void > +ecore_str_vector_free(char **str_array) > +{ > + CHECK_PARAM_POINTER("str_array", str_array); > + int i; > + > + for(i=0; str_array[i] != NULL; i++) > + { > + FREE(str_array[i]); > + } > + FREE(str_array); > +} > + > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-cvs mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-cvs > > Thanks to use arrays instead of list. Thanks to commit it too :) See you |
From: Vincent T. <vt...@un...> - 2007-03-13 08:31:17
|
On Tue, 13 Mar 2007, Stéphane Bauland wrote: > Hi! > > 1) Why ecore_str_vector_free was removed ? now, you only need to free the returned pointer. There's no need for a function to do that :) I let the others comment the 2nd question :) Vincent |
From: <jol...@gm...> - 2007-03-13 08:47:49
Attachments:
ecorestr.patch
|
Vincent Torri wrote: > > > On Tue, 13 Mar 2007, Stéphane Bauland wrote: > >> Hi! >> >> 1) Why ecore_str_vector_free was removed ? > > now, you only need to free the returned pointer. There's no need for a > function to do that :) > > I let the others comment the 2nd question :) > > Vincent Ok ok i solve memory leak... I don't know if it's a correct way to remove it but apparently it's ok. |
From: Sebastian D. <seb...@ta...> - 2007-03-13 10:01:15
|
Stéphane Bauland wrote: > Vincent Torri wrote: >> >> >> On Tue, 13 Mar 2007, Stéphane Bauland wrote: >> >>> Hi! >>> >>> 1) Why ecore_str_vector_free was removed ? >> >> now, you only need to free the returned pointer. There's no need for a >> function to do that :) >> >> I let the others comment the 2nd question :) >> >> Vincent > Ok ok i solve memory leak... I don't know if it's a correct way to > remove it but apparently it's ok. Wrong fix! The user must free ret[0] && ret. No other possibility. The question is whether this function should do a destructive split or not. Sebastian |
From: Peter W. <pet...@we...> - 2007-03-13 10:05:21
|
St=E9phane Bauland schrieb: > Vincent Torri wrote: > =20 >> On Tue, 13 Mar 2007, St=E9phane Bauland wrote: >> >> =20 >>> Hi! >>> >>> 1) Why ecore_str_vector_free was removed ? >>> =20 >> now, you only need to free the returned pointer. There's no need for a= =20 >> function to do that :) >> >> I let the others comment the 2nd question :) >> >> Vincent >> =20 > Hehe ! I got a memory leak here : > > =20 Don't believe caro, read the doxy :). i. e. if (vec) {free(*vec); free(vec);} |
From: Dave <da...@gu...> - 2008-01-10 15:32:55
|
Enlightenment CVS ha scritto: > Enlightenment CVS committal > > Author : pfritz > Project : e17 > Module : libs/ecore > > Dir : e17/libs/ecore/src/lib/ecore_file > > > Modified Files: > Ecore_File.h > > > Log Message: > remove old api macros > > =================================================================== > RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_file/Ecore_File.h,v > retrieving revision 1.34 > retrieving revision 1.35 > diff -u -3 -r1.34 -r1.35 > --- Ecore_File.h 6 Aug 2007 20:00:28 -0000 1.34 > +++ Ecore_File.h 6 Jan 2008 15:21:00 -0000 1.35 > @@ -71,9 +71,6 @@ > EAPI int ecore_file_symlink (const char *src, const char *dest); > EAPI char *ecore_file_realpath (const char *file); > EAPI int ecore_file_unlink (const char *file); > -/* NOTE: these aliases will be removed! DO NOT USE THEM */ > -#define ecore_file_get_file(path) ecore_file_file_get(path) > -#define ecore_file_get_dir(path) ecore_file_dir_get(path) > EAPI const char *ecore_file_file_get (const char *path); > EAPI char *ecore_file_dir_get (const char *path); > Why ecore_file_file_get is declared static? All the apps/libs that use this function is BROKEN on my system! |
From: Peter W. <pet...@we...> - 2008-01-10 16:34:45
|
Dave schrieb: > Enlightenment CVS ha scritto: > >> Enlightenment CVS committal >> >> Author : pfritz >> Project : e17 >> Module : libs/ecore >> >> Dir : e17/libs/ecore/src/lib/ecore_file >> >> >> Modified Files: >> Ecore_File.h >> >> >> Log Message: >> remove old api macros >> >> =================================================================== >> RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_file/Ecore_File.h,v >> retrieving revision 1.34 >> retrieving revision 1.35 >> diff -u -3 -r1.34 -r1.35 >> --- Ecore_File.h 6 Aug 2007 20:00:28 -0000 1.34 >> +++ Ecore_File.h 6 Jan 2008 15:21:00 -0000 1.35 >> @@ -71,9 +71,6 @@ >> EAPI int ecore_file_symlink (const char *src, const char *dest); >> EAPI char *ecore_file_realpath (const char *file); >> EAPI int ecore_file_unlink (const char *file); >> -/* NOTE: these aliases will be removed! DO NOT USE THEM */ >> -#define ecore_file_get_file(path) ecore_file_file_get(path) >> -#define ecore_file_get_dir(path) ecore_file_dir_get(path) >> EAPI const char *ecore_file_file_get (const char *path); >> EAPI char *ecore_file_dir_get (const char *path); >> >> > Why ecore_file_file_get is declared static? All the apps/libs that use > this function is BROKEN on my system! > Sorry, I don't understand your problem. ecore_file_file_get() isn't declared static. It isn't static in the header - as you can see in the diff above - and it isn't static in the c-file either. Peter |
From: Dave <da...@gu...> - 2008-01-10 16:34:28
|
Peter Wehrfritz ha scritto: > Dave schrieb: >> Enlightenment CVS ha scritto: >> >>> Enlightenment CVS committal >>> >>> Author : pfritz >>> Project : e17 >>> Module : libs/ecore >>> >>> Dir : e17/libs/ecore/src/lib/ecore_file >>> >>> >>> Modified Files: >>> Ecore_File.h >>> >>> Log Message: >>> remove old api macros >>> >>> =================================================================== >>> RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore_file/Ecore_File.h,v >>> retrieving revision 1.34 >>> retrieving revision 1.35 >>> diff -u -3 -r1.34 -r1.35 >>> --- Ecore_File.h 6 Aug 2007 20:00:28 -0000 1.34 >>> +++ Ecore_File.h 6 Jan 2008 15:21:00 -0000 1.35 >>> @@ -71,9 +71,6 @@ >>> EAPI int ecore_file_symlink (const char *src, const >>> char *dest); >>> EAPI char *ecore_file_realpath (const char *file); >>> EAPI int ecore_file_unlink (const char *file); >>> -/* NOTE: these aliases will be removed! DO NOT USE THEM */ >>> -#define ecore_file_get_file(path) ecore_file_file_get(path) >>> -#define ecore_file_get_dir(path) ecore_file_dir_get(path) >>> EAPI const char *ecore_file_file_get (const char *path); >>> EAPI char *ecore_file_dir_get (const char *path); >> Why ecore_file_file_get is declared static? All the apps/libs that >> use this function is BROKEN on my system! >> > Sorry, I don't understand your problem. ecore_file_file_get() isn't > declared static. It isn't static in the header - as you can see in the > diff above - and it isn't static in the c-file either. > > Peter ok solved, I have add: PKG_CHECK_MODULES(EDJE, [ ecore-file >= 0.9.9 ]) ...but strange i didn't need this check before your commit, |
From: nash <na...@fl...> - 2008-01-26 00:47:18
|
On Fri, 2008-01-25 at 13:28 -0500, Enlightenment CVS wrote: > Enlightenment CVS committal > > Author : pfritz > Project : e17 > Module : libs/ecore > =================================================================== > RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/Ecore.h,v > retrieving revision 1.57 > retrieving revision 1.58 > diff -u -3 -r1.57 -r1.58 > --- Ecore.h 11 Jan 2008 07:33:56 -0000 1.57 > +++ Ecore.h 25 Jan 2008 18:28:16 -0000 1.58 > @@ -61,6 +61,9 @@ > extern "C" { > #endif > > +#define ECORE_CALLBACK_CANCEL 0; /**< Return value to remove a callback */ > +#define ECORE_CALLBACK_RENEW 1; /**< Return value to keep a callback */ > + > I'm guessing you don't mean for those two semi-colons to be there... Regards, nash |
From: Peter W. <pet...@we...> - 2008-01-26 14:42:57
|
nash schrieb: > On Fri, 2008-01-25 at 13:28 -0500, Enlightenment CVS wrote: > >> Enlightenment CVS committal >> >> Author : pfritz >> Project : e17 >> Module : libs/ecore >> =================================================================== >> RCS file: /cvs/e/e17/libs/ecore/src/lib/ecore/Ecore.h,v >> retrieving revision 1.57 >> retrieving revision 1.58 >> diff -u -3 -r1.57 -r1.58 >> --- Ecore.h 11 Jan 2008 07:33:56 -0000 1.57 >> +++ Ecore.h 25 Jan 2008 18:28:16 -0000 1.58 >> @@ -61,6 +61,9 @@ >> extern "C" { >> #endif >> >> +#define ECORE_CALLBACK_CANCEL 0; /**< Return value to remove a callback */ >> +#define ECORE_CALLBACK_RENEW 1; /**< Return value to keep a callback */ >> + >> >> > > I'm guessing you don't mean for those two semi-colons to be there... > Yes, you are right. That was a mistake. Thanks, Peter |
From: Michael J. <e-...@ka...> - 2007-03-12 21:42:04
Attachments:
str_split.c
|
On Monday, 12 March 2007, at 21:06:46 (+0100), St?phane Bauland wrote: > > +char** > > +ecore_str_split(const char *string, const char *delimiter, int max_tokens) > > +{ > > + char **str_array = NULL; > > + char *s; > > + size_t n = 0; > > + int max = max_tokens; > > + const char *remainder; > > + size_t delimiter_len; > > + > > + CHECK_PARAM_POINTER_RETURN("string", string, NULL); > > + CHECK_PARAM_POINTER_RETURN("delimiter", delimiter, NULL); > > + > > + /* on the first run we just count the number of the strings we'll finally > > + * have */ > > + remainder = string; > > + s = strstr(remainder, delimiter); > > + if (s) > > + { > > + delimiter_len = strlen(delimiter); > > + while (--max_tokens && s) > > + { > > + remainder = s + delimiter_len; > > + s = strstr(remainder, delimiter); > > + n++; > > + } > > + } > > + if (*string != '\0') n++; > > + > > + str_array = malloc(sizeof(char *)*(n + 1)); > > + str_array[n] = NULL; > > + > > + /* reset to the initial values */ > > + n = 0; > > + max_tokens = max; > > + remainder = string; > > + s = strstr(remainder, delimiter); > > + if (s) > > + { > > + while (--max_tokens && s) > > + { > > + size_t len; > > + char *new_string; > > + > > + len = s - remainder; > > + new_string = malloc(sizeof(char)*(len + 1)); > > + memcpy(new_string, remainder, len); > > + new_string[len] = 0; > > + str_array[n++] = new_string; > > + > > + remainder = s + delimiter_len; > > + s = strstr(remainder, delimiter); > > + } > > + } > > + if (*string != '\0') str_array[n] = strdup(remainder); > > + > > + return str_array; > > +} Long and messy. Find better version attached. And as a bonus, you only have to free the array pointer and its first element. Quickie test program supplied also. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "With every kiss our love is like brand new, and every star up in the sky was made for me and you. Still we both know that the road is long. But we know that we will be together because our love is strong." -- Firehouse, "Love of a Lifetime" |
From: Peter W. <pet...@we...> - 2007-03-13 00:54:02
|
> Long and messy. Find better version attached. And as a bonus, you > only have to free the array pointer and its first element. > > Quickie test program supplied also. > > Michael > Thanks committed. It is indeed much faster. I changed it slightly, because your version had some problems with empty strings. Peter |
From: <jol...@gm...> - 2007-03-13 08:26:08
|
Hi! 1) Why ecore_str_vector_free was removed ? 2) Do you think 2/3 optionals string's functions could be good to have in ecore ? - ecore_str_strdup_printf(format, ...) - ecore_str_memcpy(void *, size) see you Peter Wehrfritz wrote: >> Long and messy. Find better version attached. And as a bonus, you >> only have to free the array pointer and its first element. >> >> Quickie test program supplied also. >> >> Michael >> >> > Thanks committed. It is indeed much faster. I changed it slightly, > because your version had some problems with empty strings. > > Peter > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > |
From: Sebastian D. <seb...@ta...> - 2007-03-13 19:47:26
|
Michael Jennings wrote: > On Tuesday, 13 March 2007, at 20:31:46 (+0100), > Sebastian Dransfeld wrote: > >> Of course I read it. My point is that you could drop the strdup and >> do a destructive split. > > No. Why do I bother arguing? S. |
From: Michael J. <e-...@ka...> - 2007-03-13 20:10:53
|
On Tuesday, 13 March 2007, at 20:46:20 (+0100), Sebastian Dransfeld wrote: > Why do I bother arguing? About making a clean function destructive? Heck if I know... If you wanted to remove the strdup(), the caller would have to accept the destructive nature of the function or remember to pass strdup(str) as the first parameter instead of just str. This would be okay (i.e., no memory leak) since the pointer is reused. But it still makes ugly and non-intuitive code. Better to leave it as is. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "He who hesitates, dies." -- Greg Lippman |
From: Sebastian D. <seb...@ta...> - 2007-03-13 21:35:12
|
Michael Jennings wrote: > On Tuesday, 13 March 2007, at 20:46:20 (+0100), > Sebastian Dransfeld wrote: > >> Why do I bother arguing? > > About making a clean function destructive? Heck if I know... > > If you wanted to remove the strdup(), the caller would have to accept > the destructive nature of the function or remember to pass strdup(str) > as the first parameter instead of just str. This would be okay (i.e., > no memory leak) since the pointer is reused. But it still makes ugly > and non-intuitive code. Better to leave it as is. > > Michael > I agree. Only stated that it was an option, not whether it was sane :) Sebastian |
From: Sebastian D. <seb...@ta...> - 2007-03-13 19:32:53
|
Michael Jennings wrote: > > On Tuesday, 13 March 2007, at 10:59:21 (+0100), > Sebastian Dransfeld wrote: > >> Wrong fix! The user must free ret[0] && ret. No other >> possibility. The question is whether this function should do a >> destructive split or not. > > I take it you missed the "s = strdup(str)" at the beginning.... > > Did ANYBODY actually bother to see how the code works besides Peter? Of course I read it. My point is that you could drop the strdup and do a destructive split. Sebastian |
From: Michael J. <e-...@ka...> - 2007-03-13 19:41:44
|
On Tuesday, 13 March 2007, at 20:31:46 (+0100), Sebastian Dransfeld wrote: > Of course I read it. My point is that you could drop the strdup and > do a destructive split. No. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "It is strange to be known so universally and yet be so lonely." -- Albert Einstein |
From: <jol...@gm...> - 2007-03-13 08:33:02
|
Vincent Torri wrote: > > > On Tue, 13 Mar 2007, Stéphane Bauland wrote: > >> Hi! >> >> 1) Why ecore_str_vector_free was removed ? > > now, you only need to free the returned pointer. There's no need for a > function to do that :) > > I let the others comment the 2nd question :) > > Vincent Hehe ! I got a memory leak here : ligne 165 (ecore_str.c) : s = strdup(str); looks like it isn't freed. ==9844== ==9844== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 109 from 1) ==9844== malloc/free: in use at exit: 60 bytes in 1 blocks. ==9844== malloc/free: 3 allocs, 2 frees, 328 bytes allocated. ==9844== For counts of detected errors, rerun with: -v ==9844== searching for pointers to 1 not-freed blocks. ==9844== checked 558,804 bytes. ==9844== ==9844== 60 bytes in 1 blocks are definitely lost in loss record 1 of 1 ==9844== at 0x401D4B0: malloc (vg_replace_malloc.c:149) ==9844== by 0x468A53F: strdup (in /lib/tls/libc-2.3.6.so) ==9844== by 0x404A51B: ecore_str_split (ecore_str.c:165) ==9844== by 0x8048732: str_split (test.c:12) ==9844== by 0x80487A4: main (test.c:23) ==9844== ==9844== LEAK SUMMARY: ==9844== definitely lost: 60 bytes in 1 blocks. ==9844== possibly lost: 0 bytes in 0 blocks. ==9844== still reachable: 0 bytes in 0 blocks. ==9844== suppressed: 0 bytes in 0 blocks. See you |
From: Vincent T. <vt...@un...> - 2007-03-13 10:38:37
|
On Tue, 13 Mar 2007, Peter Wehrfritz wrote: > Stéphane Bauland schrieb: >> Vincent Torri wrote: >> >>> On Tue, 13 Mar 2007, Stéphane Bauland wrote: >>> >>> >>>> Hi! >>>> >>>> 1) Why ecore_str_vector_free was removed ? >>>> >>> now, you only need to free the returned pointer. There's no need for a >>> function to do that :) >>> >>> I let the others comment the 2nd question :) >>> >>> Vincent >>> >> Hehe ! I got a memory leak here : >> >> > Don't believe caro, read the doxy :). > i. e. if (vec) {free(*vec); free(vec);} yes, you're right. I based my comment on what mej said. Why not only returning &str, instread of str_array, which is allocated for nothing, imho ? Vincent |
From: Michael J. <e-...@ka...> - 2007-03-13 11:26:23
|
On Tuesday, 13 March 2007, at 01:53:57 (+0100), Peter Wehrfritz wrote: > Thanks committed. It is indeed much faster. I changed it slightly, > because your version had some problems with empty strings. I intentionally left out the sanity checks at the beginning so I could test it without having too much macro overhead in the way. :) And I never really thought about how an empty delim string should be handled; your choice seems logical. On Tuesday, 13 March 2007, at 09:26:08 (+0100), St?phane Bauland wrote: > 1) Why ecore_str_vector_free was removed ? It's unnecessary. > 2) Do you think 2/3 optionals string's functions could be good to have > in ecore ? > - ecore_str_strdup_printf(format, ...) > - ecore_str_memcpy(void *, size) No. Completely unnecessary. > Hehe ! I got a memory leak here : > > ligne 165 (ecore_str.c) : s = strdup(str); > > looks like it isn't freed. Did you not read the code? or at least my mailing list message? "And as a bonus, you only have to free the array pointer and its first element." Thank you for dining at the Clueburger; please drive through. > Ok ok i solve memory leak... I don't know if it's a correct way to > remove it but apparently it's ok. No, this is completely wrong and demonstrates no understanding whatsoever of the underlying code. Ridiculous. On Tuesday, 13 March 2007, at 10:59:21 (+0100), Sebastian Dransfeld wrote: > Wrong fix! The user must free ret[0] && ret. No other > possibility. The question is whether this function should do a > destructive split or not. I take it you missed the "s = strdup(str)" at the beginning.... Did ANYBODY actually bother to see how the code works besides Peter? On Tuesday, 13 March 2007, at 11:38:27 (+0100), Vincent Torri wrote: > yes, you're right. I based my comment on what mej said. You misunderstood what mej said. See above. > Why not only returning &str, instread of str_array, which is > allocated for nothing, imho ? YHO is wrong. :) str_array holds the pointers to the tokens just like before. The difference is that I save a crapload of unnecessary malloc()/memcpy() calls by reusing memory I've already allocated. Michael -- Michael Jennings (a.k.a. KainX) http://www.kainx.org/ <me...@ka...> n + 1, Inc., http://www.nplus1.net/ Author, Eterm (www.eterm.org) ----------------------------------------------------------------------- "Windows 95: 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition." -- Unknown |
From: <jol...@gm...> - 2007-03-13 11:30:55
|
Michael Jennings wrote: > On Tuesday, 13 March 2007, at 01:53:57 (+0100), > Peter Wehrfritz wrote: > > >> Thanks committed. It is indeed much faster. I changed it slightly, >> because your version had some problems with empty strings. >> > > I intentionally left out the sanity checks at the beginning so I could > test it without having too much macro overhead in the way. :) And I > never really thought about how an empty delim string should be > handled; your choice seems logical. > > > > On Tuesday, 13 March 2007, at 09:26:08 (+0100), > St?phane Bauland wrote: > > >> 1) Why ecore_str_vector_free was removed ? >> > > It's unnecessary. > > >> 2) Do you think 2/3 optionals string's functions could be good to have >> in ecore ? >> - ecore_str_strdup_printf(format, ...) >> - ecore_str_memcpy(void *, size) >> > > No. Completely unnecessary. > > >> Hehe ! I got a memory leak here : >> >> ligne 165 (ecore_str.c) : s = strdup(str); >> >> looks like it isn't freed. >> > > Did you not read the code? or at least my mailing list message? > > "And as a bonus, you only have to free the array pointer and its first > element." > > Thank you for dining at the Clueburger; please drive through. > > >> Ok ok i solve memory leak... I don't know if it's a correct way to >> remove it but apparently it's ok. >> > > No, this is completely wrong and demonstrates no understanding > whatsoever of the underlying code. Ridiculous. > > > > > On Tuesday, 13 March 2007, at 10:59:21 (+0100), > Sebastian Dransfeld wrote: > > >> Wrong fix! The user must free ret[0] && ret. No other >> possibility. The question is whether this function should do a >> destructive split or not. >> > > I take it you missed the "s = strdup(str)" at the beginning.... > > Did ANYBODY actually bother to see how the code works besides Peter? > > > > > On Tuesday, 13 March 2007, at 11:38:27 (+0100), > Vincent Torri wrote: > > >> yes, you're right. I based my comment on what mej said. >> > > You misunderstood what mej said. See above. > > >> Why not only returning &str, instread of str_array, which is >> allocated for nothing, imho ? >> > > YHO is wrong. :) str_array holds the pointers to the tokens just like > before. The difference is that I save a crapload of unnecessary > malloc()/memcpy() calls by reusing memory I've already allocated. > > Michael > > Hi Michael, i didnt read the doxy changements. But no it's ok. It's faster and it allocates less memory as before! good job! thanks too :) |