grahamd@otc.otca.oz.au (Graham Dumpleton) (04/23/91)
I recently posted asking about Glockenspiel C++ for the DEC Station. In particular whether it had the AT&T tasking library. The responses I got indicated that it didn't. I did find out though that Oregon and Oasys sell a version of C++ for the DEC Station which does have the tasking library. Has anyone used these companies ports of AT&T's cfront. Are they okay or are they buggy. Any comments would be appreciated. -- Graham Dumpleton (grahamd@otc.otca.oz.au)
ian@rathe.cs.umn.edu (Ian Hogg) (04/26/91)
In article <2608@otc.otca.oz> grahamd@otc.otca.oz.au (Graham Dumpleton) writes: > > >I recently posted asking about Glockenspiel C++ for the DEC Station. In >particular whether it had the AT&T tasking library. The responses I got >indicated that it didn't. I did find out though that Oregon and Oasys sell >a version of C++ for the DEC Station which does have the tasking library. >Has anyone used these companies ports of AT&T's cfront. Are they okay or >are they buggy. > I don't think Oregon's is a port of cfront. I used it on HP and had to quit using it for the following reason: I was porting an application from C to C++. It depended on a C library compiled with HP's C compiler. It turned out that at least one of the functions had a parameter who via several levels of typedef's was a short. The client program (compiled with Oregon) used sizeof(short) bytes on the stack to pass the parameter. HP expects to use sizeof(short) out of sizeof(int) bytes. This caused all kinds of problems ( program crashed). And could only be resolved by going down to the lowest level of typedef and changing it to int. Oregon had to command line switches or anything to modify this behavior (except running in K&R mode which is real useful for C++ code) Oregon response to the problem was something like "the spec says we can do it this way so were are not going to change". I think that a 3rd party compiler vendor ought to make sure code they generate is compatable with libraries compiled with the native compiler (C compiler at least). There is no way I am going to debug all include files I get from HP, Oracle, etc. to make sure they don't contain shorts and God knows what else. If you are thinking about purchasing Oregon C++ please make sure you will not get caught by the above bug. Here is a small example program that shows the problem: /* Compile this with Native C compiler */ #include <stdio.h> void foobar(s) short s; { printf("It is %d\n",s); } // Compile this with occ extern "C" void foobar(short s); main() { short s2 = 1; foobar(s2); } >Any comments would be appreciated. > >-- >Graham Dumpleton (grahamd@otc.otca.oz.au) Sorry for the extensive babbling but I feel that this is a serious problem with the product and causes hard to find errors. -- Ian Hogg email: rathe!ian@cs.umn.edu ...!umn-cs!rathe!ian Rathe, Inc ianhogg@cs.umn.edu 366 Jackson Street phone: (612) 225-1401
rae@alias.com (Reid Ellis) (04/30/91)
Ian Hogg <ian@rathe.cs.umn.edu> writes: > I was porting an application from C to C++. It depended on a C >library compiled with HP's C compiler. It turned out that at least >one of the functions had a parameter who via several levels of >typedef's was a short. The client program (compiled with Oregon) used >sizeof(short) bytes on the stack to pass the parameter. HP expects to >use sizeof(short) out of sizeof(int) bytes. This is standard C behaviour. Integer values [i.e. char, short] are promoted to int when pushed onto the stack. This should be handled by the C++ compiler when you say 'extern "C"'. It would appear that Oregon's C++ compiler does not do this, in which case it is a bug, despite what they say. Note that there are some C compilers out there that will, given an ANSI function prototype, actually assume that the parameters on the stack are of the same size as that of the argument type -- i.e. a short will only occupy two bytes versus 4 bytes for an int etc. Perhaps Oregon is testing their 'extern "C"' with code of this form? >Oregon response to the problem was something like "the spec says we >can do it this way so were are not going to change". If the code you included with your article crashes, it is indeed a bug in Oregon's C++ compiler. Specifically with promoting chars and shorts to int. THe same thing will probably happen with floats->doubles, too. You'll either have to convince Oregon to fix their compiler or else switch vendors. Good luck! Reid -- Reid Ellis 1 Trefan Street Apt. E, Toronto ON, M5A 3A9 rae@utcs.toronto.edu || rae@alias.com CDA0610@applelink.apple.com || +1 416 362 9181 [work]
ian@rathe.cs.umn.edu (Ian Hogg) (05/01/91)
In article <1991Apr29.172042.29141@alias.com> rae@alias.com (Reid Ellis) writes: >Ian Hogg <ian@rathe.cs.umn.edu> writes: >> I was porting an application from C to C++. It depended on a C >>library compiled with HP's C compiler. It turned out that at least >>one of the functions had a parameter who via several levels of >>typedef's was a short. The client program (compiled with Oregon) used >>sizeof(short) bytes on the stack to pass the parameter. HP expects to >>use sizeof(short) out of sizeof(int) bytes. > >This is standard C behaviour. Integer values [i.e. char, short] are >promoted to int when pushed onto the stack. This should be handled by >the C++ compiler when you say 'extern "C"'. It would appear that >Oregon's C++ compiler does not do this, in which case it is a bug, >despite what they say. > >Note that there are some C compilers out there that will, given an >ANSI function prototype, actually assume that the parameters on the >stack are of the same size as that of the argument type -- i.e. a >short will only occupy two bytes versus 4 bytes for an int etc. >Perhaps Oregon is testing their 'extern "C"' with code of this form? I believe that is what they are doing. At minimum, I would expect them to give me a compiler flag to interpret parameter passing the classic way. Hell, I'd even be happy if they gave an 'extern "K&R C"' to use. > >>Oregon response to the problem was something like "the spec says we >>can do it this way so were are not going to change". > >If the code you included with your article crashes, it is indeed a bug >in Oregon's C++ compiler. Specifically with promoting chars and >shorts to int. THe same thing will probably happen with >floats->doubles, too. > >You'll either have to convince Oregon to fix their compiler or else >switch vendors. Good luck! > Reid I switched quite a while ago when HP came out with C++. I hope that my troubles can save a few other people some nasty headaches. >-- >Reid Ellis 1 Trefan Street Apt. E, Toronto ON, M5A 3A9 >rae@utcs.toronto.edu || rae@alias.com >CDA0610@applelink.apple.com || +1 416 362 9181 [work] -- Ian Hogg email: rathe!ian@cs.umn.edu ...!umn-cs!rathe!ian Rathe, Inc ianhogg@cs.umn.edu 366 Jackson Street phone: (612) 225-1401
sys1@imdpy1.im.se (Systecon) (05/02/91)
In article <2608@otc.otca.oz> grahamd@otc.otca.oz.au (Graham Dumpleton) writes: > > >I recently posted asking about Glockenspiel C++ for the DEC Station. In >particular whether it had the AT&T tasking library. The responses I got >indicated that it didn't. I did find out though that Oregon and Oasys sell >a version of C++ for the DEC Station which does have the tasking library. >Has anyone used these companies ports of AT&T's cfront. Are they okay or >are they buggy. > I could defenately not recommend Oregon C++. It is very buggy. I have only used it on a Sun 3, so I only know of that imlementation, but... I also once bought the Glockenspiel compiler for SCO Unix, but returned it without opening it because it hadn't got a source level debugger (it had none at all actually). -- Mats Luthman Systecon AB (A subsidiary of Industri-Matematik AB) Stockholm, Sweden
mike@taumet.com (Michael S. Ball) (05/04/91)
In article <SYS1.91May2132022@imdpy1.im.se> sys1@imdpy1.im.se (Systecon) writes: > >I could defenately not recommend Oregon C++. It is very buggy. I have only >used it on a Sun 3, so I only know of that imlementation, but... I also once >bought the Glockenspiel compiler for SCO Unix, but returned it without opening >it because it hadn't got a source level debugger (it had none at all actually). Then you should try Oregon C++ again. They recently had us take over their maintenance for them, and we are releasing stability updates to all of their compilers. We have found the new version, at least, to have far fewer bugs than cfront, and a lot less "Sorry, not implemented" messages as well. The original 1.2 compiler got an undeserved reputation for being buggy because it attempted to introduce 2.0 features (and restrictions) before 2.0 from AT&T came out. Users assumed anything not like cfront 1.2 was a bug. It did have bugs, but most of the complaints were about differences in features, which the user, not having access to the draft 2.0 reference manual, assumed were bugs. (This is from a recent review of their bug reports.) A major tactical error, in my opinion. Actually, it's academic at the moment since the DECStation version is due to reach field test next week, so you can't buy it. -- Michael S. Ball mike@taumet.com TauMetric Corporation (619)697-7607
mike@taumet.com (Michael S. Ball) (05/04/91)
In article <1991May1.135111.9148@rathe.cs.umn.edu> ian@rathe.cs.umn.edu (Ian Hogg) writes: >In article <1991Apr29.172042.29141@alias.com> rae@alias.com (Reid Ellis) writes: >>Ian Hogg <ian@rathe.cs.umn.edu> writes: >>This is standard C behaviour. Integer values [i.e. char, short] are >>promoted to int when pushed onto the stack. This should be handled by >>the C++ compiler when you say 'extern "C"'. It would appear that >>Oregon's C++ compiler does not do this, in which case it is a bug, >>despite what they say. This isn't true. It's standard behaviour for non-prototyped functions. Functions with prototypes can be expected to get the exact type. You don't give enough information to decide if this is an error in the prototype. If so, the Oregon interpretation is standard-conforming and the header file is in error. If not, the Oregon interpretation is still standard conforming but poorly integrated with the environment. I'm not saying that the complaint is invalid, just that there seems to be some misunderstanding of ANSI C here. It has nothing to do with extern "C", which has a different purpose. We (TauMetric) have recently taken over all of Oregon Software's technical maintenance and development. We have discovered a number of cases where the OS compilers, though standard, are not well integrated with the environment, and hence not useful as useful as they should be. We are in the process of issuing "stability releases" which clean up all reported bugs, as well as providing much closer integration with the programming environment. In most cases this has meant including both standard ANSI libraries and libraries which use the vendors (usually) wildly non-ANSI libraries. I will not go into my theories about why OS has taken this approach in the past, but it will not continue. Anything which prevents use of a library in the host environment is now considered a bug. -- Michael S. Ball mike@taumet.com TauMetric Corporation (619)697-7607