Undefined behavior

[Pekka Paalanen]

On Sat, 16 Aug 2014 09:27:35 -0400
"Jasper St. Pierre" <jstpierre at mecheye.net> wrote:

> It seems people got a bit caught up on the words "undefined behavior" here,
> especially as the very similar "undefined surface contents" appears in
> wl_surface.destroy / wl_surface.release. Let's try this again, with a
> different word.

Ok, let's start anew.

> Any behavior that is not explicitly defined is illegal behavior. A
> perfectly built compositor MUST send protocol errors for illegal behavior,
> but most compositors are not perfectly built, and it is exceedingly
> difficult to enumerate the undefined parts of the spec. Compositors SHOULD
> attempt to send protocol errors for illegal behavior.

To me this sounds like you just want to be sloppy with writing
specifications. Writing specifications *is* hard work.

I know that from experience, and I also know that when you write the
implementation, you will cover a lot more corner-cases when you
think about all the cases where a piece of state may not be what you
assume, and then that causes you to go back to the spec and amend
it. You simply have to cover every theoretical case in the code to
not allow a malfunctioning client to break your compositor, so it
shouldn't be that overwhelming to translate that into the spec
somehow.

I read your definition above as "Any use that is not explicitly
written down in the spec is illegal. You might send/get a protocol
error from it." What does that mean? Would it for instance apply to
the case, where you use wl_viewport on a cursor surface? I see that
as a perfectly valid use case, yet nowhere it is written explicitly
that you can do that. It is only implicit, because wl_viewport can
apply to any wl_surface, and a wl_surface can be a cursor.

What is your goal with this definition? Could you give an explicit
example which you would cover with this generic rule, preferably
something I asked to fix in my review?

Btw. for all the "what happens if..?" questions I had, a valid
answer is to just add a sentence saying "... is illegal." I do
think that must be explicitly written down, but you don't have to
specify what exactly happens when a client does something illegal.
That much slack I can give, as long as your interface definition
also contains at least a catch-all error code you can use in an
implementation.

You can also explicitly define the other way around: "(For this
request to be legal, )... surface's role must be ...". And that
implies that if it is not, it is illegal.

I don't really see the need for the blanket statement here. If
someone violates a MUST, then yeah, it is illegal. Or is this the
only thing you wanted to say with the blanket statement?

> Clients cannot rely on error conditions being the same forever. New
> features and new additions to the protocol may mean that what was illegal
> behavior before is now defined.

That is not so obvious. E.g. if a client never binds to an
interface whose semantics relieve some restrictions, I think those
restrictions should apply if practical in the compositor. The same
with new interface versions.

Furthermore, I think the extension should explicitly define the
things that become legal with the extension. I don't believe we can
avoid new extensions from changing the behaviour of old protocol,
and we already have examples of quite fundamental changes brought
by new a version or an extension.

In the end, I agree it is hard to know what not to specify. But
everything you do not specify, will be implemented and used in
various imaginative ways in the wild, and that makes writing
complatible code and future extensions much much harder.


Thanks,
pq