[Info-vax] C99 updates to CRTL

[John Reagan]

On Saturday, July 27, 2019 at 4:57:00 PM UTC-4, Craig A. Berry wrote:
> On 7/27/19 12:12 PM, John Reagan wrote:
> > On Saturday, July 27, 2019 at 9:53:07 AM UTC-4, Craig A. Berry wrote:
> >> On 7/20/19 3:56 AM, Jan-Erik Söderholm wrote:
> >>> VMS Software, Inc. is pleased to announce enhancements and updates
> >>> to the C Run Time Library to provide support for C99 Standard
> >>> functions which were not previously available.
> >>
> >> stdint.h is there, though I have not looked carefully at its contents.
> >> fpclassify appears to work as advertised, but I have not looked into
> >> other math.h functions.  However, isblank does not work as advertised,
> >> and I stopped looking further when I realized what's up with isblank.
> >> The docs that come with the C99 CRTL update says the following regarding
> >> all the new functions:
> >>
> >> ------
> >> To utilize these functions, compile your applications with the
> >> /STANDARD=C99, /STANDARD=LATEST or /STANDARD=RELAXED (default)
> >> switches.
> >> ------
> >>
> >> So one would reasonably expect that any of these switches would be
> >> sufficient to get the new functions.  But it isn't true.  Here is a
> >> little test program:
> >>
> >> $ type test_isblank.c
> >> #include <ctype.h>
> >> int main() {
> >> 	int c = ' ';
> >> 	if (isblank(c))
> >> 		return 0 ;
> >> 	else
> >> 		return 1 ;
> >> }
> >>
> >> Compiling with the default (equivalent to /STANDARD=RELAXED_ANSI) gives:
> >>
> >> $ cc test_isblank
> >>
> >> 	if (isblank(c))
> >> ............^
> >> %CC-I-IMPLICITFUNC, In this statement, the identifier "isblank" is
> >> implicitly declared as a function.
> >> at line number 4 in file D0:[craig.TEST]test_isblank.c;1
> >>
> >> So while that's "only" an informational message, the prototype is hidden
> >> and no self-respecting configuration probe will end up deciding that the
> >> isblank function exists in the C library.
> >>
> >> Compiling with /STANDARD=C99 does work:
> >>
> >> $ cc/standard=c99 test_isblank
> >>
> >> The documentation under HELP CC/STANDARD says:
> >>
> >> -----
> >> C99 is a superset of Amendment 1 to the C89 standard, and the default
> >> mode of RELAXED is a superset of C99.
> >> -----
> >>
> >> and yet the actual implementation of RELAXED for the new functions is
> >> now a subset, not a superset, of C99.
> >>
> >> A hint about what's wrong is visible from a listing snippet from
> >> compiling with the relaxed standard:
> >>
> >>    I1    X    566 #if defined(__DECC) && (__DECC_VER >= 60400000) &&
> >> (__STDC_VERSION__ >= 199901L) && defined(_ANSI_C_SOURCE) /* C99 *
> >>    I1    X    566 /
> >>    I1    X    567 int isblank  (int);
> >>    I1    X    568 #endif
> >>
> >> The _ANSI_C_SOURCE requirement is what hides this function and setting
> >> that macro explicitly does get the example to compile without warnings:
> >>
> >> $ cc/define="_ANSI_C_SOURCE" test_isblank
> >>
> >> However, defining that breaks a ton of things.  It disables all DEC C
> >> extensions, such as the optional RMS arguments to the standard I/O
> >> functions, and hides lots of functions that are de facto standards but
> >> not specified by ANSI, such as setjmp and strnlen (to name only two I
> >> stumbled across in a quick look around the headers).  pthread.h says,
> >> "_ANSI_C_SOURCE (ANSI C) will disable thread support."  Ouch.
> >>
> >> Needless to say, it's a bit disappointing after waiting so long for C99
> >> support to be completed that it got delivered in a form that is not
> >> actually workable in the real world.
> > 
> 
> > My apologies. We did do testing but obviously not enough. I'll pass
> > it along.
> > 
> > The extra difficult is what some things that used to be DEC
> > extensions to C89 became standard with C99. All those symbols are a PITA. We need
> > to work harder on them.
> 
> Thanks.  I can imagine it's quite a tangle with all the prior art in the
> CRTL and getting this out without an OS or compiler upgrade.  It did
> seem odd to me that __CRTL_VER did not get bumped and the new CRTL
> claims to be the same version as the one that shipped with v8.4, but
> maybe that's something that cannot change without a compiler change.
> 
> As far as I know, the only reason to guard a function's prototype with
> _ANSI_C_SOURCE is if you offer two different implementations of it, one
> of which conflicts with the standard one.  Arguably this isn't even
> necessary for the stdio functions with the RMS options because those
> don't *conflict* with the standard, they just extend it with optional
> arguments; a standard-compliant call would still work as-is.  But I know
> the ship has long since sailed on those.

I suspect the person who did the work for me decided not to bump the version since no new entry points were added to the transfer vector.  Of course, that would just be part of the algorithm.  We'll go look and spin a new kit as needed.