On Mon, Nov 16, 2015 at 12:46:21PM +0200, Pekka Paalanen wrote: > On Sun, 15 Nov 2015 22:17:38 +0100 > "Nils Chr. Brause" <nilschrbra...@gmail.com> wrote: > > > On Sun, Nov 15, 2015 at 9:48 PM, Auke Booij <a...@tulcod.com> wrote: > > > On 9 November 2015 at 18:17, Bill Spitzak <spit...@gmail.com> 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.
The most obvious thing that would "break" is that every client or server C implementation will suddenly get new compiler warnings and to be able to build both the version before and after the change without warnings, they'd need #if #else #fi macros around every such place. This is primarily an annoyance anyhow since the warning is mostly harmless. Jonas > > > Thanks, > pq > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
