<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic Re: C99 full compliance? in Operating System - OpenVMS</title>
    <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283615#M41614</link>
    <description>See /STANDARD=COMMON&lt;BR /&gt;&lt;BR /&gt;This switch won't help you here, as the qualifier selects the compiler settings and not the library references.  (And it's ancient.)&lt;BR /&gt;&lt;BR /&gt;As for your general question...&lt;BR /&gt;&lt;BR /&gt;C on VMS is confusingly organized into various pieces.  &lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;There are the C-provided C header files, which are not C99 compliant.  These are provided by the compiler.&lt;BR /&gt;&lt;BR /&gt;There are also the VMS-provided C header files, which are not relevant to C99.  These are specific to VMS versions.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://labs.hoffmanlabs.com/node/1424" target="_blank"&gt;http://labs.hoffmanlabs.com/node/1424&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;</description>
    <pubDate>Sat, 04 Jun 2011 17:42:15 GMT</pubDate>
    <dc:creator>Hoff</dc:creator>
    <dc:date>2011-06-04T17:42:15Z</dc:date>
    <item>
      <title>C99 full compliance?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283611#M41610</link>
      <description>Is there a roadmap anywhere for implementation of&lt;BR /&gt;full C99 compliance in the Alpha C compiler?&lt;BR /&gt;We're currently running the latest version,&lt;BR /&gt;V7.3-009 which dates from mid-2007.  The&lt;BR /&gt;documentation for this release implies that&lt;BR /&gt;full C99 compliance will be in a post-7.3&lt;BR /&gt;release.&lt;BR /&gt;I have an urgent porting project that complains&lt;BR /&gt;about missing symbols at link time (notably&lt;BR /&gt;GETOPT_LONG).  Four years seems a long time to&lt;BR /&gt;get full C99 compliance.</description>
      <pubDate>Wed, 01 Jun 2011 02:09:22 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283611#M41610</guid>
      <dc:creator>Gareth Williams_2</dc:creator>
      <dc:date>2011-06-01T02:09:22Z</dc:date>
    </item>
    <item>
      <title>Re: C99 full compliance?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283612#M41611</link>
      <description>Yes it's time for C99!&lt;BR /&gt;&lt;BR /&gt;...but GETOPT_LONG is not C99 nor Posix, it is a GNU routine.&lt;BR /&gt;It is part of GNU sh-utils, and probably all other GNU packages in the lib/ directory (getopt.c, getopt1.c).&lt;BR /&gt;&lt;BR /&gt;Whenever I have to compile a program containing GNU getopt, I compile with &lt;BR /&gt;cc/prefix=(all,except=(getopt,optarg,optopt,optind,opterr))&lt;BR /&gt;and use the GNU getopt.h include.&lt;BR /&gt;</description>
      <pubDate>Wed, 01 Jun 2011 05:38:01 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283612#M41611</guid>
      <dc:creator>Joseph Huber_1</dc:creator>
      <dc:date>2011-06-01T05:38:01Z</dc:date>
    </item>
    <item>
      <title>Re: C99 full compliance?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283613#M41612</link>
      <description>You'll want to ask HP formally.   &lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.  &lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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: &lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/contrib/file/getopt_long.c?rev=1.3&amp;amp;content-type=text/x-cvsweb-markup&amp;amp;logsort=cvs&amp;amp;f=h" target="_blank"&gt;http://www.jp.freebsd.org/cgi/cvsweb.cgi/src/contrib/file/getopt_long.c?rev=1.3&amp;amp;content-type=text/x-cvsweb-markup&amp;amp;logsort=cvs&amp;amp;f=h&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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):&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://labs.hoffmanlabs.com/node/878" target="_blank"&gt;http://labs.hoffmanlabs.com/node/878&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;</description>
      <pubDate>Wed, 01 Jun 2011 13:26:30 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283613#M41612</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2011-06-01T13:26:30Z</dc:date>
    </item>
    <item>
      <title>Re: C99 full compliance?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283614#M41613</link>
      <description>Hmm.  I don't see /STANDARD=GCC in the help file and CC/STANDARD=GCC produces an unrecognized keyword error.</description>
      <pubDate>Sat, 04 Jun 2011 15:28:31 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283614#M41613</guid>
      <dc:creator>Gareth Williams_2</dc:creator>
      <dc:date>2011-06-04T15:28:31Z</dc:date>
    </item>
    <item>
      <title>Re: C99 full compliance?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283615#M41614</link>
      <description>See /STANDARD=COMMON&lt;BR /&gt;&lt;BR /&gt;This switch won't help you here, as the qualifier selects the compiler settings and not the library references.  (And it's ancient.)&lt;BR /&gt;&lt;BR /&gt;As for your general question...&lt;BR /&gt;&lt;BR /&gt;C on VMS is confusingly organized into various pieces.  &lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;There are the C-provided C header files, which are not C99 compliant.  These are provided by the compiler.&lt;BR /&gt;&lt;BR /&gt;There are also the VMS-provided C header files, which are not relevant to C99.  These are specific to VMS versions.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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:&lt;BR /&gt;&lt;BR /&gt;&lt;A href="http://labs.hoffmanlabs.com/node/1424" target="_blank"&gt;http://labs.hoffmanlabs.com/node/1424&lt;/A&gt;&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;</description>
      <pubDate>Sat, 04 Jun 2011 17:42:15 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283615#M41614</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2011-06-04T17:42:15Z</dc:date>
    </item>
    <item>
      <title>Re: C99 full compliance?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283616#M41615</link>
      <description>&amp;gt;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.&lt;BR /&gt;&lt;BR /&gt;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.</description>
      <pubDate>Sat, 04 Jun 2011 18:35:38 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283616#M41615</guid>
      <dc:creator>Dennis Handly</dc:creator>
      <dc:date>2011-06-04T18:35:38Z</dc:date>
    </item>
    <item>
      <title>Re: C99 full compliance?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283617#M41616</link>
      <description>I'm a Fortran programmer and I dislike C&lt;BR /&gt;(intensely) precisely because of the sort of&lt;BR /&gt;problems experienced here.  This is an issue&lt;BR /&gt;with a one-off port.&lt;BR /&gt;&lt;BR /&gt;Following the advice of the respondents,&lt;BR /&gt;I've downloaded getopt_long.c and the&lt;BR /&gt;getopt_1.1.4.tar.gz file.  I will see if these&lt;BR /&gt;fix the compilation problems.  Thanks!</description>
      <pubDate>Sat, 04 Jun 2011 21:55:34 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283617#M41616</guid>
      <dc:creator>Gareth Williams_2</dc:creator>
      <dc:date>2011-06-04T21:55:34Z</dc:date>
    </item>
    <item>
      <title>Re: C99 full compliance?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283618#M41617</link>
      <description>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.  &lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;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.&lt;BR /&gt;&lt;BR /&gt;Programming tools and IDEs are moving way too fast to get cranky about C, or about a C port.</description>
      <pubDate>Sun, 05 Jun 2011 15:46:21 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283618#M41617</guid>
      <dc:creator>Hoff</dc:creator>
      <dc:date>2011-06-05T15:46:21Z</dc:date>
    </item>
    <item>
      <title>Re: C99 full compliance?</title>
      <link>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283619#M41618</link>
      <description>&lt;!--!*#--&gt;Knowing nothing about C99 compliance, I&lt;BR /&gt;ignored this thread until now, when I see&lt;BR /&gt;that the actual subject was apparently the&lt;BR /&gt;lack of some GNU library code in some&lt;BR /&gt;still-unnamed "porting project", and nothing&lt;BR /&gt;to do with C99.  Sometimes a relevant subject&lt;BR /&gt;(based on actual observations) can be more&lt;BR /&gt;helpful than one biased by a faulty analysis&lt;BR /&gt;of the problem.&lt;BR /&gt;&lt;BR /&gt;In most of the GNU(-like) code I've tried to&lt;BR /&gt;get to work on VMS, if the source kit needed&lt;BR /&gt;GNU-exotics like GNU-getopt, then it has&lt;BR /&gt;included the required GNU-getopt source, so&lt;BR /&gt;the only real requirement was to adjust the&lt;BR /&gt;builders to use the local getopt stuff,&lt;BR /&gt;instead of the VMS C RTL getopt stuff.&lt;BR /&gt;&lt;BR /&gt;&amp;gt; cc/prefix=(all,except=(getopt,optarg,optopt,optind,opterr)) &lt;BR /&gt;&lt;BR /&gt;Like that, for example.  But, with a&lt;BR /&gt;description like "urgent porting project",&lt;BR /&gt;it's tough to guess what's in (or missing&lt;BR /&gt;from) the particular source kit involved&lt;BR /&gt;here.</description>
      <pubDate>Mon, 06 Jun 2011 03:36:06 GMT</pubDate>
      <guid>https://community.hpe.com/t5/operating-system-openvms/c99-full-compliance/m-p/5283619#M41618</guid>
      <dc:creator>Steven Schweda</dc:creator>
      <dc:date>2011-06-06T03:36:06Z</dc:date>
    </item>
  </channel>
</rss>

