Changing wl_output.transform type to unsigned?

[Jonas Ådahl]

On Tue, Nov 24, 2015 at 01:41:03PM +0100, Nils Chr. Brause wrote:
> On Mon, Nov 16, 2015 at 11:46 AM, Pekka Paalanen <ppaalanen at gmail.com> 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,
> 
> Hi,
> 
> sorry I was not answering in a while.
> 
> > 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?)
> 
> Strongly typed bindings would use special types for enumerations/bitfields
> anyway, so this probably isn't a problem.
> 
> > 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.
> 
> The changes in the C API  doesn't even produce any warings. Take a look
> at the following:
> 
> #include <stdint.h>
> int foo(uint32_t c)
> {
>   return c;
> }
> int main()
> {
>   int32_t bar = 7;
>   return foo(bar);
> }
> 
> It compiles without any warings, even with -Wall. Tested an all available C
> and C++ Standards with GCC 5.2.

I tested making the change to wayland.xml and it did result in new
warnings.  Maybe not att call sites, but when assigning function
pointers, i.e. the vfunc table passed to wl_resource_set_implementation.
Again, the warnings are harmless, but definitely there.


Jonas