[patch] libstdc++/67747 Allocate space for dirent::d_name

[Jonathan Wakely]

On 02/10/15 14:41 +0200, Florian Weimer wrote:
>On 10/02/2015 02:34 PM, Jonathan Wakely wrote:
>> On 02/10/15 14:16 +0200, Florian Weimer wrote:
>>> On 09/29/2015 01:37 PM, Jonathan Wakely wrote:
>>>> POSIX says that dirent::d_name has an unspecified length, so calls to
>>>> readdir_r must pass a buffer with enough trailing space for
>>>> {NAME_MAX}+1 characters. I wasn't doing that, which works OK on
>>>> GNU/Linux and BSD where d_name is a large array, but fails on Solaris
>>>> 32-bit.
>>>>
>>>> This uses pathconf to get NAME_MAX and allocates a buffer.
>>>
>>> This still has a buffer overflow on certain file systems.
>>>
>>> You must not use readdir_r, it is deprecated and always insecure.  We
>>> should probably mark it as such in the glibc headers.
>>
>> OK, I'll just use readdir() then. The directory stream is private to
>> the library type, so the only way to call readdir() concurrently on a
>> single directory stream is to increment iterators concurrently, which
>> is undefined anyway.
>
>Right, that's the only case where readdir_r could be theoretically
>useful.  But it's not a global structure, the callers have to coordinate
>anyway, and so you could well use an external lock.

Here's a much simpler patch that just uses readdir, so not need for
pathconf, NAME_MAX and all that jazz.

Tested on GNU/Linux, DragonFly, AIX, committed to trunk.

>> So that will work as long as readdir() doesn't use a global static
>> buffer shared between streams, i.e. it meets the POSIX requirement
>> that "They shall not be affected by a call to readdir() on a different
>> directory stream." I don't know if mingw meets that, but there is lots
>> of work needed to make this stuff work in mingw.
>
>If mingw has this flaw, it is worth fixing on its own, and mingw is
>sufficiently alive that sticking workarounds into libstdc++ for its bugs
>doesn't make sense (IMHO).

FWIW I checked and the readdir in mingw-w64 is OK.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: patch.txt
Type: text/x-patch
Size: 3589 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20151002/eadba882/attachment.bin>