Re: Clear padding in the buffer due to alignment.

[Dmitry Timoshkov]

"Robert Shearman" <rob(a)codeweavers.com> wrote:
> This isn't done in MIDL, but I think it's desirable both for silencing 
> Valgrind warnings and for security purposes (fixes potential for leaking 
> information to remote computers or other processes).
> +    print_file(file, indent, "memset(_StubMsg.Buffer, 0, ((long)_StubMsg.Buffer) & 0x%x);\n", alignment - 1);

Is it possible to make it 64-bit and Wine/Windows compatible by using
ULONG_PTR instead of long?

-- 
Dmitry.

Clear padding in the buffer due to alignment.

[Robert Shearman]

Dmitry Timoshkov wrote:
> "Robert Shearman" <rob(a)codeweavers.com> wrote:
> > This isn't done in MIDL, but I think it's desirable both for 
> > silencing Valgrind warnings and for security purposes (fixes 
> > potential for leaking information to remote computers or other 
> > processes).
> > +    print_file(file, indent, "memset(_StubMsg.Buffer, 0, 
> > ((long)_StubMsg.Buffer) & 0x%x);\n", alignment - 1);
>
> Is it possible to make it 64-bit and Wine/Windows compatible by using
> ULONG_PTR instead of long?

At the moment, widl doesn't support generating 64-bit compatible client, 
server and proxy code so doing so would be useless. FWIW, MIDL outputs 
__int64 here instead of long when targeting 64-bit.

Getting support for the Microsoft 64-bit calling convention into 
upstream gcc is the most important requirement for a 64-bit Wine.

-- 
Rob Shearman

Clear padding in the buffer due to alignment.

[Dmitry Timoshkov]

"Robert Shearman" <rob(a)codeweavers.com> wrote:
> > Is it possible to make it 64-bit and Wine/Windows compatible by using
> > ULONG_PTR instead of long?
>
> At the moment, widl doesn't support generating 64-bit compatible client, 
> server and proxy code so doing so would be useless. FWIW, MIDL outputs 
> __int64 here instead of long when targeting 64-bit.

If it doesn't take too much effort to write a 64-bit clean code, why avoid
that, especially all that's required is using an appropriate cast?
> Getting support for the Microsoft 64-bit calling convention into 
> upstream gcc is the most important requirement for a 64-bit Wine.

That's a completely different problem, but we still should be able to build
a working 64-bit Wine without binary win64 support.

-- 
Dmitry.

Clear padding in the buffer due to alignment.

[Robert Shearman]

Dmitry Timoshkov wrote:
> "Robert Shearman" <rob(a)codeweavers.com> wrote:
> > > Is it possible to make it 64-bit and Wine/Windows compatible by using
> > > ULONG_PTR instead of long?
> >
> > At the moment, widl doesn't support generating 64-bit compatible 
> > client, server and proxy code so doing so would be useless. FWIW, 
> > MIDL outputs __int64 here instead of long when targeting 64-bit.
>
> If it doesn't take too much effort to write a 64-bit clean code, why 
> avoid
> that, especially all that's required is using an appropriate cast?

1. Both of these lines are correct using Unix compilers since long is 
64-bit when pointers are 64-bit:
    print_file(file, indent, "memset(_StubMsg.Buffer, 0, 
((long)_StubMsg.Buffer) & 0x%x);\n", alignment - 1);
    print_file(file, indent, "_StubMsg.Buffer = (unsigned char 
*)(((long)_StubMsg.Buffer + %u) & ~0x%x);\n",
                alignment - 1, alignment - 1);

2. It's independent of my patch (even if long is 32-bits, we're not 
going to have alignments above 4Gb).
3. Supporting 64-bit pointers in widl is a lot more complicated than 
just casting using the correct type (it involves making anything with 
embedded pointers into a complex type).

-- 
Rob Shearman