Follow-up Comment #3, patch #5893 (project mc):
Any particular reason to use FBUF and the supporting routines ? Btw. if we
decide to use those I think that the open/close/write/read/etc routines
should be replaced by their mc_ counterparts - this way your tool would be
able to work on both local
Follow-up Comment #5, patch #5893 (project mc):
Several points:
1) There is off-by-one error when calculating the size of
the `cmd' buffer in dff_execute ().
2) We use glib a lot in MC - you should do the same. Basically when there is
a glib counterpart of a given libc function you should use
Follow-up Comment #7, patch #5893 (project mc):
Your feedback is welcomed.
@1 no there isn't :) check again!
@2 I saw this one coming, after FBUF. I don't use glib, and probably I won't
use it in the foreseeable future. One of the reasons is that I don't find it
very useful, with a few
Follow-up Comment #11, patch #5893 (project mc):
I see I hit a soft spot here. Chill!
Primo: FYI, I wasn't saying glib is good or bad. I said it's uninteresting
to me, as a general concept.
Secundo: I think I said that I am not against it. But the fact I wasn't even
aware of g_try_malloc()
Follow-up Comment #12, patch #5893 (project mc):
You say that the attached piece of code is off by one char? I say it's not.
This is the piece of code that is used in all patches inside dff_execute
(horizontal diff doesn't affect that portion).
(file #12698)