Xref: utzoo comp.windows.x:29339 alt.toolkits.xview:62 Path: utzoo!utgpu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!usc!apple!uokmax!munnari.oz.au!mel.dit.csiro.au!yarra!bksmel!paulf From: paulf@bksmel.oz.au (Paul Fitchett) Newsgroups: comp.windows.x,alt.toolkits.xview Subject: Problem porting XView 2.0 to DG AviiON ( varargs ) Message-ID: <348@bksmel.oz.au> Date: 7 Nov 90 22:05:48 GMT Followup-To: comp.windows.x Lines: 49 Hi, I'm trying to port XView 2.0 to the DG AViiON and have run into trouble with the Attr_avlist stuff. Certain code in the distribution assumes that va_list is of a type that can be cast to unsigned long. On a Sun this happens to be true, as va_list is defined to be char *, however on a DG va_list is a structure: typedef struct { int __va_arg; /* argument number */ int *__va_stk; /* start of args passed on stack */ int *__va_reg; /* start of args passed in regs */ } va_list; There appears to be a way around this using attr_create() to make the Attr_avlist from the va_list, however this requires that NON_PORTABLE be undefined in the file attr.c. A consquence of this is that the function attr_copy_valist() (which is declared extern in attr_impl.h) is required. I cannot find the *.c file containing the definition of attr_copy_valist() at all. In the file attr.c there is a comment that refers to a file attr_portable.c, which is not present, perhaps this file is the one I need. The problem occurs in certain files (such as cms_pblc.c) which have the following construct: Pkg_private Xv_opaque cms_get_attr(cms_public, status, attr, args) Cms cms_public; int *status; Cms_attribute attr; va_list args; { Cms_info *cms = CMS_PRIVATE(cms_public); Xv_opaque value; Attr_avlist avlist = (Attr_avlist) args; <--- int cms_status = 0; switch (attr) { The line marked with <--- is rejected by the compiler on the DG and should perhaps be replaced by a call to attr_create() to make the avlist from the args in a portable way. If anyone can help me by sending the missing files, or by explaining how to get around this problem, or indeed by correcting a misunderstanding I may have about any of this, I would be very grateful. Thanks, Paul Fitchett (paulf@bksmel.oz.au)