I’ve passed this on to Conor himself, I happened to see him today. Roger > On 6 Dec 2018, at 15:33, Larry Dickson <tjoccam@xxxxxxxxxxx> wrote: > > All, > > I took a look in detail at the definition of occam 2.5 in Conor O'Neill's document > > http://wotug.org/occam/documentation/oc21small.pdf > > 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 -- Roger Shepherd rog@xxxxxxxx
Attachment:
signature.asc
Description: Message signed with OpenPGP