On Fri, 21 Dec 2012 23:06:24 +0100
Maxime Villard wrote:
> Le 21/12/2012 22:32, Michael Blumenkrantz a écrit :
> > On Fri, 21 Dec 2012 22:17:32 +0100
> > Maxime Villard wrote:
> >
> >> > Hi,
> >> > same patch as before: removed useless nullchecks and
> >> > switched some free()'s to E_FREE().
>
Le 21/12/2012 22:32, Michael Blumenkrantz a écrit :
> On Fri, 21 Dec 2012 22:17:32 +0100
> Maxime Villard wrote:
>
>> > Hi,
>> > same patch as before: removed useless nullchecks and
>> > switched some free()'s to E_FREE().
> Hi,
>
> I've committed your patch, but you really need to compile test
On Fri, 21 Dec 2012 22:17:32 +0100
Maxime Villard wrote:
> Hi,
> same patch as before: removed useless nullchecks and
> switched some free()'s to E_FREE().
Hi,
I've committed your patch, but you really need to compile test before sending
patches :p
>From the patch it seems that the called "dangling" pointers shouldn't be
used anymore, then it is correct to leave them like that. If you still use
them, valgrind will warn.
things like:
+ free(eth->file);
+ free(eth->key);
free(eth);
the fil
On Wed, Dec 19, 2012 at 04:24:13PM +, Michael Blumenkrantz wrote:
> On Wed, Dec 19, 2012 at 4:20 PM, Leandro Dorileo
> wrote:
>
> > Hi Maxime,
> >
> > On Wed, Dec 19, 2012 at 03:07:13PM +0100, Maxime Villard wrote:
> > > Hi,
> > > here is a patch.
> > >
> > > 1. free() already null-checks the
On Wed, Dec 19, 2012 at 4:20 PM, Leandro Dorileo wrote:
> Hi Maxime,
>
> On Wed, Dec 19, 2012 at 03:07:13PM +0100, Maxime Villard wrote:
> > Hi,
> > here is a patch.
> >
> > 1. free() already null-checks the passed argument, so it is not
> >necessary to do 'if(x) free(x)'.
>
>
> Isn't that rea
Hi Maxime,
On Wed, Dec 19, 2012 at 03:07:13PM +0100, Maxime Villard wrote:
> Hi,
> here is a patch.
>
> 1. free() already null-checks the passed argument, so it is not
>necessary to do 'if(x) free(x)'.
Isn't that reasoneable to replace if (x) free(x) by E_FREE(x)?
Regards.
>
> 2. Mo
in
On Wed, Dec 19, 2012 at 2:07 PM, Maxime Villard wrote:
> Hi,
> here is a patch.
>
> 1. free() already null-checks the passed argument, so it is not
>necessary to do 'if(x) free(x)'.
>
> 2. Moved some '{free(x); x = NULL}' to E_FREE.
>
> 3. In e_start_main.c, 'buf' is allocated with the si
On Sat, 15 Dec 2012 22:31:52 +0100 Maxime Villard said:
> Just a patch to avoid using strdupa(), which doesn't exist
> on BSD's.
>
> By the way, 'buf' - and 'trash_dir' now - should be PATH_MAX
> instead, no ?
hmm i just added the macro for it instead... so solved it differently... :/
--
On Sat, 15 Dec 2012 08:43:03 +0100 Maxime Villard said:
> Le 15/12/2012 08:19, Maxime Villard a écrit :
> > Le 14/12/2012 06:29, Carsten Haitzler (The Rasterman) a écrit :
> >> > i put in just fixed for the FILE * leak here on error -
> >> > the rest i kept.
> > Why ?
>
> I would also move some
On Sat, 15 Dec 2012 13:03:10 +0100 Maxime Villard said:
> A little patch to fix a possible warning - and overflow.
>
> 'buf' is PATH_MAX, but PATH_MAX is not necessary 1024. If
> PATH_MAX < 1024 -> overflow.
>
> Also, fgets() fills the buffer and nullterminate it, so we
> don't need to buff[0]
;t know if you noticed, but I sent a patch before your answer.
Message original --------
Sujet: Re: [E-devel] [e] [patch] Leak (was FreeBSD patch)
Date : Sat, 15 Dec 2012 08:43:03 +0100
De : Maxime Villard
Répondre à : Enlightenment developer list
Pour : enlightenment-devel@lists.sourc
On Sat, 15 Dec 2012 08:19:24 +0100 Maxime Villard said:
> Le 14/12/2012 06:29, Carsten Haitzler (The Rasterman) a écrit :
> > i put in just fixed for the FILE * leak here on error -
> > the rest i kept.
>
> Why ?
because i didnt use your patch at all - i just fixed the file leak that it
pointed
Le 15/12/2012 08:19, Maxime Villard a écrit :
> Le 14/12/2012 06:29, Carsten Haitzler (The Rasterman) a écrit :
>> > i put in just fixed for the FILE * leak here on error -
>> > the rest i kept.
> Why ?
I would also move some {free(x); x = null} to E_FREE.
Patch joined.
--- tempget.c 2012-12-15 0
Le 14/12/2012 06:29, Carsten Haitzler (The Rasterman) a écrit :
> i put in just fixed for the FILE * leak here on error -
> the rest i kept.
Why ?
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Rem
On Thu, 13 Dec 2012 21:04:51 +0100 Maxime Villard said:
i put in just fixed for the FILE * leak here on error - the rest i kept. i did
it differently tho.
> Hum, I sent it two weeks ago
>
>
> I. Removed useless 'buf[sizeof(buf) - 1] = 0;', fgets()
> already does that
>
> II. Ensure file
On Thu, 13 Dec 2012 21:04:51 +0100
Maxime Villard wrote:
> Hum, I sent it two weeks ago
>
>
> I. Removed useless 'buf[sizeof(buf) - 1] = 0;', fgets()
> already does that
>
> II. Ensure file descriptors are closed before 'goto error'
>
> III.We don't need to nullcheck before freeing a buf
On Thu, 25 Oct 2012 20:53:33 +0200 Joerg Sonnenberger
said:
> On Thu, Oct 25, 2012 at 07:32:19PM +0200, rustyBSD wrote:
> > III. There is a problem with _e_fm_op_random_char().
> > When wewant to randomize a string we do srand(time())
> > foreachcharacter, so if the file is small enough
> > to be
:31 (GMT+09:00)
Title : Re: [E-devel] [e][patch] iconify/uniconify bug?
On 11/27/2012 02:52 AM, Doyoun Kang wrote:
> Dear all.
>
> I found something like a bug. The window doesn't hide calling hide
window(like ecore_x_window_hide() or evas_object_hide(), etc.
On 11/27/2012 02:52 AM, Doyoun Kang wrote:
> Dear all.
>
> I found something like a bug. The window doesn't hide calling hide
> window(like ecore_x_window_hide() or evas_object_hide(), etc.) after
> iconifing and uniconifing window.
> I found that it was caused by bd->await_hide_event. When the w
On 11/27/2012 02:52 AM, Doyoun Kang wrote:
> Dear all.
>
> I found something like a bug. The window doesn't hide calling hide
> window(like ecore_x_window_hide() or evas_object_hide(), etc.) after
> iconifing and uniconifing window.
> I found that it was caused by bd->await_hide_event. When the w
thanks. I know you're just trying to help, but we WILL get to these
patches, I promise :)
On Fri, Oct 26, 2012 at 8:42 AM, Vincent Torri wrote:
> ok, i won't do it anymore
>
> On Fri, Oct 26, 2012 at 9:22 AM, Michael Blumenkrantz
> wrote:
> > in the future, please wait more than 12 minutes befor
ok, i won't do it anymore
On Fri, Oct 26, 2012 at 9:22 AM, Michael Blumenkrantz
wrote:
> in the future, please wait more than 12 minutes before committing a patch
> for a component which you have not previously worked with and are not the
> maintainer of. immediately committing patches like this
in the future, please wait more than 12 minutes before committing a patch
for a component which you have not previously worked with and are not the
maintainer of. immediately committing patches like this has led to a number
of frustrating bug reports in the recent past.
On Thu, Oct 25, 2012 at 6:4
On Thu, Oct 25, 2012 at 07:32:19PM +0200, rustyBSD wrote:
> III. There is a problem with _e_fm_op_random_char().
> When wewant to randomize a string we do srand(time())
> foreachcharacter, so if the file is small enough
> to be deleted inless than a second, it's not randomized.
> And even if it's b
in svn, thanks
Vincent
On Thu, Oct 25, 2012 at 7:32 PM, rustyBSD wrote:
> Hi all,
> here is a patch for the randomization in
> e/src/bin/e_fm_op.c.
>
>
> I. Simplification, andif we cannot stat(), the best
> thing to do is toswitch to a copy-delete operation.
>
> II.Just stuff...
>
> III. There
in svn, thanks
On Sat, Sep 29, 2012 at 9:09 AM, rustyBSD wrote:
> Hi,
> some trivial changes.
>
> I. _e_fm_op_stdin_handler is unused, so -> removed.
>
> II. if we cannot malloc _e_fm_op_stdin_buffer, we
> are in big shit, so nullcheck.
>
> III. Formatting.
>
> IV. if argc < 4 we quit, s
27 matches
Mail list logo
