Adding a C standard qualifier to the VFX Reference Platform spec

[Neal Gompa]

Hey folks,

The discussion around the CY2024 draft triggered a thought from me
that we should probably have the C standard revision specified just
like we do for C++.

There are a couple of reasons for why we should do this:

1. The C standard *does change*, especially in potentially incompatible ways
2. C compilers are looking to tighten conformance and update default standards

Today, most compilers default to C99, but there's an effort going on
to update the default standard for compilers to the next one (C23) and
the C23 standard will attempt to try to improve interoperability of
mixed C and C++ code by bringing in keywords, capabilities, and
structures from C++23 to C23 where it makes sense.

Within the Linux distribution space, there's an effort to update C
codebases to work with the newer C standard in preparation for this
switch by compilers coming up soon.

In particular, GCC 14 will be updating the default behaviors for C
code compilation to align more with C23:
https://fedoraproject.org/wiki/Changes/PortingToModernC

To that end, I expect that we're going to see compilers refresh their
default behaviors more frequently to conform with the latest standards
in C like they do with C++ today.

For the VFX platform, this means you can no longer implicitly rely on
your compiler using the same C standard behavior it always has used.
You need to specify it, just like you do for C++ code.

I would like to request that all previous standards retroactively have
C99 marked, and we start thinking about C18 for a future update along
with the refresh to C++20.

This would align with the largest Qt 6-based project (KDE). Note that
Qt 6 *requires* at least C++17 compatibility (which I expect is fine
by most folks now), but KDE Frameworks 6 requires C++20 (as a note for
anyone using KDE Frameworks in their projects/products/etc.).

For now, there's no need to change anything, I would just like us to
have the C standard specified alongside the C++ one. In the future, we
should consider C standard upgrades alongside C++ standard upgrades.

Thanks in advance and best regards,
Neal


--
真実はいつも一つ！/ Always, there's only one truth!

[Edward Lam]

On Thu, May 18, 2023 at 9:38 PM Neal Gompa wrote:

I would like to request that all previous standards retroactively have
C99 marked, and we start thinking about C18 for a future update along
with the refresh to C++20.

I'd like to point out that Visual Studio 2022 (which is part of the platform) only supports up to C17 [1]. Given that major releases of Visual Studio have been generally following a 3 year cadence, the next major release will most likely occur in 2025. But even then, I'd not get my hopes up as they traditionally lag very much with regards to implementing C standards although they seem to be much better in recent years.

 

Best regards,

-Edward

1. https://learn.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-170

[Michael Rochefort]

On Thursday, May 18, 2023 at 10:17:29 PM UTC-4 triplequ...@gmail.com wrote:

I'd like to point out that Visual Studio 2022 (which is part of the platform) only supports up to C17 [1].

The use of "-std=c17" or "-std=c18" should provide identical results as they reference the same standard. However, if MSVC only supports the C17 designation, that can be defined for the platform just fine.

It would be good to check if CMake abstracts that away so on Windows the use of C18 gets passed along as C17.

Cheers,

Mike

[Michael Rochefort]

On Thursday, May 18, 2023 at 10:22:22 PM UTC-4 Michael Rochefort wrote:

It would be good to check if CMake abstracts that away so on Windows the use of C18 gets passed along as C17.

After a quick check here[0], it looks like CMake takes 90, 99, 11, 17, and 23 as possible values to the C_STANDARD parameter. The use of whether or not extension variants should be used (e.g. gnu17 vs c17) is governed by the C_EXTENSIONS[1] parameter.

[0] https://cmake.org/cmake/help/latest/prop_tgt/C_STANDARD.html

[1] https://cmake.org/cmake/help/latest/prop_tgt/C_EXTENSIONS.html

Cheers,

Mike

[Edward Lam]

(Sorry for the repost as I neglected to hit Reply All the first time)

On Thu, May 18, 2023 at 9:38 PM Neal Gompa wrote:

The discussion around the CY2024 draft triggered a thought from me
that we should probably have the C standard revision specified just
like we do for C++.

There are a couple of reasons for why we should do this:

1. The C standard *does change*, especially in potentially incompatible ways
2. C compilers are looking to tighten conformance and update default standards

On second thought, I thought all the VFX Platform projects build as C++?  If that is the case, does it matter whether the VFX Platform specifies a C standard?

Best regards,

-Edward

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAEg-Je-chqhrZF-dahj%3DLmSuL4KLySb5t3Camr%3DoVeNqRUCeFA%40mail.gmail.com.

--

Support GOToronto by rating us in the App Store!

[Edward Lam]

On Thu, May 18, 2023 at 10:50 PM Edward Lam wrote:

On second thought, I thought all the VFX Platform projects build as C++?  If that is the case, does it matter whether the VFX Platform specifies a C standard?

Ah, except for oneMKL of course, but then it's not an open source project and it's a library that probably mostly uses basic C interfaces and won't matter too much.

-Edward

[Michael Rochefort]

Industry projects, not particularly. However, Python is a C project that is often built and bundled with DCCs. I do not know if vendors are authoring their DCC Python bindings via C, C++ or a mix of both.

The default C standard for GCC 11.x[0] is GNU17, and starting with Python 3.11 (the currently proposed CY2024 version) the CPython project shifted from C89+C99 to C11 as their base standard[1].

Cheers,

Mike

[0] https://gcc.gnu.org/onlinedocs/gcc-11.3.0/gcc/Standards.html

[1] https://peps.python.org/pep-0007/#c-dialect

 

[Deke Kincaid]

OpenEXR 3.1 added C Api/libraries in the last couple years but yes, a majority of the vfxplatform is c++.

--

You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/CAJZe6MAGwwE4m15gUoJ2Pnw0Lt7pm3QbUDsKipFk2yrMOL%2BtjQ%40mail.gmail.com.

[Larry Gritz]

I think most of the problems VFX Platform is meant to solve are really about ABI/link incompatibilities. That crops up all the time in C++ (exacerbated by name mangling, vtable layout, and other issues particular to C++), which is why it's wise to pick the same C++ standard and compiler if you really want to be sure that separately compiled components will play nice together. But C ABI is incredibly stable and in many ways is locked down by the fact that it's also the interface to the OS calls and FFI interop.

Remember also that VFX Platform is not intended to be a prescriptive list of what to use, but rather document the components that have historically been problematic in the absence of the DCCs (and plugins thereof) sticking to a single version in any given year.

Neither of these views of what's on VP and why really point to any imperative to dictate a C standard at this time, in my view.

There is a sense in which projects with C APIs should be aware of C23 and ensure that they are migrating towards being "safe" to compile in 23 mode -- for example, making sure you don't have any public identifiers that are coincidentally any of the new keywords like 'bool' or 'thread_local'. But I think that's the kind of thing that should be ensured by each project's CI (your CI test matrix should include building with several compilers and at different standard levels), I'm not sure why a version needs to be locked down in VFX Platform.

On May 18, 2023, at 9:05 PM, Deke Kincaid <dekek...@gmail.com> wrote:

OpenEXR 3.1 added C Api/libraries in the last couple years but yes, a majority of the vfxplatform is c++.

On Thu, May 18, 2023 at 8:39 PM Edward Lam <triplequ...@gmail.com> wrote:

On Thu, May 18, 2023 at 10:50 PM Edward Lam wrote:

On second thought, I thought all the VFX Platform projects build as C++?  If that is the case, does it matter whether the VFX Platform specifies a C standard?

Ah, except for oneMKL of course, but then it's not an open source project and it's a library that probably mostly uses basic C interfaces and won't matter too much.

-Edward

--

Larry Gritz

l...@larrygritz.com

[Michael Rochefort]

These are some good points. If there's one thing to point out, a group that may/may not be impacted by the changes the compilers and standards imply is OpenEXR. Since 3.1, with further developments in the upcoming 3.2 release slated for CY2024 if available in time, OpenEXR has a new underlying library I just learned about the other day (thanks JF!) that exposes low level core technology as a C API (libOpenEXRCore).

https://github.com/AcademySoftwareFoundation/openexr/tree/main/src/lib/OpenEXRCore

Whether or not there is an impact here is beyond my skillset. But, I think you're on the right track Larry in regards to the ABI conflicts that shouldn't be as prevalent with C (though it may be good to test some things out just in case, like using a newer standard or disabling the legacy features).

Cheers,

Mike

---- On Fri, 19 May 2023 11:58:08 -0400 Larry Gritz <l...@larrygritz.com> wrote ---

--
You received this message because you are subscribed to the Google Groups "vfx-platform-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vfx-platform-dis...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/08BAE550-07F4-4193-8D29-64EB1BE6DA6D%40larrygritz.com.

[Larry Gritz]

There's nothing in the OpenEXR C interface that should be problematic, beyond being sure that we test compile it with C23 to be sure we haven't used the new reserved words as identifiers. Short of that, I'm not sure how it could break anything.

-- lg

To view this discussion on the web visit https://groups.google.com/d/msgid/vfx-platform-discuss/1883b72314d.12a7b6605590828.8569149901139570224%40michaelrochefort.com.

--

Larry Gritz

l...@larrygritz.com