[Info-vax] C99 updates to CRTL

[Arne Vajhøj]

On 7/27/2019 1: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.

>> To utilize these functions, compile your applications with the
>> /STANDARD=C99, /STANDARD=LATEST or /STANDARD=RELAXED (default)
>> switches.

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

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

I am not an expert in C headers or the finer points in the various
C standards.

But I have this feeling that there are or will be a need
to be able to chose between modern and compatibility.

Aka:

$ CC/MODERN ...

or:

$ DEFINE DECC$STYLE "MODERN"
$ CC ...

vs:

$ CC/COMPATIBILITY ...

or:

$ DEFINE DECC$STYLE "COMPATIBILITY"
$ CC ...

Where the two different styles set different defines, have
different interpretation of other qualifiers and headers can
do:

#if (defined(__COMPATIBILITY_STYLE) && ...) || (defined(__MODERN_STYLE) 
&& ...)
...
#endif
#if (defined(__COMPATIBILITY_STYLE) && ...)
...
#endif
#if (defined(__MODERN_STYLE) && ...)
...
#endif

The people that need compatibility to build old code chose that style.

The people that want to move forward can get a reasonable sensible
experience (at the cost that some 20-30 year old code may not compile).

Arne