[LTP] [PATCH 3/3] Provide a PATH_MAX-long buffer when expecting ENAMETOOLONG

[Kevin Brodsky]

On 24/10/2023 11:36, Cyril Hrubis wrote:
> Hi!
>>> Sigh, I meant 2. I guess that we would have to loop over filesystems
>>> (easily done with .all_filesystems = 1) and pass very long filename. Or
>>> do we have such test already?
>>>
>>> Looking at our tests, the rename10.c is actually one of two tests that
>>> sets .all_fileystems and checks for ENAMETOOLONG. Looking at the
>>> filesystem limits, all seems to have limits that are <= 255 characters,
>>> the only problem is a definition of character. For utf8 character 255
>>> characters are around 1021 (including nul terminator). So I suppose that
>>> if we pass another buffer that is PATH_MAX in length and has PATH_MAX-1
>>> characters we should consistenly hit 2. Or do I miss something?
>> This is a good point, I didn't think about it this way. Your idea seems
>> sensible. With this patch we always hit 1. as we specify a string that
>> is longer than PATH_MAX. We could instead hit 2. without out-of-bound
>> access by specifying a string that is at most PATH_MAX in length
>> (including the null terminator), and at least the filesystem character
>> limit. Maybe something like the diff below (just tested it, that works
>> fine).
> Can we actually have two long paths in the test and test both? That
> should have the best test coverage.

Certainly, that should be easy enough. I can post a follow-up patch to
that effect.

Kevin