[PythonLabs] Re: [Spread-users] BUFFER_TOO_SHORT && endian_mismatch >= 0

[Tim Peters]

[Jonathan Stanton]
> Yes. From the code, in the DROP_RECV case we do not pass on any info
> aobut how big the buffers needed to be (cause the data is already
> dropped and historically we didn't provide it) so in that case
> endian_mismatch only means what it says (is there an endian mismatch or
> not) so it should only be 0 or 1 in those cases.

That makes good sense (well, for the DROP_RECV case <wink>).

> ...
> So the documentation definitely needs to clarify that service_type is an
> in/out parameter.

Reading them again, I have a hard time claiming that the docs are really
unclear about this.  For *some* reason, though, three good programmers here
stared at this code multiple times and shared a blind spot about this.  I
expect it would help if the

     Service_type is a pointer to a variable of type 'service' which will
     be set to the message type of the message just received.  This
     will be either a REG_MESSAGE or MEMBERSHIP_MESS, and the specific
     type.

part of the man page added something like

     Caution:  service_type is also an input parameter.  Set it to 0
     before calling unless you want DROP_RECV behavior (see below).

Hmm.  I also note that:

+ flooder.c's first call to SP_receive() passes stack trash in
  service_type too.  If there are subsequent calls to the first instance
  of SP_receive() in the do ... while loop, they end up passing whatever
  the last call wrote *into* service_type.

+ simple_user.c's Read_message() also passes stack trash to SP_receive().

+ Also the first call to SP_receive() in user.c's Read_message().

So every function calling SP_receive() in the Spread source distribution
also suffers this blind spot.  I'm not sure whether our error was a "monkey
see monkey do" repetition, or simply that we were *so* not interested in
getting DROP_RECV behavior that we just glossed over all the docs talking
about it.  Likely some of each.

> DROP_RECV is definitely not what you want to be suprised by!

If you need anyone to testify to that in court, I'm your man <wink>.