On Tuesday, September 21, 2010 03:34:33 Reece Dunn wrote:
On 20 September 2010 17:51, Mike Frysinger vap...@gentoo.org wrote:
well, i dont think this issue is limited to shell32. it's just the only
one to hit it atm. what about my other patch i posted ?
On Tuesday, September 21, 2010 04:21:28 Reece Dunn wrote:
On 21 September 2010 08:58, Mike Frysinger wrote:
fortify is only adding security/sanity checks to functions. so if you
do: char f[1];
strcpy(f, 1234);
the C library, with help from the compiler, will then perform constant
On 09/21/2010 03:43 AM, Marcus Meissner wrote:
No, its just that the structure is embedded in another structure and gcc 4.5
only looks at the size of the inner structure for these variable array, and
so does not see it is large enough allocated.
(It is kinda in a gray area, but I am tending
Mike Frysinger vap...@gentoo.org writes:
On Sunday, September 19, 2010 17:17:53 Alexandre Julliard wrote:
Mike Frysinger writes:
i dont see how that would help. the code is currently:
typedef struct ... {
...
CHAR foo[1];
} ...;
it needs to be foo[]. ANYSIZE_ARRAY
Hi,
Alexandre Julliard wrote:
it needs to be foo[]. ANYSIZE_ARRAY is defined as 1
True, you don't want to change the public one, but you can define a
shell32-specific version of it. At least then it looks like a normal
array declaration.
Thank you for pointing to ANYSIZE_ARRAY.
Why not cope
Mike Frysinger vap...@gentoo.org writes:
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
On Sunday, September 19, 2010 08:58:42 Alexandre Julliard wrote:
Mike Frysinger writes:
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
On 9/19/10 11:53 AM, Mike Frysinger wrote:
On Sunday, September 19, 2010 08:58:42 Alexandre Julliard wrote:
Mike Frysinger writes:
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
Mike Frysinger vap...@gentoo.org writes:
i dont see how that would help. the code is currently:
typedef struct ... {
...
CHAR foo[1];
} ...;
it needs to be foo[]. ANYSIZE_ARRAY is defined as 1, so once the
preprocessor is done, we're right back where we started. i cant
On Sunday, September 19, 2010 17:17:53 Alexandre Julliard wrote:
Mike Frysinger writes:
i dont see how that would help. the code is currently:
typedef struct ... {
...
CHAR foo[1];
} ...;
it needs to be foo[]. ANYSIZE_ARRAY is defined as 1, so once the
On 15 September 2010 12:22, Henri Verbeet hverb...@gmail.com wrote:
On 14 September 2010 15:44, Mike Frysinger vap...@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.
Henri Verbeet wrote:
On 14 September 2010 15:44, Mike Frysinger vap...@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
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
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
14 matches
Mail list logo
