[Swan-dev] Add -std=c99 to the compiler flags?

Andrew Cagney andrew.cagney at gmail.com
Thu Feb 5 18:42:09 EET 2015


On 5 February 2015 at 01:45, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> | From: Andrew Cagney <andrew.cagney at gmail.com>
>
> | On 4 February 2015 at 15:33, D. Hugh Redelmeier <hugh at mimosa.com> wrote:
> | > | From: Andrew Cagney <andrew.cagney at gmail.com>
>
> | > |     for (int i = 0; i < 10; i++) { ... }
> | > |
> | > | without -std=c99 I get a warning :-)
>
> | > Why does gcc require a flag?  Is using c99 so remarkable that it cannot be
> | > the default?  Is there any downside?  At least some things we already use
> | > were introduced in C99.
> |
> | The default for GCC (i.e, up to 4.x) is -std=gnu90 ("GNU dialect of
> | ISO C90 (including some C99 features)").  That is why we get away with
> | doing some things, but other things get warnings.
>
> Surely they could add the for (int i... thing too.  It doesn't break
> any existing program.

Cue violent agreement.

> | > What other C99 features are worth using?
> | >
> | > - I think that we already use the struct and union member initializing
> | >   syntax
> |
> | GNU and C99 had different syntax, I believe we're using the new syntax.
>
> Right.  That seems to be allowed by default.
>
> | > - Variable Length Arrays (VLAs) have been made optional-to-support in the
> | >   more recent standards so we should not use them.  Too bad: they could
> | >   do what alloca was used for.
> |
> | There's dogma arguing that we, as (what is the buzz phrase) an attack
> | surface, should never allocate dynamic sized structures on the stack.
>
> I don't that that is the reason.  I think it is that it was a
> divergence from C++, and now C++ kind of takes the lead.

Likely true.

> | The behaviour of inline also changed.  Specifically this case:
> |
> | static __inline__ struct hash_desc *ike_alg_get_hasher(int alg)
> | {
> |         return (struct hash_desc *) ikev1_alg_find(IKE_ALG_HASH, alg);
> | }
>
> I try to avoid anything with __.  It's a danger sign.  Sometimes
> needed.
>
> What's changed here?

The code is probably safe.  The keyword "extern" is also involved.
See the bottom of:
https://gcc.gnu.org/onlinedocs/gcc/Inline.html
See http://yarchive.net/comp/linux/gcc_inline.html for hints as to why
I try to erase the issue from my memory.

> | (I'm guessing the intent is for this to be a strongly typed macro)
>
> Yeah, probably.  Mind you, I look at it the other way: #define is a
> poor man's inline, one with no typechecking.
>
> | IMNSHO we shouldn't be using inline any way.  We're deluding ourselves
> | if we think we can out wit the compiler: GCC will inline the things it
> | likes regardless; and issue warning pointing out how we're wrong :-)
>
> I use inline when I'm confused about our headers.  It has the merit of
> a macro (can be defined, not just declared in a .h).  And yet it is
> type safer.

Perhaps there should be a separate discussion thread where we try to
figure out the headers.  I suspect I'm even more confused.

Here though, just use normal functions, a performance is not an issue.
For the above, for instance, I think the header should just contain:

  struct hash_desc *ike_alg_get_hasher(int alg);

hiding the generic code in the .c file along with its call:

static struct ike_alg *ikev1_alg_find(unsigned algo_type,
                             unsigned algo_id) {...}

struct hash_desc *ike_alg_get_hasher(int alg)
{
        return (struct hash_desc *) ikev1_alg_find(IKE_ALG_HASH, alg);
}

While, Mr Mackey from South Park would claim "macros are bad m'kay",
they do have their use.  The DBG macros for instance are a positive
example.

> I don't like it that I'm confused about our headers.  Some .h files
> are available to all userland but contain things only for pluto, for
> example.  That's bad.
>
> Non-inline external functions are often hard to inline, depending on
> the compiler architecture.
>
> | > - <inttypes.h> I think we already use it
> |
> | We should be using it.  Often we don't.
>
> Clean up anything you stumble upon.  That's what I try to do.


It will create a lot of entropy in the code making back-ports messier.

So, is -std=c99 in?

Andrew

PS: According to that ever reliable source of information, Wikipedia,
Microsoft skipped c99 and went straight for c11.


More information about the Swan-dev mailing list