Re: Different behaviour of HP C on Alpha and VAX
From: Hoff Hoffman (hoff_at_hp.nospam)
Date: 04/05/05
- Next message: David Gray: "Remote printing woes."
- Previous message: Stanley F. Quayle: "Re: VMS Command language."
- In reply to: Ralf Gaertner: "Different behaviour of HP C on Alpha and VAX"
- Next in thread: Ralf Gaertner: "Re: Different behaviour of HP C on Alpha and VAX (thanks Ed, FJ and Hof)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Tue, 05 Apr 2005 16:35:58 GMT
In article <e1b5cbf1.0504050103.4df3235d@posting.google.com>, ralf.gaertner@t-systems.com (Ralf Gaertner) writes:
:I have a program which generates different messages on Alpha and VAX.
:
:- VAXstation 4000 , VMS 7.2 , DEC C 6.4-005
:
: CC/DECC/OBJ=DSA1:[TEXMF2003.SOURCE.CWEB-3-64.VMS]CWEAVE.VAX_OBJ_V72
: /DEFINE=(OPENVMS)
:DSA1:[TEXMF2003.SOURCE.CWEB-3-64.VMS]CWEAVE.C/LIST
:
:- DS10 , VMS 7.2-1 , DEC C 6.4-005-46B10
:
: CC/OBJ=DSA1:[TEXMF2003.SOURCE.CWEB-3-64.VMS]CWEAVE.AXP_OBJ_V721 -
: /DEFINE=(OPENVMS)
:DSA1:[TEXMF2003.SOURCE.CWEB-3-64.VMS]CWEAVE.C/LIST
:
:On the VAX the compiler does it's job without any messages, on the
:Alpha I get a "informational message" and a "warning":
:
:3122 extern int strlen();
:...........1
:%CC-I-INTRINSICINT, (1) In this statement, the return type for
:intrinsic "strlen" is being changed from "size_t" to "int".
:
:3383 strcpy(collate+1," \1\2\3\4\5\6\7\10\11\12\13\14\15\16\17");
:.......1
:%CC-W-PTRMISMATCH1, (1) In this statement, the referenced type of the
:pointer value "collate+1" is "unsigned char", which is not compatible
:with "char" because they differ by signed/unsigned attribute.
:
:The warning is correct, since the array "collate" is defined as
:"unsigned char" and strcpy wants "char". But why is this only
:recognized on the Alpha and not on the VAX ?
For some background, the Alpha compiler is newer, and is based on a far
newer code generator.
I would look for any local symbols, such as CC. I do know that the
more recent C compilers are better at spotting calling-related errors,
and that may well be the case here.
I'd get rid of the extern declaration in the code -- that's busted -- and
I'd use an include of string.h. Redefining a standard library routine in
local code perilous practice at best, and should generally be avoided.
If this is an old port, I've found various "creative" porting techniques
in such code and in older ports, and have spent time expurgating the old
code -- older ports tend to have work-arounds for routines that were
wrong, missing or broken in OpenVMS, and newer libraries tend to have
better and more compatible libraries, and less need for the work-arounds.
Some of the work-arounds have caused problems -- I've occasionally
presented sessions at various events around porting code and around the
problems I've seen. Re-mapping standard library functions to local
functions is among the more common sources of problems -- local routines
should have local names, and not language-defined names. (Having two
or more routines with the same name is a technique I've seen used, and
it is completely dependent on exactly how the link and the libraries and
the definition files are implemented on each particular platform.)
I've some modules of #defines that I use to temporarily remap the return
status codes for some common library functions -- I use these to allow me
to select more aggressive diagnostics within the C compiler. That written,
there are a number of standard C library calls that should have a return
status coded, and it is common for programmers to ignore this for some of
the calls -- the appropriate fix is to code the return status appropriate
for the function call, of course.
I'd also use the compiler-provided __VMS and not the /DEFINE=(OPENVMS),
but that's personal preference.
---------------------------- #include <rtfaq.h> -----------------------------
For additional, please see the OpenVMS FAQ -- www.hp.com/go/openvms/faq
--------------------------- pure personal opinion ---------------------------
Hoff (Stephen) Hoffman OpenVMS Engineering hoff[at]hp.com
- Next message: David Gray: "Remote printing woes."
- Previous message: Stanley F. Quayle: "Re: VMS Command language."
- In reply to: Ralf Gaertner: "Different behaviour of HP C on Alpha and VAX"
- Next in thread: Ralf Gaertner: "Re: Different behaviour of HP C on Alpha and VAX (thanks Ed, FJ and Hof)"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
|
