<div dir="ltr">Changing C int to C uint is ok for Java. Java only knows signed ints anyway, I therefore already map C uint to Java int, which is ok as long as no arithmetic is needed.</div><div class="gmail_extra"> <div class="gmail_quote">On Mon, Nov 16, 2015 at 11:46 AM, Pekka Paalanen <<a href="mailto:ppaalanen@gmail.com" target="_blank">ppaalanen@gmail.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Sun, 15 Nov 2015 22:17:38 +0100 "Nils Chr. Brause" <<a href="mailto:nilschrbrause@gmail.com">nilschrbrause@gmail.com</a>> wrote: > On Sun, Nov 15, 2015 at 9:48 PM, Auke Booij <<a href="mailto:auke@tulcod.com">auke@tulcod.com</a>> wrote: > > On 9 November 2015 at 18:17, Bill Spitzak <<a href="mailto:spitzak@gmail.com">spitzak@gmail.com</a>> wrote: > >> I really do not see the problem with allowing it to be an int argument as > >> long as the enum value 2^31 is not used. Though I am also stumped as to why > >> you can't change the current misused ints into uint in the protocol. It will > >> not change the bit layout in the messages and therefore is not a protocol > >> change. > > > > I don't really know what to do with this final claim. I like the idea, > > and it makes sense. Finally, it will solve this issue and potentially > > future ones as well. Is there any chance it could be implemented or is > > it a crazy idea? > > Bill is absolutely right. And it also doesn't even really change the C API, > because nobody is passing negetive numbers or number greater than 2^31-1 > there anyway. Therefore, I am all for a change. :) Hi, your logic seems sound at first. The things we would need to change in the protocol are: - wl_surface.set_buffer_transform - wl_output.geometry - (possible third party extensions) It would break existing bindings for strongly typed languages that do not allow implicit conversion between signed and unsigned. (Does Java fall into that category?) You don't see any change on the wire, but changing the type changes the C API, which then changes types of variables used in C programs. I can't imagine this having an impact in this particular case, though. Weston seems to use mostly 'enum wl_buffer_transform' as the type, but struct weston_buffer_viewport already uses uint32_t. Ok, I suppose we could try this. The next step would be for someone to propose a patch to change the ints to uints in wayland.xml. Special attention should be given to the commit message: why change this, what benefits it gives, and even though it is breaking the protocol, why it cannot break anything in practice. It is important to write a good commit message, because I expect people to be looking at it a lot, since it is changing stable interfaces. We'll see how that patch is received. If anyone complains it breaks their thing, I think we have to revert it, because it is technically breaking the stability rules. Thanks, pq _______________________________________________ wayland-devel mailing list <a href="mailto:wayland-devel@lists.freedesktop.org">wayland-devel@lists.freedesktop.org</a> <a href="http://lists.freedesktop.org/mailman/listinfo/wayland-devel" rel="noreferrer" target="_blank">http://lists.freedesktop.org/mailman/listinfo/wayland-devel</a> </blockquote></div> </div>