reg.exe platform specific test?

[Jonathan Vollebregt]

In the reg.exe tests around line 181:
> verify_reg(hkey, "dword8", REG_DWORD, &dword, sizeof(dword),
>            (sizeof(long) > sizeof(DWORD)) ? 0 : TODO_REG_DATA);

What's the reason for this? Is there some platform specific quirk I 
should be aware of?

[Stefan Dösinger]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am 2014-10-17 17:45, schrieb Jonathan Vollebregt:
> In the reg.exe tests around line 181:
> > verify_reg(hkey, "dword8", REG_DWORD, &dword, sizeof(dword), 
> > (sizeof(long) > sizeof(DWORD)) ? 0 : TODO_REG_DATA);
>
> What's the reason for this? Is there some platform specific quirk
> I should be aware of?

Smells like 32 bit vs 64 bit to me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJUQTqTAAoJEN0/YqbEcdMwhLoP/Rw1J1KkVDBH8y1XsasuUk0D
2WItNi+co6QBVTprkntSu+TVYW2V1/bhUykYecEYd7em5NHikDy6mpRu7FLwxr6z
k6liFUrYSQONfNpLJx/sMo+/wGqc8bWEK0036wnwbAZHpKtQXUKgBdsUCtxgFHsJ
ZribyDSGRC4LO0NMI/MUM1maqvBQ/gs2pCYzSmHAoVEnY+ZAMns1VIGCX6UzU2PA
MXvS3A2oHRUTx+8JMScvmTV/uRvZgw7u28F0wbQikenCb5oT5MbGROEkR83hWzIW
KgJg5bsnCg2qvXAlWPjryBdz6aOfKkcKjqPaEzYb+JeH4MK8kskyJMtrAIT6IZVi
JV8229yYZOY9FdLh4QEojNCxSLrTzbPxdq2CAkOg+XXcBRytuD/jc5IWAW9PVWny
a23EC2EJ/Bky5ueqbGXnP5SxtlzBObPwrIs8Q23i+e/r2WwhWyyNym+tAdci8lbD
1QBDjda+u1S7z7//255LxWl2W6CLXj/FCGSjiMo9lwJVgdnVsqgxUXDUd/zUe60l
zI5zKlEZfqpV5ijsxvgR11YRlWaRNAeHcRHiwlT1rrrn31CODydSRs2A7tWxperB
zBFiGsc6l0g6x5j6n0MwjP0M4CVT0846M8PpjO6U+RbWE6fSGdEGprVbAdw/UBcx
SW9YS1A48uGhnlRbDmTC
=1FiP
-----END PGP SIGNATURE-----

[Henri Verbeet]

On 17 October 2014 17:49, Stefan Dösinger  wrote:
> Am 2014-10-17 17:45, schrieb Jonathan Vollebregt:
> > In the reg.exe tests around line 181:
> > > verify_reg(hkey, "dword8", REG_DWORD, &dword, sizeof(dword),
> > > (sizeof(long) > sizeof(DWORD)) ? 0 : TODO_REG_DATA);
> >
> > What's the reason for this? Is there some platform specific quirk
> > I should be aware of?
>
> Smells like 32 bit vs 64 bit to me.

But this specific instance is a bit nasty, since on 64-bit Windows
compilers sizeof(long) == sizeof(DWORD). I suspect that's
unintentional and this really wanted to use e.g. sizeof(void *), even
though it shouldn't matter in practice because the TODO_REG_DATA flag
should only make a difference on Wine.

[Akihiro Sagawa]

On Fri, 17 Oct 2014 17:45:52 +0200, Jonathan Vollebregt wrote:
> In the reg.exe tests around line 181:
> > verify_reg(hkey, "dword8", REG_DWORD, &dword, sizeof(dword),
> >            (sizeof(long) > sizeof(DWORD)) ? 0 : TODO_REG_DATA);
>
> What's the reason for this? Is there some platform specific quirk I should be aware of?

The reason is that reg.c REG_DWORD handling code uses strtolW() for
string conversion[1]. If the value greater than LONG_MAX, strtolW()
returns LONG_MAX, so this test doesn't pass if sizeof(long) == 4.

I'm not sure all wine platform use LP64 architecture then, so I
introduce above quirks. In retrospect, 0xdeadbeefU < LONG_MAX is
easier to read, I think.

[1] http://source.winehq.org/source/programs/reg/reg.c#0145

Regards,
Akihiro Sagawa

[Jonathan Vollebregt]

I thought there was a long somewhere but I couldn't figure out where. I 
also had no idea why I had to change it to 0 in my tests but knowing 
that it's obvious: I use strtoulW.

A new set of reg patches including binary/big_endian/expand/multi tests 
will be coming as soon as testbot gives me the all clear.

On 10/17/2014 08:01 PM, Akihiro Sagawa wrote:
> On Fri, 17 Oct 2014 17:45:52 +0200, Jonathan Vollebregt wrote:
> > In the reg.exe tests around line 181:
> > >  verify_reg(hkey, "dword8", REG_DWORD, &dword, sizeof(dword),
> > >             (sizeof(long) > sizeof(DWORD)) ? 0 : TODO_REG_DATA);
> >
> > What's the reason for this? Is there some platform specific quirk I should be aware of?
>
> The reason is that reg.c REG_DWORD handling code uses strtolW() for
> string conversion[1]. If the value greater than LONG_MAX, strtolW()
> returns LONG_MAX, so this test doesn't pass if sizeof(long) == 4.
>
> I'm not sure all wine platform use LP64 architecture then, so I
> introduce above quirks. In retrospect, 0xdeadbeefU < LONG_MAX is
> easier to read, I think.
>
> [1] http://source.winehq.org/source/programs/reg/reg.c#0145
>
> Regards,
> Akihiro Sagawa