lib-vfs-mc-vfs-extfs.c-UN-need-goto

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/2057
Reporter	vit_r (vit_r@….ru)

a try to simplify ("nothing" is changed)

Note

Original attachments:

• 2057-lib-vfs-mc-vfs-extfs.c-UN-need-goto.patch (raw) by vit_r (vit_r@….ru) on Feb 24, 2010 at 16:16 UTC

[mc-butler]

Changed by vit_r (vit_r@….ru) on Feb 24, 2010 at 16:16 UTC

• Attachment 2057-lib-vfs-mc-vfs-extfs.c-UN-need-goto.patch (raw) added

[mc-butler]

Changed by andrew_b (@aborodin) on Feb 24, 2010 at 17:56 UTC (comment 1)

• Description edited

What about #2033?

[mc-butler]

Changed by andrew_b (@aborodin) on Feb 25, 2010 at 7:34 UTC (comment 2)

• Milestone 4.7 deleted
• Status changed from new to closed
• Version master deleted
• Resolution set to invalid

973	972	    q = extfs_get_path_mangle (me, mpath, &archive, FALSE); 
 	973	    g_free (mpath); 
974	974	    if (q == NULL) 
975	 	        goto cleanup; 
 	975	        return -1; 
 	976	 
976	977	    entry = extfs_find_entry (archive->root_entry, q, FALSE, FALSE); 

The result of extfs_get_path_mangle() cannot be free immediately after function call because it points to function argument (mpath in this case).

[mc-butler]

Changed by vit_r (vit_r@….ru) on Feb 28, 2010 at 21:03 UTC (comment 2.3)

The result of extfs_get_path_mangle() cannot be free immediately after function
call because it points to function argument (mpath in this case).

But "nothing" is changed
It is only a try to simplify text
The result of extfs_get_path_mangle() is not freed (as it was not freed)

'g_free (mpath);' was at the end of funcs
and now it is immediately after using it in call

This patch is correct and is much better then prev version #2033

When code is more clear looking it makes it easier to go ahead

May be a prove is just around the corner

Please look once more

[mc-butler]

Changed by andrew_b (@aborodin) on Mar 1, 2010 at 8:21 UTC (comment 3.4)

Replying to vit_r:

The result of extfs_get_path_mangle() cannot be free immediately after function
call because it points to function argument (mpath in this case).

But "nothing" is changed
It is only a try to simplify text
The result of extfs_get_path_mangle() is not freed (as it was not freed)

Sorry, I was incorrect.

'g_free (mpath);' was at the end of funcs
and now it is immediately after using it in call

I meant that mpath cannot be freed immediately after call of extfs_get_path_mangle() because q (the returned value of extfs_get_path_mangle()) points to the part of mpath. If you delete mpath, q will point to deallocated memory.

[mc-butler]

Changed by vit_r (vit_r@….ru) on Mar 1, 2010 at 18:28 UTC (comment 4.5)

Replying to andrew_b:
Thanks
Actually (I really think so)

it is my prev fault (invalid patch trying g_free (q))

Bugs are surviving by helping each other to multiply ...

But most important (sorry about asking):

Did You applied this patch to see quit obvious bug (at least one) ?

And thanks for fast reply also

And one more thing
i'm 'hunted' everyday by one idea ... better to leave for the room
(coming to the room scares me (i'im almost pissed out) ... :-(O )
but i'll come for sure ( I sincerely hope ... i'll knock )

And great happening: '_vfs_get_cwd ();'
I'm now armed
You gave me the proof i was searching for
to use in arguing with dev-team ... ahead ...

[mc-butler]

Changed by vit_r (vit_r@….ru) on Mar 3, 2010 at 15:13 UTC (comment 4.6)

Replying to andrew_b:

I meant that mpath cannot be freed immediately after call of >extfs_get_path_mangle() because q (the returned value of extfs_get_path_mangle()) >points to the part of mpath. If you delete mpath, q will point to deallocated >memory.

Thanks, You are right !
My testing was shallow, because it was only MC
In real situation freed mem can be used by OS and 'q' would be corrupted

Great lesson.

Still can I try once more ?