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 towa
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
On Tuesday, September 21, 2010 03:34:33 Reece Dunn wrote:
> On 20 September 2010 17:51, Mike Frysinger 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 ?
> > http://www.winehq.org/pipermail/wine-patches/2
On Tue, Sep 21, 2010 at 08:34:33AM +0100, Reece Dunn wrote:
> On 20 September 2010 17:51, Mike Frysinger 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 ?
> > http://www.winehq.org/pipermail/wine-patches
On 21 September 2010 08:58, Mike Frysinger wrote:
> On Tuesday, September 21, 2010 03:34:33 Reece Dunn wrote:
>> On 20 September 2010 17:51, Mike Frysinger 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 pos
On 20 September 2010 17:51, Mike Frysinger 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 ?
> http://www.winehq.org/pipermail/wine-patches/2010-September/093377.html
>
How does fortify work?
See http://bl
On Monday, September 20, 2010 06:49:20 Alexandre Julliard wrote:
> Mike Frysinger 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 ... {
> >> >
> >> > ...
>
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
Mike Frysinger 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[]". A
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 on
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
> preprocessor is done, we're right back where we started. i cant change the
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 len
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 mor
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 a
> single byte will trigger:
> In function 'strcpy', inli
Henri Verbeet wrote:
> On 14 September 2010 15:44, Mike Frysinger 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
On 15 September 2010 12:22, Henri Verbeet wrote:
> On 14 September 2010 15:44, Mike Frysinger 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-wi
On 14 September 2010 15:44, Mike Frysinger 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 [
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'
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'
19 matches
Mail list logo
