DECC /VAXC Compiler

[ronald piazza]

Greetings,

What is the main difference between the DECC and VAXC compiler?

Thanx in Advance,

[Larry Kilgallen]

Post by ronald piazza
What is the main difference between the DECC and VAXC compiler?

VAXC implements an extended K&R C and runs only on VAX.

DEC C implements an extended ANSI C and runs on both VAX and Alpha.

[Nom de Plume]

Post by Larry Kilgallen

Post by ronald piazza
What is the main difference between the DECC and VAXC compiler?

VAXC implements an extended K&R C and runs only on VAX.
DEC C implements an extended ANSI C and runs on both VAX and Alpha.

With DEC C /STANDARD=VAXC places the compiler in VAX C mode. There
are differences in the C language as implemented in previous versions
of VAX C and the C language as defined by ANSI (the differences are
primarily concerned with how the preprocessor works). This mode
provides compatibility for programs that depend on old VAX C behavior.

JMOD

[Z]

Post by Larry Kilgallen
DEC C implements an extended ANSI C and runs on both VAX and Alpha.

Which can make badly written code break in rather mysterious
ways, like having -1 be greater than 100 in a comparison, for
example.

And /STANDARD=VAXC doesn't "fix" this.

A few other common gotchas with DEC C are leaving the VAX C
.OPT around and linking with VAXCRTL (bad!) and not realizing
that some functions (socket i/o funcs, IIRC) are not linked
in properly without the /PREFIX qualifier.

[Larry Kilgallen]

Post by Z

Post by Larry Kilgallen
DEC C implements an extended ANSI C and runs on both VAX and Alpha.

Which can make badly written code break in rather mysterious
ways, like having -1 be greater than 100 in a comparison, for
example.
And /STANDARD=VAXC doesn't "fix" this.

But switching to a higher level language does :-)

[nobody]

Post by Z
Which can make badly written code break in rather mysterious
ways, like having -1 be greater than 100 in a comparison, for
example.

I bitched a lot when I moved from VAXC to DECC since DECC is far more
pedantic, especially with regards to character strings being passed by
reference by default, which causes countless errors in any code that made it
clear it was being passed by reference by using &string .

DECC also wants you to prototype all your routines and does argument checking.
However, the /PROTO=IDEN , although undocumented, does exist on VAX. (it is
documented on ALPHAs). This generates a .CH file that contains all function
prototypes for that compilation unit. It needs to be edited to remove some of
the crud, but that is very helpful. And you also need to edit it when, for
instance, inside a compilation unit, you expect a pointer to internal
structure, but from the outside world, you are just passing a opaque value, so
in the prototype, you need to edit that function's declaration to expect a
void * instead of structure chocolate_struct *.

DECC does point to tiny mistakes that you would have never caught and which
eventually get you on some odd situations you had not tested before.

When I converted to DECC, I bitched and was told that I would eventually
appreciate it. Now I am at a point where I would tell someone the same :-)

DECC forces greater discipline in coding compared to VAXC. Perhaps takes a bit
longer to do simple stuff, but in the end, I really feel that it forces you to
produce more robust code compared to VAXC.

[Nom de Plume]

Post by Z

Post by Larry Kilgallen
DEC C implements an extended ANSI C and runs on both VAX and Alpha.

Which can make badly written code break in rather mysterious
ways, like having -1 be greater than 100 in a comparison, for
example.
And /STANDARD=VAXC doesn't "fix" this.
A few other common gotchas with DEC C are leaving the VAX C
.OPT around and linking with VAXCRTL (bad!) and not realizing
that some functions (socket i/o funcs, IIRC) are not linked
in properly without the /PREFIX qualifier.

We ported a major application from VAX to Alpha and had to do some
serious rewrites. So, I know there is a lot more that has to be done
for complex situations. However, if one had some simple VAX code that
was not exactly ANSI and wanted the compiler on an Alpha system to
interpret it like the old VAX compiler, then /STANDARD=VAXC would be
appropriate.

JMOD

[Ed Vogel]

Post by Z
Which can make badly written code break in rather mysterious
ways, like having -1 be greater than 100 in a comparison, for
example.
And /STANDARD=VAXC doesn't "fix" this.

Would you post an example of this?

We know that users are still porting applications from
VAX C to (DEC/Compaq/HP) C. If this is an incompatiblity
we don't know about, it's difficult for us to fix.

Ed Vogel
HP C Engineering.

[Z]

Post by Ed Vogel

Post by Z
Which can make badly written code break in rather mysterious
ways, like having -1 be greater than 100 in a comparison, for
example.
And /STANDARD=VAXC doesn't "fix" this.

Would you post an example of this?

From memory: the promotion rules for different width/type
data elements in VAX C differed from ANSI C.

IIRC, the situation was: comparing a signed char (value < 0,
eg: -1) to an unsigned short/int (value > 0, eg: 100) would
"work" on VAX C - the -1 would be less than the 100 but on
DEC C, the -1 would be greater than the 100.

This wasn't a flaw in DEC C or VAX C, the rules had changed.

[Ed Vogel]

Post by Z
From memory: the promotion rules for different width/type
data elements in VAX C differed from ANSI C.
IIRC, the situation was: comparing a signed char (value < 0,
eg: -1) to an unsigned short/int (value > 0, eg: 100) would
"work" on VAX C - the -1 would be less than the 100 but on
DEC C, the -1 would be greater than the 100.
This wasn't a flaw in DEC C or VAX C, the rules had changed.

Thank you for the reply.

I expect you are refering to the difference between what the
standard calls "unsigned preserving" vs "value preserving"

It generally requires a situation more complex than the one you
list, but this is a difference between K & R C (VAX C) and
standard C.

While the initial releases of DEC C did not match
the VAX C behavior in this regard when /STAND=VAXC was
specified. This was fixed in 1998. So, when /STAND=VAX
is used, the DEC/Compaq/HP C compiler should use unsigned preserving
semantics just as VAX C did.

Ed Vogel
HP C Engineering

[nobody]

Post by Z
IIRC, the situation was: comparing a signed char (value < 0,
eg: -1) to an unsigned short/int (value > 0, eg: 100)

Ahh, OK. Yes, I agree. But that is why I always use /UNSIGNED when I compile
with DECC. This allows a "char" value to be treated as a full byte. (Being
french cnandian, this is necessary when you wish to habdle strings containing
accented characters).

It was absolutely stupid to decide that a "char" should be a signed value by default.

[Paul Repacholi]

Post by nobody

Post by Z
-1) to an unsigned short/int (value > 0, eg: 100)

Ahh, OK. Yes, I agree. But that is why I always use /UNSIGNED when
I compile with DECC. This allows a "char" value to be treated as a
full byte. (Being french cnandian, this is necessary when you wish
to habdle strings containing accented characters).
It was absolutely stupid to decide that a "char" should be a signed value by default.

No, it is the way some machines ARE. Having a language maybe slavishly
follow implemtation quirks on Tuesdays is perhaps stupid, but once you
have opened that can, the worms, signed or unsigned are yours to
enjoy.

Not having sign/unsigned/address relational operators, that is stupid.

[Hoff Hoffman]

In article <***@corp.supernews.com>, Z <***@no.spam> writes:
:Larry Kilgallen wrote:
:> DEC C implements an extended ANSI C and runs on both VAX and Alpha.
:
:Which can make badly written code break in rather mysterious
:ways, like having -1 be greater than 100 in a comparison, for
:example.

The compiler has flagged that coding error for some time now.
Diagnostics continue to improve, of course.

:A few other common gotchas with DEC C are leaving the VAX C
:.OPT around and linking with VAXCRTL (bad!)

I haven't tried this in some time, but I'd expect the contents
of the VAX C RTL to be ignored by the linker as the symbols are
not prefixed and thus not referenced. This gets ugly on the
compilations not using the typical library symbol prefixing.

... and not realizing
:that some functions (socket i/o funcs, IIRC) are not linked
:in properly without the /PREFIX qualifier.

The /PREFIX processing has been moving for some time now, and
the particular compiler behaviour cited was corrected some time
ago. The FAQ covers some of this, as well.

There have been extensive changes in newer C run-time libraries,
as well -- I hadn't read the manual in some time and was quite
surprised at the number and the scale of the added routines and
features.

Of course the best approach for all this does obviously involve
reading the available documentation, including the VAX C porting
guide available within the HP/Compaq/DEC C for OpenVMS VAX manual
set should VAX C code be involved.


---------------------------- #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

[nobody]

Post by Hoff Hoffman
:Which can make badly written code break in rather mysterious
:ways, like having -1 be greater than 100 in a comparison, for
:example.

Pardon my ignorance, what exactly is that problem ?

you mean code such as
if (-1 > 100) printf("Laws of mathematics have been revoked\n");

??

Post by Hoff Hoffman
:A few other common gotchas with DEC C are leaving the VAX C
:.OPT around and linking with VAXCRTL (bad!)

On VAX 7.2:

SEARCH/WINDOW=0 SYS$SYSTEM:*.EXE VAXCRTL reveals that the VMS engineers need
to spend a lot of time updating the build procedures for a lot of programs
that are still being linked against VAXCRTL.


It may be parity errors in my memory, but I seem to recall finding one image
that was linked against both VAXCRTL and DECCRTL. (probably some modules
compiled with vaxc and some with decc). But I can,t remember which one (or
perhaps they fixed this with 7.2).

Post by Hoff Hoffman
There have been extensive changes in newer C run-time libraries,
as well -- I hadn't read the manual in some time and was quite
surprised at the number and the scale of the added routines and
features.

Correct, when with VAXC, I had to write my own set of missing routines (strdup
comes to mind), and when I moved to DECC, I found myself with plenty of
duplicate definitions (but that was easy enough to fix).

[Z]

Post by nobody

Post by Hoff Hoffman
:Which can make badly written code break in rather mysterious
:ways, like having -1 be greater than 100 in a comparison, for
:example.

Pardon my ignorance, what exactly is that problem ?
you mean code such as
if (-1 > 100) printf("Laws of mathematics have been revoked\n");

Something like this was the problem:

...
char c = -1;
unsigned int i = 100;
if (c > i) printf("-1 is greater than 100!\n");
...

Ed Vogel indicates this was fixed in 1998, if you compile with
/STANDARD=VAXC. I ran into it in 1995 or 1996 doing a rather
large VAX/VAXC -> Alpha/DECC port.

That was a real head scratcher at first!

[Hoff Hoffman]

In article <***@posting.google.com>, ***@ix.netcom.com (ronald piazza) writes:

:What is the main difference between the DECC and VAXC compiler?

Look at the DEC C/Compaq C/HP C documentation for OpenVMS VAX.
There is a manual there that describes the various differences.

As Larry replies, VAX C is well over a decade old, and provides
the classic K&R C compiler interface, with various VAX extensions.
HP C (as DEC C is more currently known) provides ANSI C and (far)
more current C compilation standards and diagnostics.

See C coding information in the OpenVMS FAQ, and see topic (1661)
over in the Ask The Wizard area for other common C coding errors.
Also the Programming Concepts manual and the C documentation set.
If looking at the C documentation set, the C Run-Time Library
(RTL) manual that is now most current is the version that now
ships with OpenVMS itself, and no longer the version of the C
RTL manual that was shipped with the C compiler kit; see the
OpenVMS documentation set for the C RTL manual and not the C
documentation set.

If porting, move first to HP C on OpenVMS VAX, then move to
HP C on OpenVMS Alpha. This helps differentiate syntax errors
and latent bugs -- VAX C has syntax checks and code verification
capabilities befitting its 1991 release date -- from any Alpha
or I64 architectural differences or other related changes.

---------------------------- #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

[JF Mezei <"jfmezei"@]

Another difference is when you link.

With VAXC, you need to have an options file that points to SYS$LIBRARY:VAXCRTL.EXE/SHARE
With DECC, the C shareable RTL is automatically included, so you can just link
your executable without an options file.