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 <ppaala...@gmail.com> 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,
>
> 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
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
