[petsc-dev] Request for comments: allow C99 internally

[Richard Tran Mills]

I'll just add my vote: +1 to supporting the intersection of C99, C11, 
C++11, and later standards.

Also +1 to sadness that VLAs don't fall into there. (Though I understand 
the reasons why compiler developers might not want to support them.)

--Richard

On 3/11/20 8:34 AM, Jed Brown wrote:
> My proposal is for PETSc to support the intersection of C99, C11, C++11,
> and any later standards.  This (sadly*) excludes VLA.
>
> [*] I don't care about stack allocation, but VLA-pointers are extremely
> useful for multi-dimensional array indexing.  I'm sad that C11 made that
> optional.
>
> Jeff Hammond <jeff.science at gmail.com> writes:
>
>> I wonder if it is not more useful to talk in terms of C11 features.  Unlike
>> C99, C11 makes VLAs optional via __STDC_NO_VLA__, so you have a
>> standardized way of expressing the subset of C11 that is compatible with
>> C++11.  __STDC_NO_ATOMICS__ and __STDC_NO_THREADS__ play a similar role.
>>
>> Of course, some compilers refuse to use these properly, so PETSc will have
>> to check compiler support directly rather than trusting macros, but that is
>> nothing new and Jed (rightly) doesn't trust such compiler macros anyways.
>> I merely suggest that the macros correspond to an ISO C language definition
>> for describing the portable subset in a way that C99 cannot.
> I don't think the macros are of any utility in defining the
> intersection.  For example, g++ and clang++ do not set __STDC_NO_VLA__
> (and aren't expected to because they aren't C compilers), yet they don't
> support the syntax.
>
>    double (*a)[n] = (double (*)[n])p;
>
>    a[i][j] = 42;