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

[KO Myung-Hun]

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.

Is it fine to wrap these codes in #ifdef...#endif block ?

-- 
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