Bug 144580 - [CMake] Build C code with -std=c89
Summary: [CMake] Build C code with -std=c89
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: New Bugs (show other bugs)
Version: 528+ (Nightly build)
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-05-04 09:39 PDT by Zan Dobersek
Modified: 2022-09-23 05:32 PDT (History)
6 users (show)

See Also:

Attachments
Patch (1.30 KB, patch)
2015-05-04 09:45 PDT, Zan Dobersek 		no flags Details | Formatted Diff | Diff
Patch (1.55 KB, patch)
2016-01-05 02:34 PST, Zan Dobersek 		mcatanzaro: review-
Details | Formatted Diff | Diff
Show Obsolete (1) View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Zan Dobersek 2015-05-04 09:39:16 PDT 
[CMake] Build C code with -std=c11
Comment 1 Zan Dobersek 2015-05-04 09:45:30 PDT 
Created attachment 252315 [details]
Patch
Comment 2 Csaba Osztrogonác 2015-05-04 10:40:51 PDT 
Let me check the EFL failure.
Comment 3 Csaba Osztrogonác 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.
Comment 4 Michael Catanzaro 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.
Comment 5 Zan Dobersek 2016-01-05 02:09:07 PST 
OK, agreed. Let's settle on c89 (in 2016 :|)
Comment 6 Zan Dobersek 2016-01-05 02:34:53 PST 
Created attachment 268274 [details]
Patch
Comment 7 Michael Catanzaro 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. :/
Comment 8 Zan Dobersek 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.
Comment 9 Zan Dobersek 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.
Comment 10 Ahmad Saleem 2022-09-23 05:32:11 PDT 
Is this required anymore? Thanks1