* On Fri, 6 Oct 2006, Alexandre Julliard wrote:
> * Saulius Krasuckas <[EMAIL PROTECTED]> writes:
> > That was the reason I kept the check in. It doesn't enforce
> > unnecessary complexity in the function, so I doubt the check is wrong.
> > Especially given that this fn on both platforms behave
* On Fri, 6 Oct 2006, Vitaliy Margolen wrote:
> * Saulius Krasuckas wrote:
> > Unless Alexandre confirms the requirement directly. In such case I am
> > going to put this stuff into our Wiki ^^ even write a patch for
> > cleaning the calls myself ;)
>
> No wonder people can't get _any_ response
Saulius Krasuckas wrote:
> * On Thu, 5 Oct 2006, Vitaliy Margolen wrote:
> Unless Alexandre confirms the requirement directly. In such case I am
> going to put this stuff into our Wiki ^^ even write a patch for cleaning
> the calls myself ;)
No wonder people can't get _any_ response to their pa
Saulius Krasuckas <[EMAIL PROTECTED]> writes:
> Unless Alexandre confirms the requirement directly. In such case I am
> going to put this stuff into our Wiki ^^ even write a patch for cleaning
> the calls myself ;)
There's no need to enforce 0xdeadbeef, other similar magic values work
just as
* On Thu, 5 Oct 2006, Vitaliy Margolen wrote:
> * Saulius Krasuckas wrote:
> > --- a/dlls/lz32/tests/lzexpand_main.c
> > +++ b/dlls/lz32/tests/lzexpand_main.c
> > @@ -131,6 +131,7 @@ static void test_LZOpenFileA_existing_co
> >memset(&filled_0xA5, 0xA5, OFS_MAXPATHNAME);
> >memset(&test, 0x
Saulius Krasuckas wrote:
> (Headers in this series of patches was slightly edited by hand due to lack
> of internet connection and newer git version. Don't be surprised for
> inconsistencies and just drop if that was the case)
>
> ---
>
> dlls/lz32/tests/lzexpand_main.c | 76
>
