ior does not build without CFLAGS=-std=gnu99

[glennklockwood]

A number of recent changes have essentially required that

1. the code be compiled with C99 support, as there are now pieces that violate c89 (e.g., for (int i = 0; ...)
2. there appear to be problems with certain gnuisms at link time (not sure if this is a #ifdef _GNU_SOURCE type of issue or what)

In particular, I am having lots of problems compiling ior's master using the Cray MPI environment (CLE6) and the Intel compiler, but I don't have the time to debug right now. In the long term, we should decide if we are OK with requiring C99 (and if so, add that to autoconf).

My personal preference is to use strict c89 and add that to the regression tests' compiler flags so we catch non-compliant C.

[hjelmn]

AC_PROG_CC_C99 in the configure will do it. I think it is safe for IOR to require C99 or even just jump to C11. FWIW, Open MPI requires C99 now and will require C11 in the future.

[JulianKunkel]

I'm in favor of going to C99 at least. There shouldn't be any compiler nowadays that does not do C99. Nathan Hjelm <notifications@github.com> schrieb am Di., 2. Okt. 2018, 03:06:

…

AC_PROG_CC_C99 in the configure will do it. I think it is safe for IOR to require C99 or even just jump to C11. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#93 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1uyq6QrbpkHWSE7zRIF7fytZcKoIOUks5ugspAgaJpZM4XDJWh> .

[hjelmn]

Indeed. Even Microsoft supports C99 now for the most part. They were the lone holdout for a long time. As of 2018 icc, gcc, pgcc, xlc, and sun cc all support all of C99 and most/all of C11.

[glennklockwood]

It turns out we already require C99 so the first half of this issue is not actually an issue. However the fact remains that -std=c99 reveals a bunch of not-strictly-compliant behavior such as

  CC       libaiori_a-ior.o
../../src/ior.c(182): warning #266: function "strdup" declared implicitly
          p->api = strdup(default_aiori);
                   ^

This is an issue of what magic switches autoconf should be looking for and shouldn't be hard to fix.

More critically though, the following error is fatal:

../../src/parse_options.c(543): error: identifier "optarg" is undefined
            initialTestParams.memoryPerNode = NodeMemoryStringToBytes(optarg);
                                                                      ^

compilation aborted for ../../src/parse_options.c (code 2)

I'll work on getting this all compiling using standard C.

[JulianKunkel]

Great. The optarg one is a bug. Since the option parser is rewritten, there should not be the need of using optarg. Glenn K. Lockwood <notifications@github.com> schrieb am Di., 2. Okt. 2018, 05:51:

…

It turns out we already require C99 so the first half of this issue is not actually an issue. However the fact remains that -std=c99 reveals a bunch of not-strictly-compliant behavior such as CC libaiori_a-ior.o ../../src/ior.c(182): warning #266: function "strdup" declared implicitly p->api = strdup(default_aiori); ^ This is an issue of what magic switches autoconf should be looking for and shouldn't be hard to fix. More critically though, the following error is fatal: ../../src/parse_options.c(543): error: identifier "optarg" is undefined initialTestParams.memoryPerNode = NodeMemoryStringToBytes(optarg); ^ compilation aborted for ../../src/parse_options.c (code 2) I'll work on getting this all compiling using standard C. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#93 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AE1uynM3tyX6E82NaeyTunw4AwK1Q60wks5ugvC4gaJpZM4XDJWh> .

[glennklockwood]

Making IOR actually comply with POSIX C now will require code changes that I don't want to hammer out before the 3.2 release, so this will have to wait until after 3.2.

In particular, we use usleep(3) which was removed from POSIX.1-2008 in favor of nanosleep(3), and there is some nuance to putenv/setenv that I would like to clear up as time permits.

[JulianKunkel]

I made the changes from usleep to nanosleep at least.

[glennklockwood]

Thanks! I will try to get the rest of the patches tidied up and make a PR soon.