[PATCH xf86-input-synaptics 07/10] Add touch valuator mask to hw state structure

[Chase Douglas]

On 02/10/2012 08:58 AM, Peter Hutterer wrote:
> On Thu, Feb 09, 2012 at 06:22:27PM +0100, Chase Douglas wrote:
>> On 02/09/2012 03:27 PM, Peter Hutterer wrote:
>>> On Wed, Feb 08, 2012 at 06:35:16PM -0800, Chase Douglas wrote:
>>>> Signed-off-by: Chase Douglas <chase.douglas at canonical.com>
>>>> ---
>>>>  src/synaptics.c    |   78 ++++++++++++++++++++++++++++++++++++++++++++++++++-
>>>>  src/synapticsstr.h |    1 +
>>>>  src/synproto.h     |    5 +++
>>>>  3 files changed, 82 insertions(+), 2 deletions(-)
>>>>
>>>> diff --git a/src/synaptics.c b/src/synaptics.c
>>>> index c0398fb..b01be59 100644
>>>> --- a/src/synaptics.c
>>>> +++ b/src/synaptics.c
>>>> @@ -1151,6 +1151,8 @@ DeviceInit(DeviceIntPtr dev)
>>>>  #ifdef HAVE_MULTITOUCH
>>>>      if (priv->has_touch)
>>>>      {
>>>> +        priv->num_slots = priv->max_touches ? : 10;
>>>
>>> whoah, didn't know that was legal. is this gcc or std C?
>>> either way, I'd rather not do that because of this behaviour:
>>>
>>>     int a = 12;
>>>     a = (a > 10) ? : 10;
>>>     → a is now 1
>>>     
>>> Not quite what one would expect.
>>
>> I think it is standard C. It's not seen too often because many times
>> you're checking a value against something non-zero. A better example of
>> how not to do it is:
>>
>> a = (b > 0) ? : 10;
>>
>> I don't see any reason why what I have is bad, but I'll change it if it
>> makes you cringe. People writing C need to know what they are doing, and
>> this isn't one of those areas where what really happens is different
>> than what one might think.
> 
> sorry, my fault. played around with it a bit more, that operator just worked
> differently to what I expected, hence the confusion. leave it in (once we
> know whether it's a gcc extension or not).

Well, I'm not very satisfied with what I've found, but here it is:

The draft ANSI C89 specification is here:
https://docs.google.com/viewer?a=v&pid=explorer&chrome=true&srcid=0BxVCLS4f8Sg5NWZmM2NjZWEtYmExMS00Y2EzLWE3ZTMtNzFmYjYwYzBiOTIw&hl=en_US.
I don't know how to find the ratified spec, but this is probably good
enough. It says in section 3.3.15:

"The syntactic restrictions on the middle operand of the conditional
operator have been relaxed to include more than just
logical-OR-expression: several extant implementations have adopted this
practice."

It mentions stuff about unions, structs, and pointers after this, but
they aren't germane to this discussion. I'm annoyed because this really
doesn't say anything, and what it does is so obtuse that I can't make it
out. Maybe it describes exactly what I wrote, but I'm not sure. It also
seems to assume that the full definition of the conditional operator is
defined elsewhere.

ANSI C89 is the first standard for C AFAICT. However, let's assume that
everyone was working off the Kernighan and Ritchie "standard" as
published in their book. I have one version open in front of me. In
section A.7.16 it says:

"""

conditional-expression:
logical-OR-expression
logical-OR-expression ? expression : conditional-expression

The first expression is evaluated, including all side effects; if it
compares unequal to 0, the  result is the value of the second
expression, otherwise that of the third expression. Only one of  the
second and third operands is evaluated. If the second and third operands
are arithmetic, the  usual arithmetic conversions are performed to bring
them to a common type, and that type is  the type of the result. If both
are void, or structures or unions of the same type, or pointers to
objects of the same type, the result has the common type. If one is a
pointer and the other the  constant 0, the 0 is converted to the pointer
type, and the result has that type. If one is a  pointer to void and the
other is another pointer, the other pointer is converted to a pointer to
 void, and that is the type of the result

"""

No where does it say that the middle expression is optional or what
would happen if left out.

I'm inclined to believe that leaving the middle expression out isn't
codified anywhere, but is likely to be interpreted correctly by any sane
compiler. However, that's a just an assumption and can't be verified.
Since I haven't found proof that it's ok, and I've already changed it in
v2, I'll just leave it as-is.

-- Chase