Subject: xdr problem
To: None <current-users@NetBSD.ORG>
From: Uwe Klaus <uklaus@info015.informatik.uni-leipzig.de>
List: current-users
Date: 12/02/1996 15:21:58
I got the following problem when I'm using the xdr protocol. It's a
problem in the sense that NetBSD behaves in another way than all other
Unix systems I have access to (Linux(i386), Solaris2.5(Sparc),
AIX(rs6000), HP-UX).

Run the following program to create the file "MyFile2" containing two
integers xdr encoded. (I omited all error business for simplicity.)

======================================================================
#include <fcntl.h>
#include <stdio.h>
#include <rpc/rpc.h>
#include <rpc/types.h>
#include <rpc/xdr.h>
int main(argc, argv)
     int  argc;
     char **argv;
{
  char rawbuf[BUFSIZ]; 
  int fd;
  FILE f;
  FILE *fp = &f;
  XDR  h;
  XDR  *handle = &h;
  int a=1, b=2;

  fd = open("MyFile2", O_WRONLY|O_CREAT|O_EXCL, 0666);
  fp = fdopen(fd, "a");
  setbuf(fp, rawbuf);
  xdrstdio_create(handle, fp, XDR_ENCODE);
  xdr_int(handle, &a);
  xdr_int(handle, &b);
  xdr_destroy(handle);
  fflush(fp);
  close(fd);
}
======================================================================

And now read the created file in:

======================================================================
#include <fcntl.h>
#include <stdio.h>
#include <rpc/rpc.h>
#include <rpc/types.h>
#include <rpc/xdr.h>
int main(argc, argv)
     int  argc;
     char **argv;
{
  char rawbuf[BUFSIZ]; 
  int  fd;
  FILE f;
  FILE *fp = &f;
  XDR  h;
  XDR  *handle = &h;
  int  a=0, b=0;

  fd = open("MyFile2", O_RDONLY);
  fp = fdopen(fd, "r");
  setbuf(fp, rawbuf); 
  xdrstdio_create(handle, fp, XDR_DECODE);
  xdr_int(handle, &a);
  xdr_destroy(handle);
  fp = fdopen(fd, "r");
  setbuf(fp, rawbuf); 
  xdrstdio_create(handle, fp, XDR_DECODE);
  xdr_int(handle, &b);
  xdr_destroy(handle);
  printf("a: %d, b: %d\n", a, b);
}
======================================================================

The results are:

	NetBSD(i386)   a: 1, b: 0
	Linux(i386)    a: 1, b: 2
	Solaris(Sparc) a: 1, b: 2
	AIX(RS6000)    a: 1, b: 2
	HP-UX          a: 1, b: 2

O.k., one can say why you are doing "fdopen" twice. But this should
point out the problem only. I excerpted from a really complex program
containing a user interface for dealing with stream sockets and data
transfer between several platforms. 

The fdopen manual page says that the streams with mode "r" are always
positioned at the beginning of the file. So, NetBSD behaves correct
and the other operatings not? But this problem is bound to xdr as the
following programs show.

Write again two integers to the file "MyFile1"
======================================================================
#include <fcntl.h>
int main(argc, argv)
     int  argc;
     char **argv;
{
  int fd;
  int a=1, b=2;

  fd = open("MyFile1", O_WRONLY|O_CREAT|O_EXCL, 0666);
  write(fd, &a, sizeof(int));
  write(fd, &b, sizeof(int));
  close(fd);
}
======================================================================

And read the file in

======================================================================

#include <fcntl.h>
#include <stdio.h>
int main(argc, argv)
     int  argc;
     char **argv;
{
  int  fd;
  FILE f;
  FILE *fp = &f;
  int  a=0, b=0;

  fd = open("MyFile1", O_RDONLY);
  fp = fdopen(fd, "r");
  fread(&a, sizeof(int), 1, fp);
  fp = fdopen(fd, "r");
  fread(&b, sizeof(int), 1, fp);
  printf("a: %d, b: %d\n", a, b);
}
======================================================================

And all of the above mentioned operatinmg systems behave the same:

	NetBSD(i386)   a: 1, b: 0
	Linux(i386)    a: 1, b: 0
	Solaris(Sparc) a: 1, b: 0
	AIX(RS6000)    a: 1, b: 0
	HP-UX          a: 1, b: 0

What's on ?

Best regards
Uwe 

-------------------------------------------------------------------------------
 Uwe Klaus                             email: uklaus@informatik.uni-leipzig.de	
 Department of Computer Science
 University Leipzig                    voice: +49 341 9732204
 Augustusplatz 10/11
 D - 04109 Leipzig                     FAX:   +49 341 9739348
-------------------------------------------------------------------------------