For what it's worth,
On 21 January 2017 at 16:25, Gerald Pfeifer gerald@pfeifer.com wrote:
I am wondering about the following piece of code in server/thread.c:
int is_cpu_supported( enum cpu_type cpu ) { unsigned int prefix_cpu_mask = get_prefix_cpu_mask();
if (CPU_FLAG(cpu) && (supported_cpus & prefix_cpu_mask & CPU_FLAG(cpu))) return 1;
that was added as part of
commit 1e78c99388c61d353cf60787eac6415328f54560 Author: Alexandre Julliard julliard@winehq.org Date: Fri Nov 22 12:32:48 2013 +0100
kernel32: Validate the architecture of newly created processes on the server side.
It's actually older than that, and seems to have been introduced by
commit 279defe66e1265eeae3e2a72126c2b2f75e20c99 Author: Alexandre Julliard julliard@winehq.org Date: Fri Apr 3 14:59:12 2009 +0200
server: Verify that the client is using a supported CPU type.
That means CPU_FLAG(...) is always positive and different from zero -- unless its parameter is 32 or higher on a 32-bit architecture (and the 1 shifts out).
But the definition of CPU_FLAG doesn't really matter for this. If "CPU_FLAG(cpu)" evaluates to zero, "supported_cpus & prefix_cpu_mask & CPU_FLAG(cpu)" evaluates to zero as well.
Henri Verbeet hverbeet@gmail.com writes:
For what it's worth,
On 21 January 2017 at 16:25, Gerald Pfeifer gerald@pfeifer.com wrote:
I am wondering about the following piece of code in server/thread.c:
int is_cpu_supported( enum cpu_type cpu ) { unsigned int prefix_cpu_mask = get_prefix_cpu_mask();
if (CPU_FLAG(cpu) && (supported_cpus & prefix_cpu_mask & CPU_FLAG(cpu))) return 1;
that was added as part of
commit 1e78c99388c61d353cf60787eac6415328f54560 Author: Alexandre Julliard julliard@winehq.org Date: Fri Nov 22 12:32:48 2013 +0100
kernel32: Validate the architecture of newly created processes on the server side.
It's actually older than that, and seems to have been introduced by
commit 279defe66e1265eeae3e2a72126c2b2f75e20c99 Author: Alexandre Julliard julliard@winehq.org Date: Fri Apr 3 14:59:12 2009 +0200
server: Verify that the client is using a supported CPU type.
That means CPU_FLAG(...) is always positive and different from zero -- unless its parameter is 32 or higher on a 32-bit architecture (and the 1 shifts out).
But the definition of CPU_FLAG doesn't really matter for this. If "CPU_FLAG(cpu)" evaluates to zero, "supported_cpus & prefix_cpu_mask & CPU_FLAG(cpu)" evaluates to zero as well.
Yes, it's clearly redundant. I seem to remember there was a need to avoid a compiler warning, but that may have been from a previous version that didn't use a shift.