Subject: bin/6788: rpcgen -N generates incorrect prototype
To: None <>
From: None <>
List: netbsd-bugs
Date: 01/11/1999 12:45:30
>Number:         6788
>Category:       bin
>Synopsis:       rpcgen -N generates incorrect prototype
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    bin-bug-people (Utility Bug People)
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Mon Jan 11 02:50:03 1999
>Originator:     Valtteri Vuorikoski
Data Fellows
>Release:        1.3.2
System: NetBSD xxx 1.3.2 NetBSD 1.3.2 (xxx) #0: Mon Dec 7 17:00:14 EET 1998 vuorva@xxx:xxx i386

	rpcgen -N foo.x will generate a prototype in foo.h that does not match the
	function in foo_xdr.c for rpc functions with multiple arguments. The second
	argument of the relevant XDR function should be a pointer, but is not marked
	as such in the header (the output in foo_xdr.c is correct).

	Also tested with -current rpcgen.

	rpcgen -N -C the following:

program FOOPROG {
 version FOOVER {
  int foome(int,int) = 1;
 } = 1;
} = 0x2000010;

	Attempt to compile the resulting foo_xdr.c. The result:
foo_xdr.c:10: conflicting types for `xdr_foome_1_argument'
foo.h:22: previous declaration of `xdr_foome_1_argument'

	foo.h has:
extern  bool_t xdr_foome_1_argument(XDR *, foome_1_argument);
	while foo_xdr.c has:
xdr_foome_1_argument(XDR *xdrs, foome_1_argument *objp)

	Apply following to rpcgen (this is -current as of 11.1.1999):
*** rpc_hout.c.orig     Mon Jan 11 12:20:48 1999
--- rpc_hout.c  Mon Jan 11 12:26:08 1999
*** 176,182 ****
             f_print(fout, "};\n");
             f_print(fout, "typedef struct %s %s;\n", name, name);
!            pxdrfuncdecl(name, NULL);
             f_print(fout, "\n");
--- 176,182 ----
             f_print(fout, "};\n");
             f_print(fout, "typedef struct %s %s;\n", name, name);
!            pxdrfuncdecl(name, 1);
             f_print(fout, "\n");

	A quick look at rpcgen sources and some testing didn't reveal a care whether
	this would be wrong in some case, but someone who is more intimately familiar
	with rpcgen internals should probably check this.