clang c11

Marc Lehmann schmorp at schmorp.de
Fri Mar 20 23:28:01 CET 2015


On Fri, Mar 20, 2015 at 05:44:31PM -0400, Jamal Hadi Salim <jhs at mojatatu.com> wrote:
> We are trying to use c11 with other standards of course. We have a
> requirement to make our code "c11 compliant". So thats where this
> comes

"c11 compliant" is a meaningless phrase w.r.t. C11 (the standard itself),
though: C11 only knows three compliance levels: strictly conformant,
conformant, and non-conformant (C11 doesn't place any limitations on
these).

Compliance has nothing to do with the -std=C11 switch you use: -std=c11
apparently(*) tries to enforce strict conformance to C11, which means no
sockets, no file descriptors, no libev(§).

I think clangs default mode (depending on version, or probably with
-std=gnu11) already tries to enforce C11 conformance, so that definitely
seems like the switch (or missing switch) you want.

> from (i.e by itself c11 doesnt support the things you mentioned; and
> i wouldnt expect it to - but one could argue that neither does std c).

What is "std c"? C11 is standard C, if you mean that, and neither C11, nor
any other version of standard C support those features, so it is pointless
to try to use libev in such an environment: you couldn't use it (while
being strictly conformant).

> >As such, failure is to be expected, and correct, i.e. it's a configuration
> >error.
> 
> That was what i was curious about.
> Note: I can make the problem go away with a simple patch:

That makes no sense - first you instruct your compilation environment to
enforce strict conformance (meaning not to provide any extensions), and
then you would add a hack to libev to trick your headers into providing a
non-strict environment.

And since you would have to make a similar hack in your own code to _use_
libev, why not drop strict C11 conformance in the first place - what's
trhe gain of a switch that you have to undo in your code anyway?

> Which i dont need if i dont specify -std=c11

Which seems like the logical thing to do: strictly conforming C11 code
can't use libev(†), nor can libev be compiled in such an environment.

clang without this switch isn't less conforming to C11, either, nor is
libev less (or more) conforming with this switch.

> It could be just specific to clang being pedantic (as opposed to
> c11 specific).

AFAICS, clang is being completely correct here - user requests strict
conformance, program no longer compiles because it isn't.

I think the problem here is a (relatively common) misunderstanding, namely
that -std=C11 somehow enforces conformance to C11, or checks programs
for C11 conformance. This isn't the case, it does switch clang into "C11
only" mode, in which non strictly conforming programs are not supposed to
compile, which cna be useful to check your program for strict conformance.

However, strict C11 conformance is meaningless for roughly 100% of all
real world programs, because you need extensions outside C11 to get work
done, in the case of libev, you need file descriptors as a minimum, which
are not available in C11 - you need extensions.

(*) Again, I can't find a good description of what -std=c11 applies to
achieve. The enforcing agent here might not be clang itself, but the
header files of your platform. Nevertheless, what happens is that -std=c11
selects strict conformance, within limits.

(§) libev attempts to be C11 (and C90) conformant (no known issues
exist), but it cannot be strictly conformant.

(†) not in default configuration, anyway.

-- 
                The choice of a       Deliantra, the free code+content MORPG
      -----==-     _GNU_              http://www.deliantra.net
      ----==-- _       generation
      ---==---(_)__  __ ____  __      Marc Lehmann
      --==---/ / _ \/ // /\ \/ /      schmorp at schmorp.de
      -=====/_/_//_/\_,_/ /_/\_\



More information about the libev mailing list