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

[Jonathan Stanton]

On Thu, Jul 04, 2002 at 12:39:38AM -0400, Tim Peters wrote:
> [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.

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 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.

So the documentation definitely needs to clarify that service_type is an
in/out parameter. DROP_RECV is definitely not what you want to be 
suprised by!

> 
> Thanks again for the help!

Sure. Glad you figured it out. Have a Happy 4th of July.

Jonathan

-- 
-------------------------------------------------------
Jonathan R. Stanton         jonathan at cs.jhu.edu
Dept. of Computer Science   
Johns Hopkins University    
-------------------------------------------------------