[MPlayer-dev-eng] [PATCH] Check if path is too long
komh78 at gmail.com
Fri Jun 7 15:28:27 CEST 2013
Reimar Döffinger wrote:
> On 06.06.2013, at 16:16, KO Myung-Hun <komh78 at gmail.com> wrote:
>> Reimar Döffinger wrote:
>>> On 05.06.2013, at 15:35, KO Myung-Hun <komh78 at gmail.com> wrote
>>> The other is that it follows the rule of "keep the hack close to the broken code"
>> I don't know that the rule is there. And I agree with it in the normal
>> case. But if the root of causes are found, fixing it is better.
> Well, I doubt you'll be able to fix the C library?
Fortunately, I can fix the C library. ^^ The distribution is another
problem, though. TT
> Btw. a backtrace of the error would be useful, any fix should include an exact description of the issue.
What do you mean by 'backtrace' ? Does it mean the crash report of
MPlayer ? Or such a callstack of debugger ?
>> Otherwise, this would be burden to a developer, because, similarly
>> above, a developer have to add the hack keeping track of all the broken
> That isn't any better with your solution, if all file access functions crash, your change addresses only a select few of all the places that cause issues.
> Overriding e.g. open() to use our own implementation in some header would have a chance to fix most.
I was hesitating to do this. Overriding some functions globally, can
causes a name clash with static functions. Especially, they are external
libraries, they are out of our control.
Anyway, I agree that overriding is best solution. So I've updated the
patch to override buggy functions repeatedly file by file.
I'll pray that a crash does not occur any more. ^^
Using Mozilla SeaMonkey 2.7.2
Under OS/2 Warp 4 for Korean with FixPak #15
In VirtualBox v4.1.24 on Intel Core i7-3615QM 2.30GHz with 8GB RAM
Korean OS/2 User Community : http://www.ecomstation.co.kr
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
More information about the MPlayer-dev-eng