Subject: lib/1115: xdr_double broken on little-endians
To: None <gnats-admin@sun-lamp.cs.berkeley.edu>
From: der Mouse <mouse@Collatz.McRCIM.McGill.EDU>
List: netbsd-bugs
Date: 06/05/1995 04:20:07
>Number:         1115
>Category:       lib
>Synopsis:       xdr_double broken on little-endians
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    lib-bug-people (Library Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jun  5 04:20:03 1995
>Originator:     der Mouse
>Organization:
	Dis-
>Release:        -current as of May 9th
>Environment:
	Any little-endian architecture using IEEE fp
>Description:
	See Kent Vander Velden <graphix@iastate.edu>'s message to
	current-users, Message-Id:
	<9506050722.AA12708@spiff.cc.iastate.edu>, Subject: XDR and
	double data type, Date: Mon, 05 Jun 1995 02:22:14 CDT.
	Briefly, xdr_double() either mis-encodes or mis-decodes
	doubles.  Reading the code makes me think it's mis-encoding.
>How-To-Repeat:
	(This is taken from the aforementioned letter; untested since I
	have no little-endian NetBSD machine.)

	#include <stdio.h>
	#include <stdlib.h>
	#include <rpc/types.h>
	#include <rpc/xdr.h>
	
	int
	main(void) {
	  double x=3.14159;
	  double y=0.0;
	  char *xdr_buffer=NULL;
	  XDR xdrs;
	  int nbytes=1024; /*sizeof(double);*/
	
	  xdr_buffer = (char*)malloc(nbytes);
	
	  xdrmem_create(&xdrs, xdr_buffer, nbytes, XDR_ENCODE);
	  xdr_double(&xdrs, &x);
	  xdr_destroy(&xdrs);
	
	  xdrmem_create(&xdrs, xdr_buffer, nbytes, XDR_DECODE);
	  xdr_double(&xdrs, &y);
	  xdr_destroy(&xdrs);
	
	  free(xdr_buffer);
	
	  printf("before encoding=%f\nafter encoding=%f\n", x, y);
	
	  return 0;
	}
>Fix:
	In lib/libc/rpc/xdr_float.c (line 233 in the copy I have) there
	is the fragment

		tmpl = *i32p+1;
		rv = XDR_PUTLONG(xdrs, &tmpl);
		if (!rv)
			return (rv);
		tmpl = *i32p;
		rv = XDR_PUTLONG(xdrs, &tmpl);

	From context, and from the parallel code in the XDR_DECODE
	case, it's clear that *i32p+1 should be *(i32p+1), or perhaps
	preferably i32p[1].

	That code appears to have alignment problems too, which I
	intend to investigate more fully and send-pr as appropriate.

					der Mouse

			    mouse@collatz.mcrcim.mcgill.edu
>Audit-Trail:
>Unformatted: