Changing wl_output.transform type to unsigned?

[Jonas Ådahl]

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" <nilschrbrause at gmail.com> wrote:
> 
> > On Sun, Nov 15, 2015 at 9:48 PM, Auke Booij <auke at tulcod.com> wrote:
> > > On 9 November 2015 at 18:17, Bill Spitzak <spitzak at 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 at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel