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

[Reimar Döffinger]

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.
The other is that it follows the rule of "keep the hack close to the broken code"

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