Newer versions of gcc/glibc with fortify checks enabled will complain about the handling of the network's szNames field. Currently it is always defined with a length of one which means writing more then a single byte will trigger: In function 'strcpy', inlined from '_ILCreateEntireNetwork' at dlls/shell32/pidl.c:1762:15: warning: call to __builtin___strcpy_chk will always overflow destination buffer and then at runtime, we hit an abort().
Since this field is really serving as the header to an arbitrary buffer, using a flexible array instead should solve the issue.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- note: i couldnt find a statement of what C standard wine aims for. if it is attempting pre-c99, then this will have to be done differently. perhaps introducing a project-wide define like "VARARRAY" which expands into [] for c99+ and [1] for older ...
dlls/shell32/pidl.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dlls/shell32/pidl.h b/dlls/shell32/pidl.h index 3dbfaa6..bbfacef 100644 --- a/dlls/shell32/pidl.h +++ b/dlls/shell32/pidl.h @@ -172,12 +172,12 @@ typedef struct tagPIDLDATA struct tagFileStruct file; struct { WORD dummy; /*01*/ - CHAR szNames[1]; /*03*/ + CHAR szNames[]; /*03*/ } network; struct { WORD dummy; /*01*/ DWORD dummy1; /*02*/ - CHAR szName[1]; /*06*/ /* terminated by 0x00 0x00 */ + CHAR szName[]; /*06*/ /* terminated by 0x00 0x00 */ } htmlhelp; struct tagPIDLCPanelStruct cpanel; struct tagValueW valueW;
Newer versions of gcc/glibc with fortify checks enabled will complain about the handling of the network's szNames field. Currently it is always defined with a length of one which means writing more then a single byte will trigger: In function 'strcpy', inlined from '_ILCreateEntireNetwork' at dlls/shell32/pidl.c:1762:15: warning: call to __builtin___strcpy_chk will always overflow destination buffer and then at runtime, we hit an abort().
Since this field is really serving as the header to an arbitrary buffer, using a flexible array instead should solve the issue.
Signed-off-by: Mike Frysinger vapier@gentoo.org --- dlls/shell32/pidl.h | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/dlls/shell32/pidl.h b/dlls/shell32/pidl.h index 3dbfaa6..bbfacef 100644 --- a/dlls/shell32/pidl.h +++ b/dlls/shell32/pidl.h @@ -172,12 +172,12 @@ typedef struct tagPIDLDATA struct tagFileStruct file; struct { WORD dummy; /*01*/ - CHAR szNames[1]; /*03*/ + CHAR szNames[]; /*03*/ } network; struct { WORD dummy; /*01*/ DWORD dummy1; /*02*/ - CHAR szName[1]; /*06*/ /* terminated by 0x00 0x00 */ + CHAR szName[]; /*06*/ /* terminated by 0x00 0x00 */ } htmlhelp; struct tagPIDLCPanelStruct cpanel; struct tagValueW valueW;
On 14 September 2010 15:44, Mike Frysinger vapier@gentoo.org wrote:
note: i couldnt find a statement of what C standard wine aims for. if it is attempting pre-c99, then this will have to be done differently. perhaps introducing a project-wide define like "VARARRAY" which expands into [] for c99+ and [1] for older ...
Roughly C89, C99 features are generally out.
On 15 September 2010 12:22, Henri Verbeet hverbeet@gmail.com wrote:
On 14 September 2010 15:44, Mike Frysinger vapier@gentoo.org wrote:
note: i couldnt find a statement of what C standard wine aims for. if it is attempting pre-c99, then this will have to be done differently. perhaps introducing a project-wide define like "VARARRAY" which expands into [] for c99+ and [1] for older ...
Roughly C89, C99 features are generally out.
Also, patches should go to wine-patches@winehq.org, unless you're asking for review / comments.
Henri Verbeet wrote:
On 14 September 2010 15:44, Mike Frysinger vapier@gentoo.org wrote:
note: i couldnt find a statement of what C standard wine aims for. if it is attempting pre-c99, then this will have to be done differently. perhaps introducing a project-wide define like "VARARRAY" which expands into [] for c99+ and [1] for older ...
Roughly C89, C99 features are generally out.
Hi,
In the wine wiki it is stated that "Wine adheres to standard C89/C90."
http://wiki.winehq.org/SubmittingPatches#head-7a578af49f1d1ab7f36f4b1f98b754...
Marko