Move on to C99

[fmertz]

For the next major release, look into moving the project C code base to C99. Everything moves forward, including the language itself. Maybe it is time this project formally adopts C99. As folks are making proposals for important code changes, choosing the language version early would help.

https://en.wikipedia.org/wiki/C99

[haraldg]

Do you have anything specific in mind? Our current code base definitively includes code that uses C99 features (though they probably have been available as compiler extensions for long) yet we also have a lot of #ifdefs and other annoyances to support ancient systems. While I'm removing some extreme examples every now and then, I largely leave things as they are: Who knows where lcdproc is still in use?

So what are you aiming for, actually? Without a list of actionable items I think this ticket is pretty much a noop.

As far as I'm concerned (e.g. when reviewing code) I'm happy with everything that compiles with gcc+glibc and gcc+musllibc and rely that people speak up, when we introduce a compatibility problem. That's one reason to have release candidates for people to test.

BTW to me it seems having to support old versions of the posix standard is much more an issue than the C standard.

[fmertz]

Do you have anything specific in mind?

While I was working on this new EZIO driver, I wrote something like this:

for (unsigned char c=0; ...

The compiler complained, and I had to separate the declaration. Definitely not a big seal, just that I was thinking we could move on with the times. Our open source project should be fun to contribute to, and part of it is using modern language features, I suppose.

After working on this driver, I thought I could change my local build system to add gcc's -std option and recompile the whole project. If I have tons of errors, then forget it. If I have a few errors, then maybe propose a pull request with fixes. It would mean that from that point forward, we could have contributions with the newer comments style, the more compact for loops with declarations, compound literals, etc. As of now, unless I missed something, only ANSI C is allowed.

So what are you aiming for, actually?

Ultimately, change the build system to compile everything with -std=c99

[haraldg]

fmertz writes:

While I was working on this new EZIO driver, I wrote something like this: `for (unsigned char c=0; ...` The compiler complained, and I had to separate the declaration.

This must be a problem of your local installation. Nothing in lcdproc tells the compiler not to allow such a construct. Fix your CFLAGS and AFAIK you will be fine. That said, I'm not a big fan of these surprise declarations: I always find it a bit annoying to have to look into multiple places, when reviewing code. However I'd have merged this code without comment, had it been proposed in a PR.

After working on this driver, I thought I could change my local build system to add gcc's -std option and recompile the whole project. If I have tons of errors, then forget it. If I have a few errors, then maybe propose a pull request with fixes.

Fixing all warnings and changing the travis build to treat warnings as errors, would be a useful project too. Anybody?

It would mean that from that point forward, we could have contributions with the newer comments style, the more compact for loops with declarations, compound literals, etc.

We have the coding style in the developers guide, which is much stricter then any language spec. (The coding style wasn't written by me, just mentioning it.) You will need to propose a PR for that one too ... ;)

As of now, unless I missed something, only ANSI C is allowed.

I think this is not true.

> So what are you aiming for, actually? Ultimately, change the build system to compile everything with `-std=c99`

I'm not convinced this is a good idea. I'd prefer if the choice of compiler flags was left to the user. However maybe it is a good idea to add this to the travis build? - I wouldn't be surprised if we end up finding some line of C11 somewhere ... :)

…

-- If you want to support my work: see http://friends.ccbib.org/harald/supporting/ or donate via CLAM to xASPBtezLNqj4cUe8MT5nZjthRSEjrRQXN or via peercoin to P98LRdhit3gZbHDBe7ta5jtXrMJUms4p7w

[fmertz]

After doing a bit more research, I can better frame this "issue".

Over time, the C language has evolved. There are, at a high level, 3 evolutions we can look at. They are C89, C99 and C11. As we are talking about the language itself, the primary tool is the compiler. Over time, and as the standards evolve, compilers add support for these new language features, but they are not necessarily engaged by default. So, this is a two part thing: there is what the compiler could do, and there is what that same compiler does by default. With this project, if we do "nothing" explicitly to select a variant of the language, we fall back onto whatever a particular compiler version defaults to. The important part is that that an older compiler could compile newer code if told to do so, but not without an explicit instruction to do so. Looking more in the detail of the release notes for various version of gcc, the default language does change over time.

The bottom line is that compiling new code on a new compiler just works of course. The issue is compiling new code on an older compiler. If we do nothing, the build fails because the compiler defaults to an older dialect. The thing is that if we tell that same older compiler to work with the newer dialect, it could just work (depending on the level of support that compiler has for the new features).

I believe the current Travis build fails because of this. Gcc 4.6 defaults to C89, so for loops with a declaration fail. If we were to formally declare that the official standard for the project was C99, this code would more than likely compile just fine on this older compiler. I believe just adding AC_PROG_CC_STDC to configure.ac would do it.

Once I am past this EZIO driver, I am willing to put more time testing this, and propose a pull request.

[haraldg]

Closed by merging #83