On 08.10.2016 22:31, Gerald Pfeifer wrote:
- char cStr[sizeof(dent->d_name)+sizeof(procname_ide_media)],
http://man7.org/linux/man-pages/man3/readdir.3.html says:
"""The standard also notes that the use of sizeof(d_name) is incorrect; use strlen(d_name) instead. (On some systems, this field is defined as char d_name[1]!)"""
This means your solution will not work on all systems.
On Sun, 9 Oct 2016, Sebastian Lackner wrote:
On 08.10.2016 22:31, Gerald Pfeifer wrote:
- char cStr[sizeof(dent->d_name)+sizeof(procname_ide_media)],
http://man7.org/linux/man-pages/man3/readdir.3.html says:
"""The standard also notes that the use of sizeof(d_name) is incorrect; use strlen(d_name) instead. (On some systems, this field is defined as char d_name[1]!)"""
This means your solution will not work on all systems.
Interesting, thanks! Does this happen on any system we care about?
I checked a current GNU/Linux system and FreeBSD, and on both sizeof(d_name) works. Still, good to make this more portable, so would
char cStr[NAME_MAX+sizeof(procname_ide_media)]
work?
According to that man page
Warning: applications should avoid any dependence on the size of the d_name field. POSIX defines it as char d_name[], a character array of unspecified size, with at most NAME_MAX characters preceding the termi- nating null byte ('\0').
so we should be fine, shouldn't we?
Gerald
On 09.10.2016 22:30, Gerald Pfeifer wrote:
On Sun, 9 Oct 2016, Sebastian Lackner wrote:
On 08.10.2016 22:31, Gerald Pfeifer wrote:
- char cStr[sizeof(dent->d_name)+sizeof(procname_ide_media)],
http://man7.org/linux/man-pages/man3/readdir.3.html says:
"""The standard also notes that the use of sizeof(d_name) is incorrect; use strlen(d_name) instead. (On some systems, this field is defined as char d_name[1]!)"""
This means your solution will not work on all systems.
Interesting, thanks! Does this happen on any system we care about?
I checked a current GNU/Linux system and FreeBSD, and on both sizeof(d_name) works. Still, good to make this more portable, so would
char cStr[NAME_MAX+sizeof(procname_ide_media)]
work?
According to that man page
Warning: applications should avoid any dependence on the size of the d_name field. POSIX defines it as char d_name[], a character array of unspecified size, with at most NAME_MAX characters preceding the termi- nating null byte ('\0').
so we should be fine, shouldn't we?
Gerald
NAME_MAX is only used at a few places, so not sure if it works on all platforms. The best method is usually to allocate a buffer dynamically, but not sure if its worth the effort for such old legacy code. Adding a length check at the beginning is probably easier.
Btw, please also note that cUnixDeviceName is also affected by potential buffer overflow issues.
Regards, Sebastian
On Tue, 11 Oct 2016, Sebastian Lackner wrote:
According to that man page
Warning: applications should avoid any dependence on the size of the d_name field. POSIX defines it as char d_name[], a character array of unspecified size, with at most NAME_MAX characters preceding the termi- nating null byte ('\0').
so we should be fine, shouldn't we?
NAME_MAX is only used at a few places, so not sure if it works on all platforms.
In my experience, if it works on a Linux distro like openSUSE and FreeBSD, it tends to work on all platforms Wine supports. ;-)
The better argument probably is that NAME_MAX is used in ntdll/directory.c already.
Btw, please also note that cUnixDeviceName is also affected by potential buffer overflow issues.
Yes, that's on my radar, too. First I wanted to make sure we have agreement on how to go after this first case. I'll submit an updated patch in a minute.
Sorry for the delay with that...
Gerald
Gerald Pfeifer gerald@pfeifer.com writes:
On Tue, 11 Oct 2016, Sebastian Lackner wrote:
According to that man page
Warning: applications should avoid any dependence on the size of the d_name field. POSIX defines it as char d_name[], a character array of unspecified size, with at most NAME_MAX characters preceding the termi- nating null byte ('\0').
so we should be fine, shouldn't we?
NAME_MAX is only used at a few places, so not sure if it works on all platforms.
In my experience, if it works on a Linux distro like openSUSE and FreeBSD, it tends to work on all platforms Wine supports. ;-)
The better argument probably is that NAME_MAX is used in ntdll/directory.c already.
Not really, only in a very system-specific case.
The existing sizes are fine, but if you really want to fix that code, you should check for overflow and simply ignore names that don't match what we expect.
-
Alexandre Julliard -
Gerald Pfeifer -
Sebastian Lackner