[Xcb] xinput: make ListInputDevices work, sumof with nested expr, ...

[Christian Linhart]

On 10/14/14 14:18, Ran Benita wrote:
> On Mon, Oct 13, 2014 at 11:59:20AM +0200, Christian Linhart wrote:
[...]
>> Here's an example:
>> The sumof-code is between the comments /* sumof start */ and /* sumof end. Result is in xcb_pre_tmp_7 */.
>>
>> ====================
>> xcb_input_list_input_devices_infos_length (const xcb_input_list_input_devices_reply_t *R  /**< */)
>> {
>>     int xcb_pre_tmp_5; /* sumof length */
>>     int xcb_pre_tmp_6; /* sumof loop counter */
>>     int64_t xcb_pre_tmp_7; /* sumof sum */
>>     const xcb_input_device_info_t* xcb_pre_tmp_8; /* sumof list ptr */
>>     /* sumof start */
>>     xcb_pre_tmp_5 = R->devices_len;
>>     xcb_pre_tmp_7 = 0;
>>     xcb_pre_tmp_8 = xcb_input_list_input_devices_devices(R);
>>     for (xcb_pre_tmp_6 = 0; xcb_pre_tmp_6 < xcb_pre_tmp_5; xcb_pre_tmp_6++) {
>>         xcb_pre_tmp_7 += xcb_pre_tmp_8->num_class_info;
>>         xcb_pre_tmp_8++;
>>     }
>>     /* sumof end. Result is in xcb_pre_tmp_7 */
>>     return xcb_pre_tmp_7;
>> }
>> ====================
>>
>> So, the non-polymorphicness of function xcb_sumof is not an issue because this function is not used anymore.
>> (but kept in there for compatibility reasons, for the case that some user-code uses it directly somewhere...)
> 
> Yes, this looks like the sanest (only?) way to handle this in C.
I thought a while about how to do it before I made this implementation.
This way is probably one of the most straightforward ways in C because there are no lambda expressions and templates in C.

When GNU-compiler extensions were allowed, then it could also be generated as a code block inside an expression
which will result in simpler code: This is by using  ({ statements; expr }) in an expression, possibly
generated by a macro. 
Unfortunately, this construct is still not included in the latest official C standard,
even though it is probably quite easy to implement in a compiler.

But we probably should stick to official standards.

> 
> Re. compatability, not sure if xcbext.h is considered API, but probably
> not a bad idea to keep it as it's very small.
Yes, I agree to keep the function "xcb_sumof", even if we won't use it anymore after this patchset.
Since it is probably available as a shared-lib symbol it'll probably be used somewhere
given the huge code-base using XCB.

> 
[... obsolete structs due to switch-case...]
>> So I suggest the following procedure:
>> * drop patches "proto 6/7" and "proto 7/7" now
>> 	(I'll update my patch-repo accordingly. I'll send another message when that repo is updated. )
> 
> Yes, that will be the safe thing to do. Probably nobody's using them,
> especially if the request is broken. But we had some issues with xkb in
> the past..
...so it's better to keep these structs to avoid similar issues.

> 
>> * after all my of patches are merged:
>> 	mark all obsolete structs as deprecated:
>> 	- with a comment?
>> 	- or with a xml-attribute that is translated to some comment in the C-code,
>> 	  and possibly with some macro that expands to "__declspec( deprecated )" or "__attribute__(deprecated)" 
>> 	  depending on the compiler used.
>>
>> What do you think?
> 
> Both sound OK to me. 
OK.
I think that an xml-attribute is better than just a comment because
it can be processed automatically. 

This is one of the things we can do after all of the pending 
patches are merged.
I have written it on my TODO-list so we don't forget it.

> They can also be changed to typedefs maybe.
I do not think that they can be changed to typedefs
because there are no equivalent structs which they could be typedefed to.

Actually, in most of the cases, the first few fields of such a struct
are generic, and therefore end up before the switch. 
The rest becomes a case-branch of the switch.

Chris

P.S.: Sorry for the long delay of my answer.
I am catching up with my email backlog 
now that I have finished some time-critical work.


> 
> Ran
> 
>> Chris
>>
>> _______________________________________________
>> Xcb mailing list
>> Xcb at lists.freedesktop.org
>> http://lists.freedesktop.org/mailman/listinfo/xcb
>