Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!spool.mu.edu!cs.umn.edu!kksys!wd0gol!rathe!ian From: ian@rathe.cs.umn.edu (Ian Hogg) Newsgroups: comp.lang.c++ Subject: Re: C++ and the DEC Station Message-ID: <1991May1.135111.9148@rathe.cs.umn.edu> Date: 1 May 91 13:51:11 GMT Article-I.D.: rathe.1991May1.135111.9148 References: <2608@otc.otca.oz> <1991Apr25.183306.767@rathe.cs.umn.edu> <1991Apr29.172042.29141@alias.com> Organization: Rathe, Inc. Lines: 52 In article <1991Apr29.172042.29141@alias.com> rae@alias.com (Reid Ellis) writes: >Ian Hogg 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