From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2008-08-18 12:41:19
Phil Endecott wrote:
> Andrey Semashev wrote:
>> Phil Endecott wrote:
>>> Andrey Semashev wrote:
>>>> IMO, undefined behavior usually is a design flaw, and this case is
>>>> clearly one of the "usual" ones. Otherwise, like I said, you don't need
>>>> FSM, because its whole purpose is to _define_ the behavior.
>>> I disagree. If I have a guarantee of how the environment will behave it
>>> is unnecessary to check it, except perhaps in some sort of debug mode.
>> Agreed. But in such a case, do you need an FSM in the first place? If
>> you have the guarantee that function A will always be called before
>> function B, you will simply rely on it and assume that while in B, A has
>> already been called.
> An environment that makes guarantees about how it will or will not
> behave is not generally a completely deterministic environment.
> Example: say I'm receiving UTF-8, and I'm guaranteed by the sender that
> it's valid UTF-8. I still need to track the state of the stream as I
> process the bytes, even though I'm going to allow undefined behaviour
> (either in the C++ language sense, or in some other sense) if those
> bytes are invalid. This particular problem could certainly be usefully
> expressed using an FSM.
Agreed. I admit, I didn't think about it.