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

[Tim Peters]

[Tim]
> In that case (DROP_RECV specified unwittingly, and buffer is too
> short, and BUFFER_TOO_SHORT returned), would endian_mismatch still
> contain the negation of the buffer size needed had DROP_RECV not been
> specified?  Or might it contain a value >= 0 then?

I can answer that:  The returned value of endian_mismatch can be
non-negative in this case.

I changed our Spread wrapper to initialize service_type to DROP_RECV instead
of leaving it as uninitialized stack trash.  Our standard "send a message
too big for the default buffer" wrapper test then triggered here:

		if (size == BUFFER_TOO_SHORT) {
			if (endian >= 0) {
				printf("aieeeeeeee %d\n", endian);
				goto set_error;
			}

It printed

    aieeeeeeee 0

That may or may not be intended behavior, but I expect that almost certainly
explains what our user saw.  Seeing as

#define         DROP_RECV               0x01000000

in sp.h, it's unlikely that stack trash would have the DROP_RECV bit set by
accident -- but sooner or later certain to happen.

Thanks again for the help!