[MPlayer-dev-eng] [PATCH] Check if path is too long

[KO Myung-Hun]

Reimar Döffinger wrote:
> On 05.06.2013, at 15:35, KO Myung-Hun <komh78 at gmail.com> wrote:
>> Reimar Döffinger wrote:
>>> On 05.06.2013, at 02:39, KO Myung-Hun <komh78 at gmail.com> wrote:
>>>> Hi/2.
>>>>
>>>> Reimar Döffinger wrote:
>>>>> On Tue, Jun 04, 2013 at 12:57:03PM +0900, KO Myung-Hun wrote:
>>>>>> Hi/2.
>>>>>>
>>>>>> This patch fixes the problem that MPlayer crashes if a path is too long.
>>>>>
>>>>> Why? I don't see anything in the code that you change that should
>>>>> cause crashes if the path is very long?
>>>>> Unless the open function itself crashes, but I'm not exactly convinced
>>>>> we should work around an OS issue like that, and if we do we should only
>>>>> do it for that specific OS (and probably closer to the issue, e.g. doing
>>>>> a strlen just before open()).
>>>>
>>>> I agree with you, because it was my first approach. But I think, it is
>>>> just a symptomatic treatment. So it is more general and more fundamental
>>>> to prevent from generating a too long path itself.
>>>
>>> I disagree, there is no such thing as a "too long path".
>>> While PATH_MAX is a convenient hack when you need to decide which buffer size to use and in some cases things _might_ stop working for names longer than it, it is also possible that names longer than that work perfectly fine.
>>> I see no good reason to "pre-emptively" break very long file names on purpose, just because they _might_ not work.
>>
>> Yes, a real path can be longer than PATH_MAX.
>>
>> However, I don't see the differences between this and checking a path
>> length before fopen() or such a things.
> 
> One thing is that it is hopefully less or at least less complex code.

Hmm... I don't know what you call 'complex code'. But at least, the same
codes should be written repeatedly. And this has a potential problem in
the future codes. All the writers should remember that this check should
be done before buggy functions.

> 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.
Otherwise, this would be burden to a developer, because, similarly
above, a developer have to add the hack keeping track of all the broken
codes.

>> Is it fine to wrap these codes in #ifdef...#endif block ?
> 
> As said, I don't think having these checks so far from the code that causes issues is good.
> But it is better with ifdefs.

Ok. I've introduced a conditional macro.

-- 
KO Myung-Hun

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...
Name: pathlimit.diff
URL: <http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/attachments/20130606/b3f6b943/attachment.ksh>