Newsgroups: comp.lang.c++ Path: utzoo!utgpu!news-server.csri.toronto.edu!torsqnt!geac!alias!rae From: rae@alias.com (Reid Ellis) Subject: Re: C++ and the DEC Station Message-ID: <1991Apr29.172042.29141@alias.com> Sender: news@alias.com (USENET News) Organization: Alias Research, Inc. Toronto ON Canada References: <2608@otc.otca.oz> <1991Apr25.183306.767@rathe.cs.umn.edu> Date: Mon, 29 Apr 91 17:20:42 GMT 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? >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]