[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Bad change in counted array protocol?


I took a look in detail at the definition of occam 2.5 in Conor O'Neill's document


and I found this:

19 Counted array input . . . A counted array input of the form

message ? len :: buffer

is no longer permitted to refer to the len as part of the expression buffer.
Note: This is a change from strict occam 2 behavior.

19.2 Rationale

This makes it possible to treat the input at a single input . . .

He makes a concession to previous usage but makes it clear it is vacuous.

This appears to make no sense. If len is an unknown-ahead-of-time value, 
shorter than the target array, then it appears that (a) this opens the door
to buffer overflows, (b) in the "move" type of input, the inputting process
cannot know the size of the move, (c) in a link input, the link will not know
when the transmission is done and therefore will not know when to
reschedule the process.

Did this change get adopted, i.e. put into occam-pi or any other
subsequent version of occam? It appears to destroy the entire purpose of
counted array protocol.

Larry Dickson