I'm told that you folks are one of the better places to ask about rpcgen. 
Please feel free to direct me elsewhere or forward as appropriate.

I've inherited a program that uses RPC.

For unknown historical reasons, its *_svc.c file has been modified and 
checked into the repository.  This is a nuisance because when I change the 
*.x file and regenerate the *_svc.c file, I have to hand-merge the changes.

The vast majority of the changes are to make the file pass cstyle and lint. 
  It seems like it would be straightforward to fix rpcgen to generate 
cleaner code, so that the generated code would be as similar as possible to 
the modified-and-checked-in code, to minimize the work involved in a 
resync.  That seems like a relatively non-controversial bit of work.  (Any 
disagreement?)

I did that work, and cleaned up my existing *_svc.c file to eliminate 
spurious differences between it and the generated file, and found that I 
only had one difference left, one difference that prevented me from just 
dynamically generating the file (which would avoid the need to fix the nits 
mentioned above, though I'd probably fix them anyway).  The generated 
*_svc.c file includes a message handling function _msgout that calls syslog 
or fprintf(stderr, ...) depending on a  couple of flags.  My application 
has its own logging infrastructure, so I don't want to have this one file 
doing its own thing.

I'd like to add a feature to rpcgen to allow the user to customize message 
handling, so that the generated file can be used directly and there is no 
need to hand-tweak it and check the file into the repository.

The change that I have prototyped is to surround the definition of _msgout with
        #if     !defined(_msgout)
        ...
        #endif

This then allows one to supply an alternate definition using % lines in the 
*.x file, e.g.:

     %#define       _msgout my_msgout
     %extern void my_msgout(char *);

or perhaps

     %#define _msgout(s)        printf("RPC:  %s\n", (s))

I could make this change as a consolidation-private interface, but it seems 
like it's of more general interest, suggesting an ARC case.  At that point 
it seems like I should involve the owners... which is what brings us here.

Any thoughts?

Reply via email to