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

Cyril Hrubis
2023-10-24T09:36:20Z

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.

--
Cyril Hrubis
chrubis@suse.cz