Re: Bad change in counted array protocol?

[Larry Dickson <tjoccam@xxxxxxxxxxx>]

Hello David and all,

I saw 19.4 and did not mention it because it led to the same conclusion as 19.2, and is subject to the same objections.

Disallowing a variable length to the buffer (based on len) conflicts with the rationale of the counted array protocol. Its purpose is to allow real time determination of the length of a data transmission. The length of the receiving buffer is the maximum allowed, but any size of transmission smaller than that can be allowed, which is very convenient for system-type IO and for IO of long data array sequences (like the output of a compression algorithm) that have a final member of unpredictable length.

The idea that the size of buffer has to be known ahead of time, which is what both 19.2 and 19.4 imply, requires a special transmission of len before the counted array. In other words, len must be transmitted twice. That seems to vitiate the whole point of a counted array protocol.

Larry

On Dec 6, 2018, at 3:55 PM, David May <david.may@xxxxxxxxxxxxx> wrote:

> Hi all,
> 
> The rationale (19.2) is not correct. 
> 
> The issue is whether the assignment to len and the assignment to the buffer 
> are performed sequentially - or not. 
> 
> This is set out in 19.4.
> 
> David
> 
> 
>> 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
>