C99 full compliance?

[Gareth Williams_2]

Is there a roadmap anywhere for implementation of
full C99 compliance in the Alpha C compiler?
We're currently running the latest version,
V7.3-009 which dates from mid-2007. The
documentation for this release implies that
full C99 compliance will be in a post-7.3
release.
I have an urgent porting project that complains
about missing symbols at link time (notably
GETOPT_LONG). Four years seems a long time to
get full C99 compliance.

[Joseph Huber_1]

Yes it's time for C99!

...but GETOPT_LONG is not C99 nor Posix, it is a GNU routine.
It is part of GNU sh-utils, and probably all other GNU packages in the lib/ directory (getopt.c, getopt1.c).

Whenever I have to compile a program containing GNU getopt, I compile with
cc/prefix=(all,except=(getopt,optarg,optopt,optind,opterr))
and use the GNU getopt.h include.

[Hoff · Accepted solution]

You'll want to ask HP formally.

Other than as a source of the usual commiseration (see below), ITRC postings don't usually get you where you want to be with these sorts of formal "when?" questions.

The VMS C compiler reportedly has full C99 support, while it is the VMS C RTL and the C header files that are not yet C99 compliant.

While the getopt_long() call has been around in various open-source projects for many years now (and as was mentioned earlier), it's not part of C99, nor IEEE Std 1003.1-2008, nor do I see it listed in the current C1X draft. Which means you're seeking better gcc compatibility here and not specifically better C99 compliance.

The existing CC /STANDARD=GCC compliance is very old, supporting somewhere around gcc 2.8, where gcc is around 4.7, and where llvm/clang is also progressing rapidly.

The source code to the getopt_long() routine is available. Both GPL'd versions and BSD-licensed version are around and variously ported, and here's a BSD version that might be ported over:

http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/contrib/file/getopt_long.c?rev=1.3&content-type=text/x-cvsweb-markup&logsort=cvs&f=h

The 2003, 2004 and 2008 revisions are also around, and the C1X standard is progressing, and modern gcc and llvm/clang versions both include changes from/for the C1X draft.

Not all pieces of C99 are supported by all compilers. llvm/clang isn't there: "The support for standard C in clang is feature-complete except for the C99 floating-point pragmas", for instance. I don't know off-hand if gcc is compliant; when last I checked, it wasn't, but this stuff is a moving target.

For those that are interested in what C99 brings with it, there are links to details here (written by somebody that used to work on the VMS C pieces, by coincidence):

http://labs.hoffmanlabs.com/node/878

And yes, there are pieces within C1X around alignment and threading that would be handy to have, as well as features of gcc and the glibc libraries.

[Gareth Williams_2]

Hmm. I don't see /STANDARD=GCC in the help file and CC/STANDARD=GCC produces an unrecognized keyword error.

[Hoff]

See /STANDARD=COMMON

This switch won't help you here, as the qualifier selects the compiler settings and not the library references. (And it's ancient.)

As for your general question...

C on VMS is confusingly organized into various pieces.

There's the compiler and its various and sundry compilation modes, and the compiler itself is probably compliant with the C99 features that are implemented by the compiler.

There are the C-provided C header files, which are not C99 compliant. These are provided by the compiler.

There are also the VMS-provided C header files, which are not relevant to C99. These are specific to VMS versions.

There is the C library, which is not C99, and which can also be tied to the most recent C patches and (for various features) into dependencies on specific features that can be available in the underlying OpenVMS implementation.

Recent C compilers don't update the C header file reference directories and don't create the reference directories during new installations, so the system manager can want to perform post-installation steps to keep these directories current. Here is some DCL:

http://labs.hoffmanlabs.com/node/1424

Beyond assumptions around mainstream C99 support and on parts of C1X, C applications are increasingly targeting and assuming compliance with the gcc and llvm/clang compilers and particularly with the associated C libraries. And as is the case here; this isn't the compiler centrally at fault, it's the (lack of) compatibility with the de facto standard C libraries.

Secondary to your discussions with HP around moving C forward with better GCC compatibility and/or full C99 support, your best path forward is to not bother with the GCC compatibility (again, it's ancient) and to haul over your own version of getopt_long() from one of the various available resources and sites.

[Dennis Handly]

>Hoff: The VMS C compiler reportedly has full C99 support, while it is the VMS C RTL and the C header files that are not yet C99 compliant.

Yes, that's usually the hold up. That and the math lib. On HP-UX, it took from 2004 to 2007 until HP-UX 11.31 was released.

[Gareth Williams_2]

I'm a Fortran programmer and I dislike C
(intensely) precisely because of the sort of
problems experienced here. This is an issue
with a one-off port.

Following the advice of the respondents,
I've downloaded getopt_long.c and the
getopt_1.1.4.tar.gz file. I will see if these
fix the compilation problems. Thanks!

[Hoff]

For the purposes of your own career here, consider dialing back your manifest dislike of C, and spend some time learning a few newer programming languages. That might well be C or a C derivative, or Lua, Python, or any of the other and newer languages.

And also some time learning what Fortran 2003 and Fortran 2008 can bring here, though these are unfortunately not implemented in the OpenVMS Fortran compilers. The VMS Fortran compilers are limited to Fortran 95. Pointers are available in your current compilers, but pointer updates and function pointers and better C interoperation and a pile of useful features arrive with the newer standards.

Fortran is good at various tasks, and the newer Fortran tools yet better, and other languages can really be helpful to your career and to your employer.

Programming tools and IDEs are moving way too fast to get cranky about C, or about a C port.

[Steven Schweda]

Knowing nothing about C99 compliance, I
ignored this thread until now, when I see
that the actual subject was apparently the
lack of some GNU library code in some
still-unnamed "porting project", and nothing
to do with C99. Sometimes a relevant subject
(based on actual observations) can be more
helpful than one biased by a faulty analysis
of the problem.

In most of the GNU(-like) code I've tried to
get to work on VMS, if the source kit needed
GNU-exotics like GNU-getopt, then it has
included the required GNU-getopt source, so
the only real requirement was to adjust the
builders to use the local getopt stuff,
instead of the VMS C RTL getopt stuff.

> cc/prefix=(all,except=(getopt,optarg,optopt,optind,opterr))

Like that, for example. But, with a
description like "urgent porting project",
it's tough to guess what's in (or missing
from) the particular source kit involved
here.