This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Fix readdir_r with long file names
- From: Andreas Schwab <schwab at suse dot de>
- To: Andreas Jaeger <aj at suse dot com>
- Cc: Florian Weimer <fweimer at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha <libc-alpha at sourceware dot org>
- Date: Thu, 16 May 2013 14:34:08 +0200
- Subject: Re: [PATCH] Fix readdir_r with long file names
- References: <519220C7 dot 6050705 at redhat dot com> <20130516110136 dot GB11420 at spoyarek dot pnq dot redhat dot com> <5194CDEE dot 4020708 at redhat dot com> <5194CE86 dot 7080000 at suse dot com>
Andreas Jaeger <aj@suse.com> writes:
> On 05/16/2013 02:15 PM, Florian Weimer wrote:
>> On 05/16/2013 01:01 PM, Siddhesh Poyarekar wrote:
>>> On Tue, May 14, 2013 at 01:32:23PM +0200, Florian Weimer wrote:
>>>> This patch changes readdir_r to return ENAMETOOLONG if the kernel
>>>> returns a file name longer than NAME_MAX characters, after the end of
>>>> the directory has been reached (so that the directory contents is not
>>>> truncated). It also makes the padding compensation code
>>>> architecture-agnostic and enables it everywhere.
>>>
>>> The specification for readdir/readdir_r does not mention ENAMETOOLONG
>>> as a possible error return[1], so this should at least be mentioned in
>>> the glibc manual, if not also in the man page. So a manual patch is
>>> needed on top of this.
>>
>> Thanks for your comments.
>>
>> We could use EOVERFLOW instead. But ENAMETOOLONG is more informative.
>
> I think the description for EOVERFLOW:
> "One of the values in the structure to be returned cannot be represented
> correctly." fits this case - so, let's use that one to follow POSIX,
No, that doesn't fit. It's a buffer overflow, so ERANGE would be
better.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."