frankie@killer.DALLAS.TX.US (Frank Filippis) (02/22/89)
I am encountering the following errors while trying to compile a sunview
program on a Sun 4.
Can anyone tell me if this is a compiler error?
"/usr/include/sunwindow/attr.h", line 183: error: non-int field
"/usr/include/sunwindow/attr.h", line 185: error: non-int field
"/usr/include/sunwindow/attr.h", line 186: error: non-int field
"/usr/include/sunwindow/attr.h", line 188: error: non-int field
typedef union {
struct {
Attr_pkg pkg : 8; /* Line 183 */
unsigned ordinal : 8;
Attr_list_type list_type : 2; /* Line 184 */
Attr_list_ptr_type list_ptr_type : 1; /* Line 185 */
unsigned spare1 : 1;
Attr_base_type base_type : 7; /* Line 188 */
unsigned spare2 : 1;
unsigned cardinality : 4;
} info;
Attr_attribute code;
} Attr_union;
also the following line
err_frame=(Frame) window_create(NULL,FRAME,
WIN_X,0,
WIN_Y,0,
WIN_WIDTH,1152,
WIN_HEIGHT,35,
FRAME_SHOW_LABEL,FALSE,
WIN_SHOW, FALSE,
0);
results in the following error
"error.cc", line 34: error: unexpected 1 argument for window_create()
window create is declared in the header file
window.h as
extern Window window_create();
with no parameters specified.
is there anyway to get around this in c++ without redefining the function as
extern Window window_create(...);
Thanks
Frank A. Filippis
Shearson Lehman Hutton
uunet!slcpi!mbs-dev9!frankcoggins@coggins.cs.unc.edu (Dr. James Coggins) (02/23/89)
In article <7276@killer.DALLAS.TX.US> frankie@killer.DALLAS.TX.US (Frank Filippis) writes: > >I am encountering the following errors while trying to compile a sunview >program on a Sun 4. > ... apparent bugs and other weirdness deleted... >Frank A. Filippis >Shearson Lehman Hutton >uunet!slcpi!mbs-dev9!frank What a timely posting! I have just encountered and fixed the same problems - as well as a whole bunch of others you encounter when you fix these. The suntools .h files work fine with C but contain a myriad of syntax errors for C++. I fixed the problem in attr.h by making the offending fields in the offending struct ints and keeping the enumerated type name as a comment. (This is either a cfront bug or a semantic detail that cfront catches: isn't an enumerated type supposed to be equivalent to an int?) Then I went to work on function prototypes. I first tried simply changing all () to (...). This would basically turn off the checking of number and type of arguments. Unfortunately, it also breaks the suntools header files as far as C is concerned. (I'm making these mods in /usr/include/CC/{suntool,sunwindow,pixrect} which started as copies of the regular suntools headers.) After fixing the few macros-with-no- arguments that were made invalid by that change, there were lots of SunView functions that were left undeclared. Warnings irritate me, so I looked at the files again. Several of their .h files have sections that are wrapped in #ifdef cplus ... #endif that contain complete, explicit argument declarations that look correct. I thought, "Hey, they've thought of us forward-looking, leading-edge C++ programmers after all!" So I defined the symbol cplus in my code and got immediate trouble: defining cplus enables those function prototypes but does not inhibit the void foo() prototypes, resulting in multiple definitions. I guess they weren't planning for C++ after all. I rearranged some things so that the foo() prototypes were defined only if cplus is not defined. The validity of doing this is still questionable, however, because there were some obvious, trivial syntax errors (FOR C AND C++!) in the newly enabled code! There were also a few VERY strange items that I don't recognize as even being valid C - pointer-to-function-with-typed-arguments as argument to another function is still a mystery to me - that I just commented out of there. Anyway, the result was that it all worked. I recompiled my suntools image display program and it works. Hallelujah! I expect to get it working on Sun 4's today by redoing the same modifications on the somewhat different suntools.h files for Sun 4's. Disclaimer: Now I'd prefer NOT to get a hundred requests for my modified SunView header files because while they work for me now, I'm really not a sophisticated suntools programmer, and I really can't answer many questions about why something else doesn't work - or does. I don't know what I might have screwed up or not fixed simply because I have limited needs for SunView. (Our crowd is moving steadily toward X anyway, and we'd move faster if the X Consortium was foresighted enough to look beyond text windows and line drawing to raster graphics and image processing.) It would not be difficult to create a set of SunView headers that would work correctly for both C and C++ (using the cplus symbol or something similar to tell the difference). I have no plans to develop such a set of unified headers myself. (But I have my price! You listening, Sun?) --------------------------------------------------------------------- Dr. James M. Coggins coggins@cs.unc.edu Computer Science Department UNC-Chapel Hill Convert to X? Chapel Hill, NC 27514-3175 But I just mastered SunView!! ---------------------------------------------------------------------
dog@cbnewsl.ATT.COM (edward.n.schiebel) (02/24/89)
In article <7276@killer.DALLAS.TX.US>, frankie@killer.DALLAS.TX.US (Frank Filippis) writes: > > I am encountering ... errors while trying to compile a sunview > program ... > > "error.cc", line 34: error: unexpected 1 argument for window_create() > > is there anyway to get around this in c++ without redefining the function as > > extern Window window_create(...); > In a word yes and no. There is no way around declaring the function, but the proper declaration is extern Window window_create(Window, caddr_t(*)(), ...); If you are running cfront 2.0, then you also need to wrap this declaration between extern "C" { and } By declaring functions as func(...), you are defeating one of the purposes of function prototypes, verifying the application is using the proper argument types. I have a complete (and untested) set of sunview header files that have been C++'ified. If it is legal for me to post them, I will. Ed Schiebel ...att!vilya!dog
graeme@basser.oz (Graeme Woodward) (03/13/89)
I have a number of problems with C++ used on a Sun. I have a program that compiled on an Apollo (running sr10.1) that refused to compile on the SUN. The errors are ... "undeclared function _flsbuf() called" in stream.h "uninitialized reference _rresult" supposedly in one of my header files. Nowhere in my code, or in the intermediate code up to the stage generated by cfront, does any variable with a name anything like rresult is used!! Does anyone have any comments or possible solutions. Graeme.