[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference lassie::ucx

Title:DEC TCP/IP Services for OpenVMS
Notice:Note 2-SSB Kits, 3-FT Kits, 4-Patch Info, 7-QAR System
Moderator:ucxaxp.ucx.lkg.dec.com::TIBBERT
Created:Thu Nov 17 1994
Last Modified:Fri Jun 06 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5568
Total number of notes:21492

5326.0. "RPCGEN error?" by CSC32::J_HENSON (Don't get even, get ahead!) Mon Mar 10 1997 13:19

ucx v4.1-eco5, dec c for openvms alpha v5.5-002, openvms alpha v6.2

I have another problem report regarding rpcgen.  I have attached a
com procedure to demonstrate the behavior, and the output I
got when I ran it.

I don't claim to know rpcgen, but it seems strange that two different
modules with the same exact name being generated in the same source
file is correct.

Please advise.

Jerry

===============x.com====================================================

$ucx sho version
$create x.x
enum krB
{
        KRTRUE = 1,
        KRFALSE = 0
};
typedef enum krB krB;
typedef krB KRB;
$rpcgen/header x.x
$rpcgen/xdr x.x
$type x.h
$type x_xdr.c

============results of running x.out=======================================


  Digital TCP/IP Services for OpenVMS Alpha Version V4.1 - ECO Level 4
  on a AlphaServer 1000 4/200 running OpenVMS V6.2    

/*
 * Please do not edit this file.
 * It was generated using rpcgen.
 */

#include <string.h>
#include "UCX$RPC:TYPES.H"


enum krB {
	KRTRUE = 1,
	KRFALSE = 0,
};
typedef enum krB krB;
bool_t xdr_krB();

bool_t xdr_krB();

typedef krB KRB;
bool_t xdr_KRB();
/*
 * Please do not edit this file.
 * It was generated using rpcgen.
 */

#include <string.h>
#include "UCX$RPC:RPC.H"
#include "X.H"

bool_t
xdr_krB(xdrs, objp)
	XDR *xdrs;
	krB *objp;
{
	if (!xdr_enum(xdrs, (enum_t *)objp)) {
		return (FALSE);
	}
	return (TRUE);
}

bool_t
xdr_krB(xdrs, objp)
	XDR *xdrs;
	krB *objp;
{
	if (!xdr_krB(xdrs, objp)) {
		return (FALSE);
	}
	return (TRUE);
}

bool_t
xdr_KRB(xdrs, objp)
	XDR *xdrs;
	KRB *objp;
{
	if (!xdr_krB(xdrs, objp)) {
		return (FALSE);
	}
	return (TRUE);
}
T.RTitleUserPersonal
Name		DateLines
5326.1LASSIE::GEMIGNANITue Mar 11 1997 13:2820
    
    Well, I don't to make any such claim, either.
    
    It looks like when you cascaded the declarations, RPCGEN didn't notice
    that it was already done.
    
    When RPCGEN handles the typedef, it apparently has to perform the
    expansion of the dependency in order to resolve it.
    
    You used a previous typedef for yet another typedef, and RPCGEN
    apparently doesn't catch multiple typedefs of this variety.
    
    This sort of thing is best solved by `#define KRB krB', so that
    there would only be ONE typedef.
    
    I'm not trying to get out of this ***BUT*** this code is derived from
    DIGITAL UNIX, which is derived from SUN's ONC and it is not UCX
    original code.  This problem would therefore exist on all three systems
    and, I would surmise, any system which uses the ONC reference set
    in their product.
5326.2And?CSC32::J_HENSONDon&#039;t get even, get ahead!Wed Mar 12 1997 09:5621
>>                    <<< Note 5326.1 by LASSIE::GEMIGNANI >>>

    
>>    I'm not trying to get out of this ***BUT*** this code is derived from
>>    DIGITAL UNIX, which is derived from SUN's ONC and it is not UCX
>>    original code.  This problem would therefore exist on all three systems
>>    and, I would surmise, any system which uses the ONC reference set
>>    in their product.

Yes, this code is from Unix.  In fact, this and another rpcgen
issue which I posted earlier (the #pragma issue) is from the same customer
who is porting rpc code from Unix to OpenVMS, so I suspect he will be
reporting other such anomalies.

What is our official position on this?  Is it a bug in rpgcgen, or has the
use violated some standard with the way in which his code is written.  I
have to tell him something.

Thanks,

Jerry
5326.3LASSIE::GEMIGNANIThu Mar 13 1997 18:0810
    
    I gather from your mail that this customer sees the same thing on his
    Unix systems.  If so, then the portability issues require that he
    adheres to whatever works; if I fix it here it will be broken somewhere
    else.
    
    The #pragma issue is strictly VMS related (it's not a portablility issue,
    I surmise?) so he should be accomodating the DECC compiler.
    
    Is this reasonable?
5326.4LASSIE::GEMIGNANIThu Mar 13 1997 18:268
    I re-read this issue, then decided to bring (i.e. test) this code out on
    DIGITAL UNIX.  It produces the same result.
    
    Does the customer see this problem on *his* systems?
    
    The UCX and DIGITAL UNIX code are based on the code from Sun
    Microsystems, so I would expect other system's code to exhibit
    the similar behavior if they are also Sun-based.