Re: Type safety of protocol calls
* Chris Morgan schrieb: > Maybe we could compile the c code as c++? Wouldn't require using > classes etc but would provide better type conversion checking. Actually, I'm currently in process of building several packages with an C++ (instead of C) compiler for analysis and cleanup purposes (eg. it enforced you to write parameter types before the parameter names, and other things I'd consider much cleaner). This approach might turn out as a fine QM tool ... cu -- -- Enrico Weigelt, metux IT service -- http://www.metux.de/ phone: +49 36207 519931 email: weig...@metux.de mobile: +49 151 27565287 icq: 210169427 skype: nekrad666 -- Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme -- ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
On Feb 6, 2011, at 1:22 PM, "Kristian Høgsberg" wrote: > 2011/2/6 Chris Morgan : >> On Sunday, February 6, 2011, Kristian Høgsberg wrote: >>> On Sun, Feb 6, 2011 at 11:57 AM, Chris Morgan wrote: Hello. I ran into an issue figuring out how a resize event made it's way from window.c in the client to shell.c on the server. I think I figured out the mapping and sent a patch that performs the mapping between the two different types being used. >>> >>> I saw the patch, but the window.h #defines are defined to match the >>> protocol enumeration where they overlap for convenience. That's >>> perfectly legal in C, safe and convenient.. You may not like that >>> technique, but claiming that the protocol isn't typesafe for this >>> reason is a little disingenuous. >>> >>> Kristian >>> >> >> Hi. >> >> I thought when a function called for an enum that in c++ a warning or >> error was generated when passing anything other than that enum into >> that function? I thought that was generally considered type safety, >> should I have called it strict type conversion instead? > > You're talking about C++ and C++ type conversion. Wayland is written in C. > > Kristian Maybe we could compile the c code as c++? Wouldn't require using classes etc but would provide better type conversion checking. Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
I am unable to view patches. Yay Droid. EHLL is an Extremely High-Level Language. I was thinking of Python, but a similar technique would be appropriate in other languages, too. Judging from your patch description, it sounds like you wrote code that does The Right Thing, but were hoping that the compiler could do The Right Thing for us in the future. In this case, no, probably not. Sending from a mobile, pardon the brevity. ~ C. On Feb 6, 2011 10:20 AM, "Chris Morgan" wrote: ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
2011/2/6 Chris Morgan : > On Sunday, February 6, 2011, Kristian Høgsberg wrote: >> On Sun, Feb 6, 2011 at 11:57 AM, Chris Morgan wrote: >>> Hello. >>> >>> I ran into an issue figuring out how a resize event made it's way from >>> window.c in the client to shell.c on the server. I think I figured out >>> the mapping and sent a patch that performs the mapping between the two >>> different types being used. >> >> I saw the patch, but the window.h #defines are defined to match the >> protocol enumeration where they overlap for convenience. That's >> perfectly legal in C, safe and convenient.. You may not like that >> technique, but claiming that the protocol isn't typesafe for this >> reason is a little disingenuous. >> >> Kristian >> > > Hi. > > I thought when a function called for an enum that in c++ a warning or > error was generated when passing anything other than that enum into > that function? I thought that was generally considered type safety, > should I have called it strict type conversion instead? You're talking about C++ and C++ type conversion. Wayland is written in C. Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
On Sunday, February 6, 2011, Corbin Simpson wrote: > C++ type safety is still compile-time-only in this case and not necessarily > more bulletproof. Even in EHLLs, I would still take the time to write out > explicit enum mapping code rather than trust the compiler. > Sending from a mobile, pardon the brevity. ~ C. EHLLs? Wouldn't c++ at least force an explcit cast, which is at least somewhat self documenting since you can see the target type? Did you happen to see my patch to explicitly map the two enums or was that not what you meant by mapping? Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
C++ type safety is still compile-time-only in this case and not necessarily more bulletproof. Even in EHLLs, I would still take the time to write out explicit enum mapping code rather than trust the compiler. Sending from a mobile, pardon the brevity. ~ C. On Feb 6, 2011 10:03 AM, "Chris Morgan" wrote: ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
On Sunday, February 6, 2011, Kristian Høgsberg wrote: > On Sun, Feb 6, 2011 at 11:57 AM, Chris Morgan wrote: >> Hello. >> >> I ran into an issue figuring out how a resize event made it's way from >> window.c in the client to shell.c on the server. I think I figured out >> the mapping and sent a patch that performs the mapping between the two >> different types being used. > > I saw the patch, but the window.h #defines are defined to match the > protocol enumeration where they overlap for convenience. That's > perfectly legal in C, safe and convenient.. You may not like that > technique, but claiming that the protocol isn't typesafe for this > reason is a little disingenuous. > > Kristian > Hi. I thought when a function called for an enum that in c++ a warning or error was generated when passing anything other than that enum into that function? I thought that was generally considered type safety, should I have called it strict type conversion instead? I see the utility of mapping the two enums onto each other but I don't think is a good idea. Why not be strict where possible about the values passed through the protocol? What about the risk of someone changing one enum without changing the other? Wouldn't the issue be avoided if the protocol call specified the enum and a c++ compiler were used? If we can lock things down and prevent future errors why not attempt to do so? Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: Type safety of protocol calls
On Sun, Feb 6, 2011 at 11:57 AM, Chris Morgan wrote: > Hello. > > I ran into an issue figuring out how a resize event made it's way from > window.c in the client to shell.c on the server. I think I figured out > the mapping and sent a patch that performs the mapping between the two > different types being used. I saw the patch, but the window.h #defines are defined to match the protocol enumeration where they overlap for convenience. That's perfectly legal in C, safe and convenient.. You may not like that technique, but claiming that the protocol isn't typesafe for this reason is a little disingenuous. Kristian ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Type safety of protocol calls
Hello. I ran into an issue figuring out how a resize event made it's way from window.c in the client to shell.c on the server. I think I figured out the mapping and sent a patch that performs the mapping between the two different types being used. Assuming the protocol methods specified specific types like enum wl_shell_resize vs uint32, is there some way to get gcc to warn about the implicit type conversion? It would be nice to avoid confusion about the desired type for the rpc calls. I know building with c++ would allow this. Any reason we couldn't go that route to tighten up the API? Chris ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
