NEW 144580
[CMake] Build C code with -std=c89 
https://bugs.webkit.org/show_bug.cgi?id=144580
Summary [CMake] Build C code with -std=c89
Zan Dobersek
Reported 2015-05-04 09:39:16 PDT
[CMake] Build C code with -std=c11
Attachments
Patch (1.30 KB, patch)
2015-05-04 09:45 PDT, Zan Dobersek 		no flags
DetailsFormatted DiffDiff
Patch (1.55 KB, patch)
2016-01-05 02:34 PST, Zan Dobersek 		mcatanzaro: review-
DetailsFormatted DiffDiff
Show Obsolete (1) View All Add attachment proposed patch, testcase, etc.
Zan Dobersek
Comment 1 2015-05-04 09:45:30 PDT
Created attachment 252315 [details] Patch
Csaba Osztrogonác
Comment 2 2015-05-04 10:40:51 PDT
Let me check the EFL failure.
Csaba Osztrogonác
Comment 3 2015-05-05 05:52:51 PDT
The problem is that strdup in string.h is ifdef-ed out if we build it with -std=c11. Defining GNU_SOURCE solves the build error in Minibrowser/main.c, but I'm not sure what is the proper fix for it, or if EFL wants to build with c11 or not.
Michael Catanzaro
Comment 4 2016-01-03 17:10:12 PST
Comment on attachment 252315 [details] Patch I'm not at all sure this is a good idea. Microsoft has no intention of supporting C11 (or even C99) in MSVCC, so we would have to be careful to only use C11 in code that will never be used by Windows. Since we probably want to support Windows eventually, allowing C11 to creep into our codebase anywhere will make that harder. It also makes it easier to accidentally break Windows when making changes locally, and not find out until the EWS catches it. Now, with GCC 5 the default is currently -std=gnu11, so switching to -std=c11 is more restrictive as it disables GNU extensions, which is good for us. But with Clang the default is -std=gnu99, and with GCC 4.x the default is -std=gnu89. You might call Microsoft's version ms89. So we're compiling with four different standards right now, and there is certainly good benefit to explicitly specifying a standard. But I would suggest we explicitly compile with -std=c89, rather than c11.
Zan Dobersek
Comment 5 2016-01-05 02:09:07 PST
OK, agreed. Let's settle on c89 (in 2016 :|)
Zan Dobersek
Comment 6 2016-01-05 02:34:53 PST
Created attachment 268274 [details] Patch
Michael Catanzaro
Comment 7 2016-01-05 06:38:29 PST
Comment on attachment 268274 [details] Patch Patch LGTM, except for the roughly bajillion EFL and GTK build failures. :/
Zan Dobersek
Comment 8 2016-01-05 07:36:01 PST
The errors are in the Udis86 code. I'm not fixing that since the code is coming from an external project, which I hope doesn't care about C89 compliance. MSVC has some basic support for C99, and no compiler supports it completely anyway. C11 doesn't work with EFL headers. So either C99 should be default, or we should make the -std= C flag port-specific.
Zan Dobersek
Comment 9 2016-01-13 01:50:25 PST
I'm not bothering with this anymore. The amount of C code that's built is minimal, and every compiler and port have their own quirks around this.
Ahmad Saleem
Comment 10 2022-09-23 05:32:11 PDT
Is this required anymore? Thanks1
Note You need to log in before you can comment on or make changes to this bug.