Type safety of protocol calls

[Chris Morgan]

On Sunday, February 6, 2011, Kristian Høgsberg <krh at bitplanet.net> wrote:
> On Sun, Feb 6, 2011 at 11:57 AM, Chris Morgan <chmorgan at gmail.com> 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