Hi Perry, On Tue, 8 Sep 2015, Perry Ruiter wrote:
> I pushed a patch that used a C99 language feature (Gerritt 11858). > Ben caught that and felt the community should explicitly approve the use > of C99 language features rather than just have it happen by stealth with > patches going in that contain C99 extensions. > So what say ye all? C99 OK for 1.8 and later releases? ... Perry Thanks for bringing this to the list. In the abstract, I'm in favor of bringing in some C99 features -- they're quite useful, and it's been around for 16 years (more than half as long as AFS!). The only real barrier to adoption that I see is if there are specific platforms that do not have support for the features in question. If I remember correctly, Visual Studio did not gain support for C99 designated initializers until VS2015. At the workshop, we heard that AuriStor has to build with the latest compiler/toolchain for win10 certification, so that codebase should be compatible with a compiler that supports designated initializers. Unfortunately, I have the impression that it took a fair bit of work to get that codebase to that point, work which is not reflected in the current OpenAFS codebase, which I only ever got building with VS2005 (VS2008 is also documented to work, but newer versions than that are believed to not work). There may also be commercial Unices that do not ship full C99 compilers, though I don't remember which ones those might be, and in the absence of hard evidence we should not make decisions based on that concern. In some cases, there are workarounds or mitigating factors; code not built for windows does not necessarily need to cripple itself for the benefit of the windows compiler. gcc is available ~everywhere, even if the system compiler does not support C99 (but then again, it is required to use the system compiler to build kernel modules on some platforms), so userland code only used on Unix could avoid any concerns. But, "C99 for userland code only used on Unix" doesn't really feel very satisfying... -Ben _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
